?>(null) }
+
+ fun appendLog(msg: String) {
+ Log.d("CertTestApp", msg)
+ logMessages = logMessages + msg
+ }
+
+ // Response dialog with WebView
+ responseDialog?.let { (code, body) ->
+ AlertDialog(
+ onDismissRequest = { responseDialog = null },
+ title = { Text("HTTP $code") },
+ text = {
+ AndroidView(
+ factory = { ctx ->
+ WebView(ctx).apply {
+ val html = "${body.replace("&", "&").replace("<", "<")}"
+ loadDataWithBaseURL(null, html, "text/html", "UTF-8", null)
+ }
+ },
+ modifier = Modifier
+ .fillMaxWidth()
+ .height(320.dp)
+ )
+ },
+ confirmButton = {
+ TextButton(onClick = { responseDialog = null }) { Text("Close") }
+ }
+ )
+ }
+
+ Column(
+ modifier = Modifier
+ .fillMaxSize()
+ .padding(16.dp)
+ .verticalScroll(rememberScrollState())
+ ) {
+ Text("NIAP EST Enrollment Client", style = MaterialTheme.typography.headlineMedium)
+ Spacer(modifier = Modifier.height(16.dp))
+
+ OutlinedTextField(value = alias, onValueChange = { alias = it; savePrefs() }, label = { Text("Key Alias") }, modifier = Modifier.fillMaxWidth())
+ Spacer(modifier = Modifier.height(8.dp))
+ OutlinedTextField(value = estUrl, onValueChange = { estUrl = it; savePrefs() }, label = { Text("EST Server URL") }, modifier = Modifier.fillMaxWidth())
+ Spacer(modifier = Modifier.height(8.dp))
+ OutlinedTextField(value = authToken, onValueChange = { authToken = it; savePrefs() }, label = { Text("Auth Token (user:pass)") }, modifier = Modifier.fillMaxWidth())
+ Spacer(modifier = Modifier.height(8.dp))
+ OutlinedTextField(value = subjectDn, onValueChange = { subjectDn = it; savePrefs() }, label = { Text("Subject DN") }, modifier = Modifier.fillMaxWidth())
+ Spacer(modifier = Modifier.height(8.dp))
+ OutlinedTextField(value = caPemUrl, onValueChange = { caPemUrl = it; savePrefs() }, label = { Text("CA PEM URL (blank = raw resource)") }, modifier = Modifier.fillMaxWidth())
+ Spacer(modifier = Modifier.height(8.dp))
+ OutlinedTextField(value = mtlsEndpoint, onValueChange = { mtlsEndpoint = it; savePrefs() }, label = { Text("mTLS Endpoint URL") }, modifier = Modifier.fillMaxWidth())
+ Spacer(modifier = Modifier.height(16.dp))
+
+ Row(modifier = Modifier.fillMaxWidth(), horizontalArrangement = Arrangement.SpaceEvenly) {
+ Button(onClick = {
+ coroutineScope.launch(Dispatchers.IO) {
+ logMessages = emptyList()
+ certSummary = null
+ errorMessage = null
+ status = "ENROLLING"
+ val caPem = loadCaPem()
+ appendLog("CA PEM: ${caPem.length} bytes")
+ // Use custom CA as TLS trust anchor only for self-signed servers (localhost / private IP).
+ // Public endpoints (Cloud Run etc.) use the system trust store.
+ val isPrivate = estUrl.contains("localhost") || estUrl.contains("10.0.2.2") || estUrl.contains("192.168.")
+ val trustAnchor = if (isPrivate) caPem else ""
+ if (!isPrivate) appendLog("Public EST URL โ using system trust store")
+ val req = EnrollmentRequest(alias, estUrl, authToken, subjectDn, trustedCaPem = trustAnchor)
+ try {
+ val certBytes = certManager.enroll(req).get(30, java.util.concurrent.TimeUnit.SECONDS)
+ status = "READY"
+ val cert = CertificateFactory.getInstance("X.509")
+ .generateCertificate(ByteArrayInputStream(certBytes)) as X509Certificate
+ certSummary = "Subject: ${cert.subjectDN}\nIssuer: ${cert.issuerDN}\nSerial: ${cert.serialNumber}\nAlg: ${cert.sigAlgName}\nValid: ${cert.notBefore} โ ${cert.notAfter}"
+ appendLog("Enrollment succeeded")
+ } catch (e: java.util.concurrent.ExecutionException) {
+ status = "FAILED"
+ val detail = e.cause?.message ?: e.message ?: "Unknown error"
+ appendLog("Enrollment failed: $detail")
+ errorMessage = detail
+ } catch (e: Exception) {
+ status = "FAILED"
+ appendLog("Enrollment error: ${e.message}")
+ errorMessage = e.message
+ }
+ }
+ }) { Text("Enroll (EST)") }
+
+ Button(
+ onClick = {
+ coroutineScope.launch(Dispatchers.IO) {
+ appendLog("Revoking alias: $alias")
+ try {
+ certManager.revoke(alias).get(15, java.util.concurrent.TimeUnit.SECONDS)
+ status = "REVOKED"
+ certSummary = null
+ errorMessage = null
+ } catch (e: Exception) {
+ appendLog("Revoke failed: ${e.message}")
+ }
+ }
+ },
+ colors = ButtonDefaults.buttonColors(containerColor = MaterialTheme.colorScheme.error)
+ ) { Text("Revoke") }
+
+ Button(
+ onClick = {
+ coroutineScope.launch(Dispatchers.IO) {
+ appendLog("Opening mTLS endpoint: $mtlsEndpoint")
+ try {
+ val caPem = loadCaPem()
+ val sslCtx = certManager.getSslContext(alias, caPem.ifBlank { null })
+ val tm: X509TrustManager = if (caPem.isNotBlank()) {
+ val ks = KeyStore.getInstance(KeyStore.getDefaultType()).apply {
+ load(null, null)
+ setCertificateEntry("ca", CertificateFactory.getInstance("X.509")
+ .generateCertificate(caPem.byteInputStream()) as X509Certificate)
+ }
+ TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm())
+ .apply { init(ks) }.trustManagers[0] as X509TrustManager
+ } else {
+ TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm())
+ .apply { init(null as KeyStore?) }.trustManagers[0] as X509TrustManager
+ }
+ val client = OkHttpClient.Builder()
+ .sslSocketFactory(sslCtx.socketFactory, tm)
+ .hostnameVerifier { _, _ -> true }
+ .build()
+ val response = client.newCall(Request.Builder().url(mtlsEndpoint).get().build()).execute()
+ val code = response.code
+ val body = response.body?.string() ?: ""
+ appendLog("Response: HTTP $code")
+ responseDialog = code to body
+ } catch (e: Exception) {
+ appendLog("Error: ${e.message}")
+ responseDialog = 0 to (e.message ?: e.javaClass.simpleName)
+ }
+ }
+ },
+ enabled = mtlsEndpoint.isNotBlank()
+ ) { Text("mTLS") }
+ }
+
+ Spacer(modifier = Modifier.height(16.dp))
+ Text("Status: $status", style = MaterialTheme.typography.titleMedium)
+
+ errorMessage?.let {
+ Spacer(modifier = Modifier.height(8.dp))
+ Card(
+ modifier = Modifier.fillMaxWidth(),
+ colors = CardDefaults.cardColors(containerColor = MaterialTheme.colorScheme.errorContainer)
+ ) {
+ Column(modifier = Modifier.padding(12.dp)) {
+ Text("Enrollment Failed", style = MaterialTheme.typography.titleSmall, color = MaterialTheme.colorScheme.onErrorContainer)
+ Text(it, style = MaterialTheme.typography.bodySmall, color = MaterialTheme.colorScheme.onErrorContainer)
+ }
+ }
+ }
+
+ certSummary?.let {
+ Spacer(modifier = Modifier.height(8.dp))
+ Card(
+ modifier = Modifier.fillMaxWidth(),
+ colors = CardDefaults.cardColors(containerColor = MaterialTheme.colorScheme.secondaryContainer)
+ ) {
+ Column(modifier = Modifier.padding(12.dp)) {
+ Text("Certificate", style = MaterialTheme.typography.titleSmall)
+ Text(it, style = MaterialTheme.typography.bodySmall)
+ }
+ }
+ }
+
+ // โโ Logs โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
+ Spacer(modifier = Modifier.height(16.dp))
+ Text("Logs:", style = MaterialTheme.typography.titleSmall)
+ Spacer(modifier = Modifier.height(4.dp))
+ Card(
+ modifier = Modifier.fillMaxWidth().height(180.dp),
+ colors = CardDefaults.cardColors(containerColor = MaterialTheme.colorScheme.surfaceVariant)
+ ) {
+ Column(modifier = Modifier.padding(8.dp).verticalScroll(rememberScrollState())) {
+ logMessages.forEach { Text(it, style = MaterialTheme.typography.bodySmall) }
+ }
+ }
+ }
+}
diff --git a/niap-cc/niap-android-cert-ext/cert-test-app/src/main/res/raw/est_validation_ca.pem b/niap-cc/niap-android-cert-ext/cert-test-app/src/main/res/raw/est_validation_ca.pem
new file mode 100644
index 0000000..b42a508
--- /dev/null
+++ b/niap-cc/niap-android-cert-ext/cert-test-app/src/main/res/raw/est_validation_ca.pem
@@ -0,0 +1,15 @@
+-----BEGIN CERTIFICATE-----
+MIICUjCCAdegAwIBAgIUI93ak0Af/PpdrSMXYNNYXsqZV4swCgYIKoZIzj0EAwMw
+VjELMAkGA1UEBhMCSlAxDjAMBgNVBAgMBVRva3lvMRYwFAYDVQQKDA1OSUFQIFRl
+c3QgTGFiMR8wHQYDVQQDDBZFU1QgVmFsaWRhdGlvbiBSb290IENBMB4XDTI2MDUy
+MTA3MDUxMloXDTM2MDUxODA3MDUxMlowVjELMAkGA1UEBhMCSlAxDjAMBgNVBAgM
+BVRva3lvMRYwFAYDVQQKDA1OSUFQIFRlc3QgTGFiMR8wHQYDVQQDDBZFU1QgVmFs
+aWRhdGlvbiBSb290IENBMHYwEAYHKoZIzj0CAQYFK4EEACIDYgAE912sIneXUhfC
+pKCOlPeoJFLVR0CP1s0Z01+IQIuNEGgoHOKJHFbptRdQJX56q5OfQx9JT/ngevEN
+XLuKgAZQNlP/ClVpSs2ShgavWjgcBFq5UJ2gwvH/9P8aV/v1Qi38o2YwZDASBgNV
+HRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRPsVVyFfv7Kf9nn7pr6siFah5PuzAf
+BgNVHSMEGDAWgBRPsVVyFfv7Kf9nn7pr6siFah5PuzAOBgNVHQ8BAf8EBAMCAQYw
+CgYIKoZIzj0EAwMDaQAwZgIxAO8ZMUvtTSUqyCfzpbTxWEuOilNUm2n8UB0lNqHY
+mGltrZFFMakwcsl/I4r/V7tYRQIxAIhVhY25gRoVz33MyHCSIkhw3DwuensR4NpB
+RM+4/9m5aN5jODgfEW8bjBK3QlZPJg==
+-----END CERTIFICATE-----
diff --git a/niap-cc/niap-android-cert-ext/cert-test-app/src/main/res/xml/network_security_config.xml b/niap-cc/niap-android-cert-ext/cert-test-app/src/main/res/xml/network_security_config.xml
new file mode 100644
index 0000000..e6a7e2f
--- /dev/null
+++ b/niap-cc/niap-android-cert-ext/cert-test-app/src/main/res/xml/network_security_config.xml
@@ -0,0 +1,21 @@
+
+
+
+
+ localhost
+
+
diff --git a/niap-cc/niap-android-cert-ext/docs/FIA_XCU_EXT.1.md b/niap-cc/niap-android-cert-ext/docs/FIA_XCU_EXT.1.md
new file mode 100644
index 0000000..1aa1606
--- /dev/null
+++ b/niap-cc/niap-android-cert-ext/docs/FIA_XCU_EXT.1.md
@@ -0,0 +1,204 @@
+## Identification and Authentication (FIA)
+
+### FIA\_XCU\_EXT.1 Implementation of X.509 Functions
+
+FIA\_XCU\_EXT.1.1
+The TSF shall \[**selection**: *verify, assert*\] identities included in X.509 certificates.
+
+### FIA\_X509\_EXT.1 X.509 Certificate Validation
+
+FIA\_X509\_EXT.1.1
+The TSF shall \[**selection**: *invoke platform-provided functionality, implement functionality*\] to validate certificates in accordance with the following rules:
+
+* Certification path validation meets requirements of RFC 5280 for certificate paths of \[**selection**: *unlimited path length, maximum path length of \[**assignment**: 102\] certificates*\] and certificate paths exceeding the maximum path length are invalid.
+* The current time is within the notBefore and notAfter values of all certificates in the certification path.
+* The certification path shall terminate at a trust anchor element appropriate for the supported function.
+* Certificates containing subjectUniqueID or issuerUniqueID fields are considered invalid.
+* Certificates are signed using cryptographic signatures and hashes in accordance with RFC 8603, and \[**selection**:
+ * *\[**assignment**: list of supported cryptographic algorithms\]*
+ * *no other algorithms*
+
+ \] and certificates signed using other cryptographic algorithms are considered invalid.
+
+* \[**selection**:
+ * *CRLs are signed using cryptographic signatures and hashes in accordance with RFC 8603 and \[**selection**:*
+ * *\[**assignment**: list of supported cryptographic algorithms\]*
+ * *no other algorithms*
+
+ *\] and CRLs signed using other cryptographic algorithms are considered invalid;*
+
+ * *OCSP responses are signed using \[**selection**:*
+ * *sha384WithRSAEncryption with key size of 3072 bits or greater,*
+ * *ecdsa-with-SHA384 using \[**selection**: secp384r1, secp521r1\],*
+ * *ecdsa-with-SHA512 using \[**selection**: secp384r1, secp521r1\],*
+
+ *\] and \[**selection**:*
+
+ * *\[**assignment**: list of other supported algorithms\]*
+ * *no other algorithms*
+
+ *\] requested using the preferredSignatureAlgorithm extension and OCSP responses are considered invalid if using other algorithms;*
+
+ * *No other algorithm constraints*
+
+ \].
+
+
+FIA\_X509\_EXT.1.2
+The TSF shall \[**selection**: *invoke platform-provided functionality, implement*\] processing of the extensions indicated in RFC 5280, section 4.2,
+
+* Authority Key Identifier,
+* Subject Key Identifier
+* keyUsage
+* and \[**selection**:
+ * *basicConstraints*
+ * *authorityInformationAccess*
+ * *cRLDistributionPoints*
+ * *certificatePolicies*
+ * *policyMapping*
+ * *Subject alternate name containing any of the following name types \[**selection**:*
+ * *rfc822Name*
+ * *dNSName*
+ * *directoryName*
+ * *uniformResourceIdentifier*
+ * *iPAddress*
+ * *\[**assignment**: other name types\]*
+
+ *\]*
+
+ * *extendedKeyUsage*
+ * *nameConstraints*
+ * *\[**assignment**: other extensions\]*
+ * *no other extensions*
+
+ \].
+
+
+FIA\_X509\_EXT.1.3
+The TSF shall \[**selection**: *invoke platform-provided functionality, implement functionality*\] to validate revocation status of the certificate using \[**selection**:
+
+* *The Online Certificate Status Protocol (OCSP) as specified in RFC 6960*
+* *Certificate Revocation Lists (CRL) as specified in RFC 5280 and refined by RFC 8603*
+* *Certificate Revocation Lists as specified in RFC 5280*
+* *Based on validity period: Certificates expiring within \[**assignment**: time less than 24 hours\] of the current time are considered valid when no other valid revocation status information is available*
+* *Administrative notification of revocation: \[**assignment**: administrative action upon notification\] using \[**assignment**: method to invalidate use of certificates in supported functions\] when the certificate is revoked.*
+* *Direct association with Certification Authority: \[**assignment**: direct revocation status information implementations\]*
+
+\].
+
+FIA\_X509\_EXT.1.4
+The TSF shall \[**selection**:
+
+* *not obtain revocation status information by the TSF due to \[**selection**: determining that the certificate expires within \[**assignment**: time less than 24 hours\], determining that the \[assignment: supported function\] validates revocation status using \[**assignment**: methods supported by the function\]\]*
+* *\[**selection**: invoke platform-provided functionality, implement functionality\] to obtain supported revocation status information via \[**selection**:*
+* *Network connection to \[**selection**: CA, CRL distribution point, OCSP responder, \[**assignment**: alternate sources \]\]*
+* *Local revocation status information from \[**selection**: cached CRL, embedded CA repository, local OCSP responder, administrator configuration\]*
+* *An OCSP TLS Status Request Extension (OCSP stapling) as specified in RFC 6066,*
+* *An OCSP TLS Multiple Certificate Status Request Extension (OCSP multi-stapling) as specified in RFC 6961*
+ *\]*
+
+\].
+
+FIA\_X509\_EXT.1.5
+The TSF shall \[**selection**: *invoke platform-provided functionality, implement functionality, pass context information to the supported function*\] to validate that the context of the certificate path and trust store element is consistent with the supported function use via \[**selection**:
+
+* *processing \[**selection**:*
+ * *\[**assignment**: trust store context rules\]*
+ * *extendedKeyUsage field constraints in the leaf certificate including: \[**selection**:*
+ * *\[**assignment**: trust store context rules\],*
+ * *extendedKeyUsage (EKU) field constraints in the leaf certificate including: \[**selection**:*
+ * *Certificates used for trusted updates and executable code integrity verification shall have the Code Signing Purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3),*
+ * *Client certificates presented for TLS shall have the Client Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2),*
+ * *Server certificates presented for TLS shall have the Server Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1),*
+ * *Delegated OCSP signerโs certificates presented for OCSP responses shall have the OCSP Signing purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9),*
+ * *Server certificates presented for EST shall have the CMC Registration Authority (RA) purpose (id-kp-cmcRA with OID 1.3.6.1.5.5.7.3.28),*
+ * *Certificates representing a Registration Authority have the CMC Registration Authority Purpose (id-kp-cmcRA with OID 1.3.6.1.5.5.7.3.28),*
+ * *Certificates representing a Registration Authority have the v3 CMP Registration Authority Purpose (id-kp-cmcRA with OID 1.3.6.1.5.5.7.3.28)*
+ * *SMIME certificates presented to protect email have the email protection purpose (id-kp-emailProtection with OID 1.3.6.1.5.5.7.3.4),*
+ * *IPsec and IKE certificates used in conjunction with other functions requiring an explicit EKU also have the IPsec-IKE purpose (id-kp-ipsecIKE with OID 1.3.6.1.5.5.7.3.17) in accordance with RFC 4945, section 5.1.3.12,*
+ * *\[**assignment**: other EKU values required by supported functions\]*
+
+ *\]*
+
+ *\] and rejects the certificate if the context requirements are not met,*
+
+ *\]*
+
+* *passing \[**selection**: certification path, \[**assignment**: context from certification path processing\] passed to the supported function\]*
+
+\].
+
+FIA\_X509\_EXT.1.6
+The TSF shall \[**selection**: *manage trust stores, use platform-managed trust stores*\] used for certification path validation.
+
+### FIA\_X509\_EXT.2 X.509 Certificate Support for Functions
+
+FIA\_X509\_EXT.2.1
+The TSF shall \[**selection**: *invoke platform-provided functionality to validate, validate*\] X.509v3 certificates in accordance with FIA\_X509\_EXT.1 to support \[**assignment**: *supported functions*\] using \[**selection**:
+
+* *\[**selection**: TLS, DTLS, IPsec or IKE , SMIME, SSH, \[**assignment**: other authenticated communications protocol\]\]*
+* *\[**selection**: code signing for system software updates, code signing for software integrity testing, integrity verification for TSF protected data, administrator authentication, user authentication , \[**assignment**: other uses\]\]*
+
+\].
+
+FIA\_X509\_EXT.2.2
+For each function indicated in FIA\_X509\_EXT.2.1, the TSF shall \[**selection**: *invoke the TOE platform to determine, determine*\] whether the \[**selection**: *administrator is allowed to configure certificate acceptance, supported function determines acceptance via \[**assignment**: method of determining acceptance\], certificate is accepted, certificate is not accepted*\] when valid certificate revocation status information cannot be obtained from a source indicated in FIA\_X509\_EXT.1.3.
+
+### FIA\_X509\_EXT.3 X.509 Certificate Requests
+
+FIA\_X509\_EXT.3.1
+The TSF shall \[**selection**: *invoke the TOE platform to generate, generate*\] Certificate Requests as specified by \[**selection**:
+
+* *RFC 2986 (PKCS-10)*
+* *RFC 7030 as updated by RFC 8996 (EST)*
+* *RFC 5272 as updated by RFC 6402 (CMC)*
+* *RFC 5272 as updated by RFC 8756 (CNSA CMC)*
+* *RFC 4210 as updated by RFC 6712 and RFC 9481 (v2 CMP)*
+* *RFC 4210 as updated by RFC 6712 and RFC 9480 (v3 CMP)*
+
+\] and be able to provide the following information in the request: public key, \[**selection**:
+
+* *Subject DN consisting of values for \[**selection**:*
+ * *U*
+ * *O*
+ * *OU*
+ * *CN*
+ * *\[**assignment**: other subject attributes\]*
+
+ *\]*
+
+* *one or more of the following SAN types \[**selection**:*
+ * *rfc822Name*
+ * *dNSName*
+ * *directoryName*
+ * *uniformResourceIdentifier*
+ * *iPAddress*
+ * *\[**assignment**: other SAN types\]*
+
+ *\]*
+
+\] and \[**selection**:
+
+* *\[**assignment**: list of other certificate field and extension values\]*
+* *\[**assignment**: list of identifying information\]*
+* *no other information.*
+
+\].
+
+FIA\_X509\_EXT.3.2
+The TSF shall \[**selection**: *invoke platform-provided functionality, provide functionality*\] to validate the certificate path in accordance with FIA\_X509\_EXT.1 upon receiving the CA Certificate Response, and validate that the certificate path of the response is consistent with the intended usage.
+
+### FIA\_XCU\_EXT.2 X.509 Certificate Acquisition
+
+FIA\_XCU\_EXT.2.1
+The TSF shall \[**selection**:
+
+* *request certificates from an \[**selection**: external, embedded \] CA,*
+* *obtain certificates from an embedded CA*
+
+\] to represent \[**assignment**: *TOE functions*\] for \[**selection**:
+
+* *\[**selection**: TLS, DTLS, IPsec or IKE , SMIME, SSH, \[**assignment**: other authenticated communications protocol\]\]*
+* *\[**selection**: code signing for system software updates, code signing for software integrity testing, integrity verification for TSF protected data, administrator authentication, user authentication, \[**assignment**: other uses\]\]*
+
+\].
diff --git a/niap-cc/niap-android-cert-ext/docs/cetrt-manager.arch.md b/niap-cc/niap-android-cert-ext/docs/cetrt-manager.arch.md
new file mode 100644
index 0000000..afc5e54
--- /dev/null
+++ b/niap-cc/niap-android-cert-ext/docs/cetrt-manager.arch.md
@@ -0,0 +1,161 @@
+# cert-manager Architecture & Design
+
+## 1. Component Architecture (Client, IPC, Service)
+
+```mermaid
+graph TD
+ subgraph Client Layer / App Process
+ APP[Client Application]
+ CM[CertManager
Client Interface / API]
+ end
+
+ subgraph IPC Layer
+ AIDL[ICertManager.aidl
Binder IPC]
+ end
+
+ subgraph Service Layer / FGS Process
+ FGS[CertManagerService
Foreground Service]
+ ORCH[CertOrchestrator
Workflow Controller]
+ end
+
+ subgraph Service Core Engines
+ CSR[CsrEngine
PKCS#10 Generation]
+ EST[EstClient
Acquisition Engine]
+ VAL[CertValidator
NiapCertValidator Wrapper]
+ KS[KeyStoreEngine
Android KeyStore]
+ end
+
+ APP -->|Calls API| CM
+ CM -->|Binds & Calls| AIDL
+ AIDL -->|Dispatches to| FGS
+ FGS -->|Delegates to| ORCH
+ ORCH -->|1. Generate CSR| CSR
+ ORCH -->|2. Acquire Cert| EST
+ ORCH -->|3. Validate Cert| VAL
+ ORCH -->|4. Store Cert| KS
+```
+
+## 2. Protocol-Agnostic Certificate Acquisition Flow
+
+```mermaid
+graph TD
+ subgraph 1. Common CSR Generation
+ CSR[CsrEngine
Enforces P-384 / SHA-384 / SAN]
+ end
+ subgraph 2. Abstract Acquisition Layer
+ INT[IAcquisitionClient
Interface]
+ EST[EstClient]
+ CMC[CmcClient
Future]
+ CMP[CmpClient
Future]
+ INT --- EST
+ INT --- CMC
+ INT --- CMP
+ end
+ subgraph 3. Common Validation
+ VAL[CertValidator
Enforces FIA_X509_EXT.1 Rules]
+ end
+ CSR -->|PKCS#10| INT
+ INT -->|Cert Response| VAL
+```
+
+## 3. Operational Use Cases & Enrollment Workflows
+
+```mermaid
+graph TD
+ subgraph 1. Zero-Touch / MDM Provisioning
+ MDM[MDM Config / Managed Configs] -->|Auto Trigger| FGS[CertManagerService]
+ FGS -->|Silent EST Enrollment| CA[CA Server]
+ end
+
+ subgraph 2. Auto Rotation / Scheduled Job
+ WM[WorkManager Cron] -->|Check Expiry < 24h| FGS
+ end
+
+ subgraph 3. User Interactive Enrollment
+ UI[Settings UI Activity] -->|User enters PIN/Token| FGS
+ end
+
+ subgraph Target Consumers of Acquired Certificates
+ KS[Android KeyStore / KeyChain API]
+ FGS -->|Stores Verified Cert| KS
+ KS -->|mTLS Authentication| BROWSER[Chrome / Web Browsers]
+ KS -->|EAP-TLS Wi-Fi / VPN| NET[VPN Clients / Enterprise Wi-Fi]
+ KS -->|API Mutual Auth| APPS[Dedicated Enterprise Apps]
+ end
+```
+
+### Explanation of Certificate Consumers
+
+Acquired client certificates are stored in the **Android KeyStore** and made available system-wide via Android's `KeyChain API`. This means the certificates managed by `cert-manager` can be utilized across the entire Android device ecosystem:
+
+1. **Web Browsers (Chrome / Edge / Enterprise Browsers)**: When accessing high-security government or corporate intranet web portals requiring mTLS, Android prompts the user with a certificate selection dialog to authenticate using the acquired certificate.
+2. **Network Security (VPN & EAP-TLS Wi-Fi)**: The stored certificates can be selected in VPN client configurations (e.g., Cisco AnyConnect) or 802.1X Wi-Fi settings for secure network onboarding.
+3. **Dedicated Enterprise Applications**: Other enterprise apps (secure mailers, ERPs) can request access to the certificate via KeyChain for backend API mutual authentication.
+
+## 4. Security Functional Requirements (SFR) Selection & Traceability
+
+To satisfy NIAP Common Criteria (CC) and MDFPP requirements, `cert-manager` enforces strict architectural selections mapped directly to the official SFRs:
+
+```mermaid
+graph TD
+ subgraph FIA_X509_EXT.3.1 Selection Mapping
+ GEN[Generate Mode
BouncyCastle Builder] --> FMT[Format
RFC 2986 PKCS#10 / RFC 7030 EST]
+ FMT --> DN[Subject DN
CN / O / OU / C]
+ FMT --> SAN[SAN Extensions
dNSName / iPAddress]
+ FMT --> OTHER[Other Info
no other information]
+ end
+```
+
+### FIA_X509_EXT.3.1 (Certificate Requests)
+* **Generation Mode**: `[generate]`
+ * *Implementation*: The TOE module directly generates the PKCS#10 ASN.1 structure and DER encoding using Bouncy Castle (`JcaPKCS10CertificationRequestBuilder`), while leveraging Android KeyStore for secure asymmetric hardware key generation.
+* **Request Protocol/Format**: `[RFC 2986 (PKCS-10), RFC 7030 (EST)]`
+ * *Implementation*: CSRs are strictly formatted as PKCS#10 requests and transmitted over EST `/simpleenroll` endpoints. (CMC and CMP are out of scope).
+* **Subject DN Attributes**: `[O, OU, CN, and assignment: C]`
+ * *Implementation*: Parses and constructs organizational and common name attributes into the X.500 principal structure.
+ * *Note on 'U' Attribute*: In MDFPP requirements, `U` appears as a shorthand representation for `UID` (LDAP User ID: `0.9.2342.19200300.100.1.1`). Bouncy Castle's `BCStyle` natively supports `UID`. `cert-manager` supports `UID` mapping when provided in the subject DN string to fulfill this requirement seamlessly.
+* **Subject Alternative Names (SAN)**: `[rfc822Name, dNSName, directoryName, uniformResourceIdentifier, iPAddress]`
+ * *Implementation*: Bouncy Castle's `GeneralName` core architecture natively supports all standard X.509 v3 SAN tags (Tag 0 through Tag 8). `cert-manager` is capable of constructing and encoding any of these required SAN types (`rfc822Name` for email, `dNSName` for domains, `directoryName` for DNs, `uniformResourceIdentifier` for URIs, and `iPAddress` for IP addresses) into the certificate request extension when provided in the enrollment configuration.
+* **Other Information**: `[no other information]`
+ * *Implementation*: Minimizes attack surface by excluding unnecessary challenge passwords or non-standard attributes.
+
+### FIA_X509_EXT.3.2 (Certificate Path Validation)
+* **Validation Mode**: `[provide functionality]`
+ * *Implementation*: Instead of relying solely on OS defaults, `CertValidator` wraps `NiapCertValidator` to actively enforce SHA-384/P-384 algorithm constraints, basic constraints (non-CA), and EKU rules upon receiving the certificate response.
+
+### FIA_XCU_EXT.2.1 (Certificate Acquisition)
+* **Acquisition Source**: `[request certificates from an external CA]`
+ * *Implementation*: Communicates securely via OkHttp with external enterprise or government CAs (e.g., Cisco EST server) over TLS.
+* **Target Protocol Selection**: `[TLS, IPsec or IKE]`
+ * *Implementation*: While the acquisition transport itself uses TLS (HTTPS), the acquired certificates are stored in Android KeyStore and exposed system-wide via `KeyChain API`. This architecture allows Android OS daemons (VPN clients, IPsec/IKEv2 services like StrongSwan, and Wi-Fi EAP-TLS supplicants) to authenticate network connections using the acquired certificates.
+ * *Server/Gateway Readiness*: Modern enterprise VPN gateways (e.g., Cisco ASA, StrongSwan) natively support EST/SCEP integration. Devices enroll via EST over TLS, then authenticate IPsec tunnels using the acquired hardware-backed certificates.
+
+```mermaid
+sequenceDiagram
+ autonumber
+ participant Chrome as Android Chrome / Partner App
(TLS Client)
+ participant Mgr as Cert Manager Service
(EST Client)
+ participant Proxy as EST/CAS Proxy Server
(Basic Auth Protected)
+ participant CAS as Google Cloud CAS
(Private Sub-CA)
+ participant TestSrv as mTLS Test Endpoint
(Requires CA-signed Cert)
+
+ Note over Mgr, Proxy: Phase 1: Certificate Acquisition (EST)
+ Mgr->>Mgr: 1. Generate P-384 Key in AndroidKeyStore
+ Mgr->>Mgr: 2. Construct & Sign PKCS#10 CSR (SHA384)
+ Mgr->>Proxy: 3. POST CSR over HTTPS (w/ Basic Auth)
+ Proxy->>Proxy: 4. Authenticate Basic Credentials
+ Proxy->>CAS: 5. Request signature via Google CAS API
+ CAS->>CAS: 6. Sign & Issue Certificate (SHA-384)
+ CAS-->>Proxy: 7. Return issued certificate
+ Proxy-->>Mgr: 8. Return Base64 PKCS#7 response
+ Mgr->>Mgr: 9. Validate signature & path constraints
+ Mgr->>Mgr: 10. Store certificate chain in Android KeyStore/KeyChain
+
+ Note over Chrome, TestSrv: Phase 2: Real-World Verification (mTLS)
+ Chrome->>TestSrv: 11. Access secure page via HTTPS
+ TestSrv-->>Chrome: 12. Request Client Certificate (TLS Handshake)
+ Note over Chrome: 13. Android System Prompt:
"Select certificate for authentication"
+ Chrome->>Chrome: 14. User selects installed 'test_client_cert'
+ Chrome->>TestSrv: 15. Complete TLS client authentication (mTLS)
+ TestSrv-->>Chrome: 16. Return secure content (Success!)
+```
\ No newline at end of file
diff --git a/niap-cc/niap-android-cert-ext/docs/niap-cert-ext-design-note.md b/niap-cc/niap-android-cert-ext/docs/niap-cert-ext-design-note.md
new file mode 100644
index 0000000..3d4367a
--- /dev/null
+++ b/niap-cc/niap-android-cert-ext/docs/niap-cert-ext-design-note.md
@@ -0,0 +1,60 @@
+# NIAP Certificate Extension Library Design Note
+
+**Agent / Author**: Antigravity (Draft)
+
+**1. Introduction**
+
+* **1.1 Goal and Scope:** The primary goal of this project is to implement strict X.509 certificate validation and management functions required for NIAP compliance on Android. This library will act as an extension to the Android platform's native capabilities to satisfy specific `FIA_X509_EXT` and `FIA_XCU_EXT` requirements.
+* **1.2 Audience:** Internal developers and evaluation authorities.
+* **1.3 Definitions and Acronyms:**
+ * **TOE**: Target of Evaluation (The system/app running on the Android device being evaluated).
+ * **NIAP**: National Information Assurance Partnership.
+ * **CSR**: Certificate Signing Request.
+ * **EST**: Enrollment over Secure Transport (RFC 7030).
+ * **AKID/SKID**: Authority Key Identifier / Subject Key Identifier.
+
+**2. Background and Motivation**
+
+* **2.1 Problem Statement:**
+ * The standard Android security provider (Conscrypt) is lenient regarding some X.509 extensions and does not strictly enforce all validation rules required by NIAP (e.g., presence of specific extensions, Name Constraints).
+ * Additionally, NIAP requires the TOE to support CSR issuance and certificate acquisition, but native Android devices do not provide these functions by default. Therefore, these features must be added to the TOE.
+ * *(Japanese reference: ใพใใCSRใฎ็บ่กใ่จผๆๆธใฎๅๅพใNIAPใงใฏTOEใซ่ฆๆฑใใใใAndroidใใใคในใฏใใฎๆฉ่ฝใๆใใชใใใ่ฟฝๅ ใฎๅฟ
่ฆใใใ)*
+* **2.2 Justification:**
+ * To achieve NIAP certification, we need to complement Conscrypt's behavior with a library that performs strict post-handshake checks.
+ * We need to provide standard-compliant mechanisms for certificate enrollment (CSR and EST) within the TOE.
+* **2.3 Requirements:**
+ * **OS**: Android OS (Targeting TOE environment).
+ * **Standards**: RFC 8603 (CNSA) algorithm constraints, RFC 9580 (relevant if OpenPGP style headers are used, but primarily standard X.509/TLS focus here).
+ * Support for custom TrustAnchor and isolated TrustStore.
+* **2.4 Schedule:**
+ * *TBD (To be defined after design finalization)*
+
+**3. High-Level Design and Architecture**
+
+* **3.1 System Context:**
+ * The library will be integrated into the TOE (Android application). It will be used in conjunction with HTTP clients like OkHttp or direct `SSLSocket` usage to enforce strict security policies.
+* **3.2 Architectural Overview:**
+ * **Module 1: Validation Core (Android Archive - AAR)**
+ * **NiapCertValidator**: Core logic for strict X.509 checks. Specific restrictions to be enforced include:
+ * **Algorithm Constraints**: Restrict to RFC 8603 (CNSA) profiles (e.g., enforcing SHA-384 with ECDSA P-384).
+ * **Mandatory Extension Checks**: Verify presence of AKID (Authority Key Identifier), SKID (Subject Key Identifier), and KeyUsage.
+ * **Field Enforcement**: Strict checking of Basic Constraints, EKU (Extended Key Usage), and Name Constraints (which Conscrypt may ignore).
+ * **Revocation Checks**: Enforce OCSP Stapling and support fallback to Out-of-Band CRL fetching.
+ * **Network Security Features** (Carried over from NIAPSEC/SecureURL):
+ * Enforce HTTPS (blocking non-secure connections).
+ * Hostname and TLD validation.
+ * **Config Support**: Ability to read these strict validation rules and policies from an **XML file placed in resources** (e.g., `res/xml/niap_security_config.xml`).
+ * **Helpers / Integration**: Provide easy integration for:
+ * **OkHttp3**: Via `Interceptor` or custom `X509TrustManager`.
+ * **Ktor**: Via engine-specific TLS configuration using custom `TrustManager`.
+ * **java.net**: Via custom `SSLSocketFactory` applied to `HttpsURLConnection`.
+ * **Module 2: Certificate Management (Execution Module)**
+ * **CSR Generator**: Generates PKCS#10 CSRs using Bouncy Castle.
+ * **EST Client**: Handles certificate acquisition via EST.
+ * **Form Factor Options**:
+ * *Option A (Library)*: Included in the AAR, called directly by the app.
+ * *Option B (Service)*: An Android Service in a dedicated application (APK) to satisfy the "executable" requirement and allow IPC (Inter-Process Communication).
+* **3.3 Key Design Decisions:**
+ * **Language**: Java / Kotlin for Android SDK.
+ * **Libraries**: Bouncy Castle (for CSR generation and advanced crypto operations not supported by default Android providers).
+ * **Integration**: Transport-agnostic validator to allow use in different layers (Socket, HTTP).
diff --git a/niap-cc/niap-android-cert-ext/est-server/Dockerfile b/niap-cc/niap-android-cert-ext/est-server/Dockerfile
new file mode 100644
index 0000000..66f8a21
--- /dev/null
+++ b/niap-cc/niap-android-cert-ext/est-server/Dockerfile
@@ -0,0 +1,129 @@
+# =============================================================================
+# EST Validation Server โ Multi-stage Docker Build
+# Based on Cisco libest (https://github.com/cisco/libest)
+# Purpose: NIAP / Common Criteria Android certificate enrollment testing
+# =============================================================================
+
+# -----------------------------------------------------------------------------
+# Stage 1: builder
+# Compile libest from source on Ubuntu 22.04
+# -----------------------------------------------------------------------------
+FROM ubuntu:22.04 AS builder
+
+ENV DEBIAN_FRONTEND=noninteractive
+
+# Install build dependencies
+RUN apt-get update && apt-get install -y --no-install-recommends \
+ git \
+ build-essential \
+ autoconf \
+ automake \
+ libtool \
+ libssl-dev \
+ pkg-config \
+ ca-certificates \
+ && rm -rf /var/lib/apt/lists/*
+
+# Clone libest (pin branch/tag for reproducibility)
+# To update: run `git ls-remote https://github.com/cisco/libest HEAD`
+# and set LIBEST_REF to the new commit hash.
+ARG LIBEST_REF=main
+
+WORKDIR /build
+RUN git clone --depth 1 --branch ${LIBEST_REF} \
+ https://github.com/cisco/libest.git libest \
+ && cd libest \
+ && git rev-parse HEAD | tee /LIBEST_COMMIT \
+ && echo "Cloned libest at commit: $(cat /LIBEST_COMMIT)"
+
+# NIAP requirement: use SHA-384 for certificate signing (default is SHA-256)
+# Compliance with FIA_X509_EXT and related PP requirements
+RUN sed -i 's/^default_md[[:space:]]*=.*/default_md = sha384/' \
+ /build/libest/example/server/estExampleCA.cnf \
+ && echo "=== SHA setting verification ===" \
+ && grep -n "default_md" /build/libest/example/server/estExampleCA.cnf
+
+# Build libest core library
+WORKDIR /build/libest
+# Two known issues fixed here:
+# 1. configure.ac has duplicate AM_INIT_AUTOMAKE (fatal error on Ubuntu 22.04 autotools)
+# 2. estclient.c references FIPS_mode/FIPS_mode_set removed in OpenSSL 3.x
+# โ estclient is not needed; build only the core library (src/)
+#
+# ARM64 note: libest's estserver.c uses `char c` for the getopt return value.
+# On ARM64 Linux, char is unsigned by default, so getopt's end-of-options (-1)
+# becomes 255 and never terminates the option loop โ show_usage_and_exit() called.
+# Fix: CFLAGS="-fsigned-char" forces signed char behavior.
+RUN awk 'BEGIN{n=0} /AM_INIT_AUTOMAKE/{n++; if(n==2)next} {print}' \
+ configure.ac > /tmp/configure.ac.patched \
+ && mv /tmp/configure.ac.patched configure.ac \
+ && echo "=== AM_INIT_AUTOMAKE count (must be 1) ===" \
+ && grep -c "AM_INIT_AUTOMAKE" configure.ac \
+ && autoreconf --force --install --verbose 2>&1 | tail -5 \
+ && ./configure --disable-safec CFLAGS="-fsigned-char" \
+ # Build order:
+ # 1. safe_c_stub โ produces libsafe_lib.a
+ # 2. Inject FIPS compat stubs into libsafe_lib.a (OpenSSL 3.x support)
+ # 3. src โ produces libest.so
+ && make -j"$(nproc)" -C safe_c_stub \
+ # OpenSSL 3.x compatibility:
+ # FIPS_mode / FIPS_mode_set were removed in OpenSSL 3.0.
+ # libest was written for OpenSSL 1.x, so we provide stub implementations.
+ # Injecting into libsafe_lib.a resolves the symbols for both libest.so
+ # and the estserver binary at link time.
+ && printf 'int FIPS_mode_set(int r){(void)r;return 0;}\nint FIPS_mode(void){return 0;}\n' \
+ > /tmp/fips_compat.c \
+ && gcc -c -o /tmp/fips_compat.o /tmp/fips_compat.c \
+ && ar rcs /build/libest/safe_c_stub/lib/libsafe_lib.a /tmp/fips_compat.o \
+ && echo "=== FIPS compat stubs injected into libsafe_lib.a ===" \
+ && make -j"$(nproc)" -C src
+
+# Build EST sample server binary only (skip estclient which has FIPS references)
+WORKDIR /build/libest/example/server
+RUN make -j"$(nproc)" \
+ && echo "=== Build artifact ===" \
+ && ls -lh estserver \
+ && file estserver
+
+# -----------------------------------------------------------------------------
+# Stage 2: runtime
+# Minimal runtime: NGINX + OpenSSL + compiled estserver binary
+# -----------------------------------------------------------------------------
+FROM ubuntu:22.04
+
+ENV DEBIAN_FRONTEND=noninteractive
+
+# Install runtime dependencies only
+RUN apt-get update && apt-get install -y --no-install-recommends \
+ nginx \
+ openssl \
+ libssl3 \
+ curl \
+ && rm -rf /var/lib/apt/lists/*
+
+# Copy compiled estserver binary
+# Note: example/server/estserver is a libtool wrapper script.
+# The actual binary is at .libs/estserver
+COPY --from=builder /build/libest/example/server/.libs/estserver /usr/local/bin/estserver
+
+# Copy libest shared library and update linker cache
+COPY --from=builder /build/libest/src/est/.libs/libest-*.so /usr/local/lib/
+RUN ln -sf /usr/local/lib/libest-*.so /usr/local/lib/libest.so && ldconfig
+
+# Copy sample server working directory (contains CA config files)
+COPY --from=builder /build/libest/example/server/ /opt/estserver/
+
+# Record the libest commit used in this image for reproducibility
+COPY --from=builder /LIBEST_COMMIT /opt/estserver/LIBEST_COMMIT
+
+# Copy runtime config files
+COPY nginx.conf /etc/nginx/nginx.conf
+COPY entrypoint.sh /entrypoint.sh
+RUN chmod +x /entrypoint.sh
+
+# Port definitions:
+# 8443 = EST endpoints (HTTPS + mTLS)
+# 8080 = Admin HTTP (CA cert download, health check)
+EXPOSE 8080 8443
+
+CMD ["/entrypoint.sh"]
diff --git a/niap-cc/niap-android-cert-ext/est-server/README.md b/niap-cc/niap-android-cert-ext/est-server/README.md
new file mode 100644
index 0000000..15bb417
--- /dev/null
+++ b/niap-cc/niap-android-cert-ext/est-server/README.md
@@ -0,0 +1,590 @@
+# EST Validation Server โ Setup Guide
+
+> **Purpose**: EST (Enrollment over Secure Transport) server for testing NIAP / Common Criteria
+> Android certificate enrollment. Cisco libest + NGINX in a single container.
+>
+> **Deployment options:**
+>
+> | Option | Environment | EST enroll | mTLS test | Docker required |
+> |--------|------------|-----------|-----------|-----------------|
+> | **Cloud Run** | Company device, any machine | โ
| โ | No |
+> | **Cloud Run + LB** | Company GCP with budget | โ
| โ
| No |
+> | **Local Docker** | Personal dev machine only | โ
| โ
| Yes |
+>
+> `gcloud run deploy --source .` builds on Google Cloud Build โ
+> no local Docker installation required.
+
+---
+
+## Architecture Overview
+
+```
+Android device / emulator
+ โ
+ โ HTTPS (mTLS optional) :8443 โ EST protocol
+ โ HTTPS (mTLS required) :8081 โ mTLS test endpoint
+ โผ
+โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
+โ Docker container โ
+โ โ
+โ NGINX :8443 (HTTPS + mTLS optional) โ
+โ โโ proxy โโโถ libest :8085 โ
+โ โโ issues certs (CA) โ
+โ โ
+โ NGINX :8081 (HTTPS + mTLS required) โ
+โ โโ /protected/ โ mTLS test โ
+โ โ
+โ NGINX :8080 (HTTP) โ
+โ โโ /cacert.pem โ CA cert download โ
+โ โโ /health โ health check โ
+โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
+ โ
+ โ HTTP :8080
+ โผ
+Developer browser (CA cert download)
+```
+
+### CA Certificate Role
+
+A throwaway Root CA is auto-generated on first container start. This CA:
+1. Signs the server's TLS certificate (used by NGINX)
+2. Signs CSRs from Android clients (used by libest)
+
+---
+
+## Prerequisites
+
+### Cloud Run deployment (no Docker needed)
+
+| Tool | Check |
+|------|-------|
+| gcloud CLI | `gcloud version` |
+| GCP project with billing enabled | โ |
+
+```bash
+# Install gcloud CLI (example for macOS via Homebrew)
+brew install --cask google-cloud-sdk
+# Add to profile (e.g., ~/.zshrc): export PATH=/opt/homebrew/share/google-cloud-sdk/bin:"$PATH"
+gcloud auth login
+gcloud config set project
+```
+
+### Local Docker (personal dev machine only)
+
+| Tool | Version | Check |
+|------|---------|-------|
+| Docker | 20.x+ | `docker --version` |
+| Docker Compose | v2+ | `docker compose version` |
+| curl | any | `curl --version` |
+
+Internet access is required at image build time (to clone libest). After startup the server runs fully offline.
+
+---
+
+## Certificate Profiles
+
+Set `EST_CERT_PROFILE` in `docker-compose.yml`:
+
+| Profile | Purpose | CA key | Server key | Signature | NIAP validator |
+|---------|---------|--------|-----------|-----------|----------------|
+| `general` | Basic EST verification | RSA-4096 | RSA-2048 | SHA-256 | โ not compliant |
+| `niap` | NIAP/CC validation | ECDSA P-384 | ECDSA P-384 | SHA-384 | โ
all checks pass |
+
+**NIAP profile server certificate extensions:**
+- AKID (2.5.29.35), SKID (2.5.29.14), KeyUsage (2.5.29.15) โ FIA_X509_EXT.1.2
+- EKU: `serverAuth` (1.3.6.1.5.5.7.3.1) โ NiapCertValidator.kt
+- EKU: `id-kp-cmcRA` (1.3.6.1.5.5.7.3.28) โ FIA_XCU_EXT.1.md ยง5 EST-specific requirement
+- basicConstraints: CA:FALSE
+
+**Client certificates issued by libest (both profiles):**
+- SHA-384 signature, AKID, SKID, KeyUsage, EKU (clientAuth)
+
+---
+
+## Setup
+
+### 1. Check out the repository
+
+```bash
+git clone
+cd niap-android-cert-ext/est-server
+```
+
+### 2. Build the Docker image
+
+Clones and compiles libest from source. **First build takes 5โ10 minutes.**
+
+```bash
+docker compose build
+```
+
+Verify the build log output:
+```
+=== SHA setting verification ===
+default_md = sha384 โ NIAP SHA-384 requirement in place
+=== Build artifact ===
+estserver: ELF 64-bit LSB executable โ binary built successfully
+```
+
+> **Reproducibility**: After startup, check the libest commit used with:
+> `docker exec est-validation-server cat /opt/estserver/LIBEST_COMMIT`
+> Record this in your test report.
+
+### 3. Start the server
+
+```bash
+docker compose up -d
+```
+
+Wait for the health check to pass:
+```bash
+docker compose ps
+# est-validation-server ... healthy
+```
+
+Watch the CA initialization log:
+```bash
+docker compose logs -f
+```
+
+Expected output:
+```
+[est-entrypoint] CA initialization complete. CA certificate info:
+[est-entrypoint] EST server startup confirmed.
+[est-entrypoint] Starting NGINX [profile: general]
+[est-entrypoint] EST (HTTPS + mTLS): https://localhost:8443/.well-known/est/
+[est-entrypoint] CA cert: http://localhost:8080/cacert.pem
+```
+
+### 4. Smoke test (curl)
+
+```bash
+# Health check
+curl http://localhost:8080/health
+# โ OK
+
+# CA cert info
+curl -s http://localhost:8080/cacert.pem | openssl x509 -noout -subject -dates
+# โ subject=C=JP, ST=Tokyo, O=NIAP Test Lab, CN=EST Validation Root CA
+
+# EST /cacerts endpoint
+curl -ks --cacert <(curl -s http://localhost:8080/cacert.pem) \
+ https://localhost:8443/.well-known/est/cacerts \
+ | openssl base64 -d | openssl pkcs7 -inform DER -print_certs -noout
+
+# EST /simpleenroll
+openssl req -newkey rsa:2048 -nodes -keyout /tmp/client.key \
+ -subj "/CN=test-client" -out /tmp/client.csr 2>/dev/null
+curl -sk \
+ --cacert <(curl -s http://localhost:8080/cacert.pem) \
+ -u "estuser:estpwd" \
+ -H "Content-Type: application/pkcs10" \
+ --data-binary @/tmp/client.csr \
+ https://localhost:8443/.well-known/est/simpleenroll \
+ | openssl base64 -d | openssl pkcs7 -inform DER -print_certs -noout
+# โ subject=CN=test-client
+```
+
+### 4.5. Test the mTLS endpoint manually (curl)
+
+Once you have successfully enrolled a client certificate in the previous step, you can verify the mTLS enforcement endpoint on port `8081` using standard command line tools.
+
+1. **Extract the client certificate to a PEM file**:
+ ```bash
+ # Convert the returned PKCS#7 bundle from simpleenroll into standard PEM format
+ curl -sk \
+ --cacert <(curl -s http://localhost:8080/cacert.pem) \
+ -u "estuser:estpwd" \
+ -H "Content-Type: application/pkcs10" \
+ --data-binary @/tmp/client.csr \
+ https://localhost:8443/.well-known/est/simpleenroll \
+ | openssl base64 -d | openssl pkcs7 -inform DER -print_certs -out /tmp/client.crt
+ ```
+
+2. **Verify the issued certificate meets NIAP requirements (SHA-384 / ECDSA P-384 / clientAuth)**:
+ ```bash
+ openssl x509 -in /tmp/client.crt -noout -text | grep -E "Signature Algorithm|Public Key Algorithm|ASN1 OID|Extended Key Usage" -A 1
+ # Expected Output:
+ # Signature Algorithm: ecdsa-with-SHA384
+ # Public Key Algorithm: id-ecPublicKey
+ # ASN1 OID: secp384r1
+ # Extended Key Usage:
+ # TLS Web Client Authentication
+ ```
+
+3. **Establish an mTLS session using the issued client key and cert**:
+ ```bash
+ curl -v -k --cacert <(curl -s http://localhost:8080/cacert.pem) \
+ --key /tmp/client.key \
+ --cert /tmp/client.crt \
+ https://localhost:8081/protected/
+
+ # Expected HTTP Response: 200 OK
+ # Body output should contain:
+ # mTLS OK
+ # Client: C=JP, ST=Tokyo, O=NIAP Test Lab, CN=test-client
+ ```
+
+---
+
+
+## Switching to NIAP Profile
+
+```bash
+# Edit docker-compose.yml: set EST_CERT_PROFILE=niap, then restart
+docker compose down
+docker compose up -d
+docker compose logs -f # watch NIAP cert generation
+
+# Verify server cert NIAP extensions
+docker exec est-validation-server \
+ openssl x509 -in /opt/estserver/estCA/private/estserver.crt -noout -text \
+ | grep -A 5 "Extended Key Usage"
+# โ Server Authentication (1.3.6.1.5.5.7.3.1) โ
+# โ 1.3.6.1.5.5.7.3.28 (cmcRA) โ
+```
+
+---
+
+## Android App Integration
+
+### 5. Download and deploy the CA cert
+
+The Android emulator reaches the host machine at `10.0.2.2`. For a real device on USB,
+use the host machine's LAN IP or set up ADB port forwarding.
+
+```bash
+# Download CA cert
+curl -o cacert.pem http://localhost:8080/cacert.pem
+
+# Place in app's raw resources
+cp cacert.pem \
+ ../cert-test-app/src/main/res/raw/est_validation_ca.pem
+```
+
+### 6. Configure the Android app
+
+| Setting | Value |
+|---------|-------|
+| EST server URL (emulator) | `https://10.0.2.2:8443/.well-known/est/` |
+| EST server URL (real device) | `https://:8443/.well-known/est/` |
+| Trust anchor | downloaded `cacert.pem` |
+| Auth | `estuser:estpwd` |
+
+### 7. Connectivity check from the device
+
+```bash
+# Emulator
+adb shell nc -w 2 10.0.2.2 8443 < /dev/null; echo $? # 0 = connected
+
+# Real device via ADB port forward
+adb reverse tcp:8443 tcp:8443
+adb reverse tcp:8080 tcp:8080
+# then use https://localhost:8443/.well-known/est/ in the app
+```
+
+### 8. Manual test with the cert-test-app (real device)
+
+Set up ADB port forwarding first (run on the host machine each time you reconnect the device):
+
+```bash
+adb reverse tcp:8443 tcp:8443 # EST/HTTPS (NGINX โ Host)
+adb reverse tcp:8081 tcp:8081 # mTLS test endpoint (NGINX โ Host)
+adb reverse tcp:8080 tcp:8080 # HTTP admin / CA cert download (NGINX โ Host)
+```
+
+App settings to use:
+
+| Field | Value |
+|-------|-------|
+| EST Server URL | `https://localhost:8443/.well-known/est/` |
+| Auth Token | `estuser:estpwd` |
+| CA PEM URL | `http://localhost:8080/cacert.pem` |
+| mTLS Endpoint | `https://localhost:8081/protected/` |
+
+The app downloads the CA PEM automatically from the CA PEM URL on each Enroll attempt.
+Leave CA PEM URL blank only if you have embedded the CA cert as a raw resource (`est_validation_ca`) in the app.
+
+> **Note**: `adb reverse` must be re-run after every device reconnect (USB unplug/replug or `adb kill-server`).
+
+---
+
+## Troubleshooting
+
+### Build fails
+
+**Symptom**: errors during `autogen.sh` or `make`
+
+- Docker memory allocation must be โฅ 4 GB (Docker Desktop โ Settings โ Resources)
+- Internet access required for libest clone
+
+```bash
+# Rebuild without cache
+docker compose build --no-cache
+```
+
+### `estserver` exits immediately
+
+**Symptom**: log shows "EST server exited immediately"
+
+**Known root cause (ARM64 / Apple Silicon)**: libest's `estserver.c` declares `char c` for the
+getopt return value. On ARM64 Linux, `char` is unsigned by default, so getopt's end-of-options
+sentinel (-1) becomes 255, falls through to `default:`, and calls `show_usage_and_exit()`.
+Fixed by building with `CFLAGS="-fsigned-char"` (already in the Dockerfile).
+
+Other causes:
+- `libest.so` link error โ `ldd /usr/local/bin/estserver`
+- CA directory permission issue โ `ls -la /opt/estserver/estCA/`
+
+```bash
+# Manual test inside container
+docker exec -it est-validation-server bash
+cd /opt/estserver
+estserver -p 8085 \
+ -c estCA/private/estservercertandkey.pem \
+ -k estCA/private/estservercertandkey.pem \
+ -r estrealm -v
+```
+
+### Cannot connect from Android
+
+**Symptom**: TLS handshake error or timeout
+
+1. Check TCP connectivity: `adb shell nc -w 2 10.0.2.2 8443 < /dev/null`
+2. Test with curl: `curl -v --cacert cacert.pem https://10.0.2.2:8443/.well-known/est/cacerts`
+3. Verify the `cacert.pem` in the app matches the current container CA
+
+> **Note**: `docker compose down` โ `up` generates a **new CA**. Re-download `cacert.pem`
+> and update the app's trust anchor each time you recreate the container.
+
+### Persist CA across restarts
+
+```bash
+docker run -d \
+ -v est-ca-data:/opt/estserver/estCA \
+ -p 8443:8443 -p 8080:8080 \
+ est-validation-server:local
+```
+
+---
+
+## Stop and Clean Up
+
+```bash
+docker compose down
+
+# Remove image too (requires rebuild)
+docker compose down --rmi local
+```
+
+---
+
+## Cloud Run Deployment (optional)
+
+> **Note on TLS trust**: Cloud Run presents a Google-signed certificate. When using this endpoint
+> from the Android app, leave CA PEM URL blank or do not apply the downloaded CA cert as the TLS
+> trust anchor โ use the system trust store instead. The CA PEM is still needed to validate issued
+> client certificates.
+
+---
+
+### Architecture and limitations
+
+Cloud Run terminates TLS at Google's infrastructure before the request reaches the container.
+As a result:
+
+| Feature | Cloud Run only | Cloud Run + LB |
+|---------|---------------|----------------|
+| EST enroll (`/simpleenroll`) | โ
| โ
|
+| CA cert download (`/cacert.pem`) | โ
| โ
|
+| mTLS test (`/protected/`) | โ | โ
|
+
+**Why mTLS does not work on Cloud Run alone:**
+The client certificate is stripped at the Cloud Run proxy โ nginx inside the container never
+receives it, so `ssl_verify_client` has no effect.
+
+---
+
+### Option A: Cloud Run only (EST enroll, no mTLS test)
+
+This is the current setup. **Local Docker is not required** โ `gcloud run deploy --source .`
+builds the container on Google Cloud Build, so deployment works from any machine with the
+gcloud CLI installed (including company devices where Docker is unavailable).
+
+For Android app configuration when using Cloud Run:
+- EST Server URL: `https:///.well-known/est/`
+- CA PEM URL: leave blank (Cloud Run presents a Google-signed cert; system trust store is used)
+- mTLS endpoint: requires local Docker or Option B (Cloud LB)
+
+---
+
+### Option B: Cloud Run + Cloud Load Balancer (full mTLS on cloud) โ requires budget approval
+
+> This option is documented for reference when deploying to a company GCP environment with
+> an approved budget. The LB forwarding rule incurs a fixed charge (~$18/month) regardless
+> of traffic volume โ not suitable for personal accounts or short-term validation.
+
+Add a Cloud Load Balancer in front of Cloud Run to perform mTLS termination.
+The LB verifies the client certificate and forwards cert info as an HTTP header
+(`X-Forwarded-Client-Cert`) to Cloud Run, where nginx reads it.
+
+```
+Android device
+ โ HTTPS + client cert (mTLS)
+ โผ
+Cloud Load Balancer
+ โ - Verifies client cert against EST CA
+ โ - Adds X-Forwarded-Client-Cert header
+ โผ
+Cloud Run :8080
+ โ
+ โผ
+nginx /protected/
+ - Checks X-Forwarded-Client-Cert header
+ - 200 if present, 401 if absent
+```
+
+#### nginx change for `/protected/` on port 8080
+
+```nginx
+location /protected/ {
+ if ($http_x_forwarded_client_cert = "") {
+ return 401 "mTLS required\n";
+ }
+ add_header Content-Type "text/plain";
+ return 200 "mTLS OK\nClient-Cert: $http_x_forwarded_client_cert\n";
+}
+```
+
+#### Cloud LB setup
+
+```bash
+# 1. Create a serverless NEG for Cloud Run
+gcloud compute network-endpoint-groups create est-neg \
+ --region=asia-northeast1 \
+ --network-endpoint-type=serverless \
+ --cloud-run-service=est-validation-server
+
+# 2. Create backend service
+gcloud compute backend-services create est-backend \
+ --load-balancing-scheme=EXTERNAL_MANAGED \
+ --global
+
+gcloud compute backend-services add-backend est-backend \
+ --network-endpoint-group=est-neg \
+ --network-endpoint-group-region=asia-northeast1 \
+ --global
+
+# 3. Create URL map, HTTPS proxy, forwarding rule
+gcloud compute url-maps create est-url-map --default-service=est-backend
+gcloud compute ssl-certificates create est-cert --domains=
+gcloud compute target-https-proxies create est-https-proxy \
+ --url-map=est-url-map \
+ --ssl-certificates=est-cert
+gcloud compute forwarding-rules create est-forwarding-rule \
+ --load-balancing-scheme=EXTERNAL_MANAGED \
+ --target-https-proxy=est-https-proxy \
+ --global --ports=443
+
+# 4. Enable mTLS: upload EST CA cert as trust config
+gcloud certificate-manager trust-configs create est-trust-config \
+ --location=global \
+ --ca-certs=<(curl -s https:///cacert.pem)
+
+gcloud compute target-https-proxies update est-https-proxy \
+ --server-tls-policy=... # attach trust config via server TLS policy
+```
+
+> Once approved and deployed, this setup enables full cloud-based mTLS testing without
+> requiring Docker on the test device.
+
+---
+
+### Prerequisites (first-time setup)
+
+1. Create a GCP project and enable billing
+2. Install and configure gcloud CLI:
+ ```bash
+ # Example for macOS via Homebrew; adjust for other OS platforms:
+ brew install --cask google-cloud-sdk
+ # Add to profile configuration:
+ # export PATH=/opt/homebrew/share/google-cloud-sdk/bin:"$PATH"
+ source ~/.zshrc
+ gcloud auth login
+ gcloud config set project
+ ```
+3. Grant required IAM permissions to the default Compute Engine service account
+ (needed once per project โ Cloud Run source deploy requires these):
+ ```bash
+ SA="-compute@developer.gserviceaccount.com"
+ gcloud projects add-iam-policy-binding --member="serviceAccount:$SA" --role="roles/cloudbuild.builds.builder"
+ gcloud projects add-iam-policy-binding --member="serviceAccount:$SA" --role="roles/storage.objectAdmin"
+ gcloud projects add-iam-policy-binding --member="serviceAccount:$SA" --role="roles/artifactregistry.writer"
+ ```
+ > Find your project number: `gcloud projects describe --format="value(projectNumber)"`
+
+### Deploy
+
+```bash
+cd est-server
+gcloud run deploy est-validation-server \
+ --source . \
+ --region asia-northeast1 \
+ --allow-unauthenticated \
+ --max-instances 1 \
+ --memory 512Mi \
+ --port 8080
+```
+
+After deployment:
+- CA cert: `https:///cacert.pem`
+- Health: `https:///health`
+- EST enroll: `https:///.well-known/est/`
+- mTLS test (`/protected/`): requires Cloud LB (Option B) or local Docker
+
+---
+
+## Packet Capture (PCAP) for NIAP/CC Verification
+
+To provide cryptographic verification of the TLS and mTLS handshakes (e.g., confirming TLS 1.3 usage, client cert submission, and SHA-384 algorithms in TLS 1.2 `CertificateVerify`), evaluators can record traffic within the container using `tcpdump`.
+
+1. **Start packet capture on target interfaces inside the container**:
+ ```bash
+ docker exec -it est-validation-server tcpdump -i any -w /opt/estserver/handshake.pcap "port 8443 or port 8081"
+ ```
+
+2. **Execute your test case** (either through `curl` or the Android client app).
+
+3. **Stop the capture** with `Ctrl+C`.
+
+4. **Copy the PCAP file to the host machine for Wireshark analysis**:
+ ```bash
+ docker cp est-validation-server:/opt/estserver/handshake.pcap ./handshake.pcap
+ ```
+
+---
+
+## File Layout
+
+
+```
+est-server/
+โโโ Dockerfile Multi-stage build: compiles Cisco libest from source
+โโโ docker-compose.yml Local dev/test Compose definition
+โโโ nginx.conf mTLS reverse proxy (ports 8443/8080)
+โโโ entrypoint.sh CA init โ estserver start โ NGINX start
+โโโ README.md This guide
+```
+
+---
+
+## Version Info
+
+| Component | Version |
+|-----------|---------|
+| Base image | ubuntu:22.04 |
+| libest | main branch (commit pinned at build time) |
+| NGINX | Ubuntu 22.04 package |
+| OpenSSL | Ubuntu 22.04 package (libssl3) |
+| Signature algorithm | SHA-384 (NIAP requirement) |
+| ARM64 fix | `CFLAGS=-fsigned-char` (unsigned char getopt bug) |
diff --git a/niap-cc/niap-android-cert-ext/est-server/docker-compose.yml b/niap-cc/niap-android-cert-ext/est-server/docker-compose.yml
new file mode 100644
index 0000000..a0f8d30
--- /dev/null
+++ b/niap-cc/niap-android-cert-ext/est-server/docker-compose.yml
@@ -0,0 +1,29 @@
+services:
+ est-server:
+ build:
+ context: .
+ dockerfile: Dockerfile
+ args:
+ # libest branch/tag/commit hash (pin for reproducibility)
+ # Example: LIBEST_REF: "a464ba8a66717419ba71d289ef82c7b2315b2006"
+ # To find the latest commit: git ls-remote https://github.com/cisco/libest HEAD
+ LIBEST_REF: main
+ image: est-validation-server:local
+ container_name: est-validation-server
+ ports:
+ - "8443:8443" # EST endpoints (HTTPS + mTLS optional)
+ - "8081:8081" # mTLS test endpoint (HTTPS + mTLS required)
+ - "8080:8080" # Admin HTTP (CA cert download, health check)
+ environment:
+ - TZ=Asia/Tokyo
+ # Certificate profile:
+ # general = basic EST protocol verification (RSA-2048, SHA-256, minimal extensions)
+ # niap = full NIAP/CC validator compliance (ECDSA P-384, SHA-384, all extensions)
+ - EST_CERT_PROFILE=niap
+ healthcheck:
+ test: ["CMD", "curl", "-sf", "http://localhost:8080/health"]
+ interval: 10s
+ timeout: 5s
+ retries: 3
+ start_period: 20s
+ restart: unless-stopped
diff --git a/niap-cc/niap-android-cert-ext/est-server/entrypoint.sh b/niap-cc/niap-android-cert-ext/est-server/entrypoint.sh
new file mode 100644
index 0000000..78db070
--- /dev/null
+++ b/niap-cc/niap-android-cert-ext/est-server/entrypoint.sh
@@ -0,0 +1,338 @@
+#!/bin/bash
+# =============================================================================
+# EST Validation Server โ Entrypoint Script
+#
+# Certificate profile selection:
+# EST_CERT_PROFILE=general (default) โ basic protocol verification
+# EST_CERT_PROFILE=niap โ passes all NIAP/CC validator checks
+#
+# Directory layout (follows libest ESTcommon.sh conventions):
+# /opt/estserver/
+# estExampleCA.cnf โ CA config (used by openssl ca)
+# trustedcerts.crt โ EST_TRUSTED_CERTS (client cert verification)
+# estCA/
+# cacert.crt โ EST_CACERTS_RESP (CA cert returned by /cacerts)
+# index.txt, serial, newcerts/ โ OpenSSL CA database
+# private/
+# cakey.pem โ CA private key
+# estserver.key โ Server private key
+# estserver.crt โ Server certificate
+# estservercertandkey.pem โ cert+key combined (used for -c/-k args)
+# estserver-chain.pem โ cert+CACert chain (used by NGINX ssl_certificate)
+#
+# NIAP requirements (NiapCertValidator.kt):
+# - Signature: SHA-384 or stronger
+# - Key size: RSA-3072+ or ECDSA P-384+
+# - Mandatory extensions: AKID(2.5.29.35), SKID(2.5.29.14), KeyUsage(2.5.29.15)
+# - EKU: serverAuth (1.3.6.1.5.5.7.3.1)
+# - basicConstraints: CA:FALSE (leaf cert)
+# - EST-specific (FIA_XCU_EXT.1.md ยง5): cmcRA OID (1.3.6.1.5.5.7.3.28)
+# =============================================================================
+set -euo pipefail
+
+WORK_DIR="/opt/estserver"
+CA_DIR="${WORK_DIR}/estCA"
+PRIV_DIR="${CA_DIR}/private"
+PROFILE="${EST_CERT_PROFILE:-general}"
+LOG_TAG="[est-entrypoint]"
+
+log() { echo "${LOG_TAG} $*"; }
+die() { echo "${LOG_TAG} ERROR: $*" >&2; exit 1; }
+
+log "=================================================="
+log " EST Validation Server starting"
+log " Certificate profile: ${PROFILE}"
+log "=================================================="
+
+# =============================================================================
+# Step 1: Write CA config file used by libest
+# (directory layout follows ESTcommon.sh variable conventions)
+# =============================================================================
+log "Writing estExampleCA.cnf..."
+cat > "${WORK_DIR}/estExampleCA.cnf" << 'OPENSSL_CA_CNF_EOF'
+# EST Sample CA config (NIAP/CC compliant)
+# Path conventions follow ESTcommon.sh:
+# EST_OPENSSL_CAPRIVKEY = estCA/private/cakey.pem
+# EST_OPENSSL_CACERT = estCA/cacert.crt
+
+[ ca ]
+default_ca = CA_default
+
+[ CA_default ]
+dir = ./estCA
+certs = $dir/certs
+crl_dir = $dir/crl
+database = $dir/index.txt
+new_certs_dir = $dir/newcerts
+certificate = $dir/cacert.crt
+serial = $dir/serial
+private_key = $dir/private/cakey.pem
+x509_extensions = usr_cert
+default_days = 365
+default_crl_days = 30
+# NIAP requirement: SHA-384 or stronger (FIA_X509_EXT.1.1 / RFC 8603 CNSA)
+default_md = sha384
+preserve = no
+policy = policy_match
+# Allow re-enrollment with the same subject name (required for EST /reenroll)
+unique_subject = no
+
+[ policy_match ]
+countryName = optional
+stateOrProvinceName = optional
+organizationName = optional
+organizationalUnitName = optional
+commonName = supplied
+emailAddress = optional
+
+[ req ]
+default_bits = 3072
+default_md = sha384
+distinguished_name = req_distinguished_name
+attributes = req_attributes
+
+[ req_distinguished_name ]
+countryName = Country Name (2 letter code)
+stateOrProvinceName = State or Province Name
+organizationName = Organization Name
+commonName = Common Name
+
+[ req_attributes ]
+
+# ---------------------------------------------------------------------------
+# [ usr_cert ] โ extensions for client certs issued by libest via /simpleenroll
+# Compliant with NIAP FIA_X509_EXT.1.2:
+# - basicConstraints: CA:FALSE (end-entity)
+# - AKID, SKID: required (2.5.29.35, 2.5.29.14)
+# - KeyUsage: required (2.5.29.15)
+# - EKU: clientAuth (for TLS client authentication)
+# ---------------------------------------------------------------------------
+[ usr_cert ]
+basicConstraints = CA:FALSE
+subjectKeyIdentifier = hash
+authorityKeyIdentifier = keyid,issuer
+keyUsage = critical,digitalSignature
+extendedKeyUsage = clientAuth
+
+[ v3_ca ]
+basicConstraints = critical,CA:true,pathlen:0
+subjectKeyIdentifier = hash
+authorityKeyIdentifier = keyid:always,issuer
+keyUsage = critical,keyCertSign,cRLSign
+OPENSSL_CA_CNF_EOF
+
+log "estExampleCA.cnf written."
+
+# =============================================================================
+# Step 2: Initialize CA (first boot only)
+# =============================================================================
+if [ -f "${PRIV_DIR}/estservercertandkey.pem" ]; then
+ log "CA already initialized. Skipping."
+else
+ log "=================================================="
+ log " Initializing Certificate Authority [${PROFILE}]"
+ log "=================================================="
+
+ # Create directory layout expected by libest
+ mkdir -p "${CA_DIR}/newcerts" "${CA_DIR}/certs" "${CA_DIR}/crl" "${PRIV_DIR}"
+ chmod 700 "${PRIV_DIR}"
+ touch "${CA_DIR}/index.txt"
+ echo "unique_subject = no" > "${CA_DIR}/index.txt.attr"
+ echo "01" > "${CA_DIR}/serial"
+
+ cd "${WORK_DIR}"
+
+ if [ "${PROFILE}" = "niap" ]; then
+ # ------------------------------------------------------------------
+ # NIAP profile
+ # CA: ECDSA P-384, SHA-384
+ # ------------------------------------------------------------------
+ log "[NIAP] Generating Root CA (ECDSA P-384, SHA-384)..."
+
+ openssl ecparam -name secp384r1 -genkey -noout \
+ -out "${PRIV_DIR}/cakey.pem"
+ chmod 600 "${PRIV_DIR}/cakey.pem"
+
+ openssl req -new -x509 \
+ -sha384 \
+ -days 3650 \
+ -key "${PRIV_DIR}/cakey.pem" \
+ -out "${CA_DIR}/cacert.crt" \
+ -subj "/C=JP/ST=Tokyo/O=NIAP Test Lab/CN=EST Validation Root CA" \
+ -extensions v3_ca \
+ -config "${WORK_DIR}/estExampleCA.cnf"
+
+ log "[NIAP] Generating server certificate (ECDSA P-384, SHA-384, full NIAP extensions)..."
+
+ openssl ecparam -name secp384r1 -genkey -noout \
+ -out "${PRIV_DIR}/estserver.key"
+ chmod 600 "${PRIV_DIR}/estserver.key"
+
+ # Server certificate extensions (mandatory NIAP extensions + EST-specific EKU)
+ cat > "${WORK_DIR}/server_ext.cnf" << 'SERVER_EXT_EOF'
+[ server_cert ]
+# FIA_X509_EXT.1.2: AKID, SKID, KeyUsage required
+basicConstraints = CA:FALSE
+subjectKeyIdentifier = hash
+authorityKeyIdentifier = keyid,issuer
+keyUsage = critical,digitalSignature
+# EKU:
+# serverAuth (1.3.6.1.5.5.7.3.1) โ TLS server authentication (NiapCertValidator.kt)
+# id-kp-cmcRA (1.3.6.1.5.5.7.3.28) โ EST-specific requirement (FIA_XCU_EXT.1.md ยง5)
+extendedKeyUsage = serverAuth,1.3.6.1.5.5.7.3.28
+# SAN: Android emulator access (10.0.2.2 = host machine) and real device via host IP
+subjectAltName = @san_names
+
+[ san_names ]
+DNS.1 = est-server
+DNS.2 = localhost
+IP.1 = 127.0.0.1
+IP.2 = 10.0.2.2
+
+[ req ]
+distinguished_name = req_dn
+[ req_dn ]
+SERVER_EXT_EOF
+
+ openssl req -new \
+ -sha384 \
+ -key "${PRIV_DIR}/estserver.key" \
+ -out "${CA_DIR}/estserver.csr" \
+ -subj "/C=JP/ST=Tokyo/O=NIAP Test Lab/CN=est-server"
+
+ openssl x509 -req \
+ -sha384 \
+ -days 397 \
+ -in "${CA_DIR}/estserver.csr" \
+ -CA "${CA_DIR}/cacert.crt" \
+ -CAkey "${PRIV_DIR}/cakey.pem" \
+ -CAcreateserial \
+ -out "${PRIV_DIR}/estserver.crt" \
+ -extfile "${WORK_DIR}/server_ext.cnf" \
+ -extensions server_cert
+
+ log "[NIAP] Server certificate extensions:"
+ openssl x509 -in "${PRIV_DIR}/estserver.crt" -noout -text \
+ | grep -A 20 "X509v3 extensions:"
+
+ else
+ # ------------------------------------------------------------------
+ # General profile (basic protocol verification)
+ # CA: RSA-4096, SHA-256 / Server: RSA-2048, SHA-256
+ # ------------------------------------------------------------------
+ log "[General] Generating Root CA (RSA-4096, SHA-256)..."
+
+ openssl req -x509 \
+ -newkey rsa:4096 \
+ -sha256 \
+ -days 3650 \
+ -nodes \
+ -keyout "${PRIV_DIR}/cakey.pem" \
+ -out "${CA_DIR}/cacert.crt" \
+ -subj "/C=JP/ST=Tokyo/O=NIAP Test Lab/CN=EST Validation Root CA" \
+ -addext "basicConstraints=critical,CA:true" \
+ -addext "subjectKeyIdentifier=hash" \
+ -addext "keyUsage=critical,keyCertSign,cRLSign"
+ chmod 600 "${PRIV_DIR}/cakey.pem"
+
+ log "[General] Generating server certificate (RSA-2048, SHA-256)..."
+
+ openssl req -newkey rsa:2048 \
+ -nodes \
+ -keyout "${PRIV_DIR}/estserver.key" \
+ -out "${CA_DIR}/estserver.csr" \
+ -subj "/C=JP/ST=Tokyo/O=NIAP Test Lab/CN=est-server"
+ chmod 600 "${PRIV_DIR}/estserver.key"
+
+ # General profile does not need NIAP validator compliance;
+ # a simple cert without extensions is sufficient for EST protocol verification.
+ openssl x509 -req \
+ -sha256 \
+ -days 365 \
+ -in "${CA_DIR}/estserver.csr" \
+ -CA "${CA_DIR}/cacert.crt" \
+ -CAkey "${PRIV_DIR}/cakey.pem" \
+ -CAcreateserial \
+ -out "${PRIV_DIR}/estserver.crt"
+ fi
+
+ # ------------------------------------------------------------------
+ # Create combined PEM files required by estserver
+ # (cert+key โ passed to both -c and -k arguments)
+ # ------------------------------------------------------------------
+ cat "${PRIV_DIR}/estserver.crt" "${PRIV_DIR}/estserver.key" \
+ > "${PRIV_DIR}/estservercertandkey.pem"
+ chmod 600 "${PRIV_DIR}/estservercertandkey.pem"
+
+ # Certificate chain for NGINX (server cert + CA cert)
+ cat "${PRIV_DIR}/estserver.crt" "${CA_DIR}/cacert.crt" \
+ > "${PRIV_DIR}/estserver-chain.pem"
+
+ # EST_TRUSTED_CERTS: trust store for verifying client certificates
+ cp "${CA_DIR}/cacert.crt" "${WORK_DIR}/trustedcerts.crt"
+
+ log "CA initialization complete. CA certificate info:"
+ openssl x509 -in "${CA_DIR}/cacert.crt" -noout \
+ -subject -issuer -dates -fingerprint -sha256
+ log "libest commit: $(cat ${WORK_DIR}/LIBEST_COMMIT)"
+fi
+
+# =============================================================================
+# Step 3: Expose CA cert via HTTP for Android TrustStore setup
+# =============================================================================
+mkdir -p /var/www/html
+cp "${CA_DIR}/cacert.crt" /var/www/html/cacert.pem
+log "CA cert available at: http://localhost:8080/cacert.pem"
+
+# =============================================================================
+# Step 4: Start libest EST server (port 8085, TLS)
+# =============================================================================
+log "=================================================="
+log " Starting libest EST server (port 8085, TLS)"
+log "=================================================="
+
+# Environment variables used by libest (same naming as ESTcommon.sh)
+export EST_TRUSTED_CERTS="${WORK_DIR}/trustedcerts.crt"
+export EST_CACERTS_RESP="${CA_DIR}/cacert.crt"
+export EST_OPENSSL_CACONFIG="${WORK_DIR}/estExampleCA.cnf"
+
+cd "${WORK_DIR}"
+
+# estserver arguments (per runserver.sh):
+# -c/-k: combined cert+key PEM (same file for both)
+# -r: HTTP Basic auth realm
+# -v: verbose logging
+# -p: listen port (default 8085)
+estserver \
+ -p 8085 \
+ -c "estCA/private/estservercertandkey.pem" \
+ -k "estCA/private/estservercertandkey.pem" \
+ -r "estrealm" \
+ -v &
+
+EST_PID=$!
+log "EST server PID: ${EST_PID}"
+
+# Wait up to 15 seconds for startup confirmation
+for i in $(seq 1 15); do
+ sleep 1
+ if ! kill -0 "${EST_PID}" 2>/dev/null; then
+ die "EST server exited immediately. Check 'docker compose logs' for details."
+ fi
+done
+log "EST server startup confirmed."
+
+# =============================================================================
+# Step 5: Start NGINX
+# NGINX terminates TLS/mTLS on 8443 and reverse-proxies to estserver on 8085
+# =============================================================================
+log "=================================================="
+log " Starting NGINX [profile: ${PROFILE}]"
+log " EST (HTTPS + mTLS optional): https://localhost:8443/.well-known/est/"
+log " mTLS test (HTTPS + mTLS req): https://localhost:8081/protected/"
+log " Admin (HTTP): http://localhost:8080/"
+log " CA cert: http://localhost:8080/cacert.pem"
+log " Health check: http://localhost:8080/health"
+log "=================================================="
+
+exec nginx -g 'daemon off;'
diff --git a/niap-cc/niap-android-cert-ext/est-server/nginx.conf b/niap-cc/niap-android-cert-ext/est-server/nginx.conf
new file mode 100644
index 0000000..b641a2c
--- /dev/null
+++ b/niap-cc/niap-android-cert-ext/est-server/nginx.conf
@@ -0,0 +1,170 @@
+# =============================================================================
+# NGINX config โ EST Validation Server
+# =============================================================================
+# Port layout:
+# 8443 (HTTPS + mTLS optional) ... EST protocol endpoints (RFC 7030)
+# 8081 (HTTPS + mTLS required) ... mTLS test endpoint (/protected/)
+# 8080 (HTTP) ... CA cert download and health check only
+# =============================================================================
+
+events {
+ worker_connections 1024;
+}
+
+http {
+ # Detailed log format including mTLS verification result and client cert info
+ log_format est_log '$remote_addr "$request" $status '
+ 'ssl_verify=$ssl_client_verify '
+ 'client_cn="$ssl_client_s_dn" '
+ 'issuer="$ssl_client_i_dn"';
+
+ access_log /var/log/nginx/access.log est_log;
+ error_log /var/log/nginx/error.log info;
+
+ # =========================================================================
+ # Server 1: EST endpoints (HTTPS + optional mTLS)
+ #
+ # Why ssl_verify_client optional:
+ # - /simpleenroll is initial enrollment, no client cert exists yet
+ # - /reenroll requires an existing cert (verified internally by estserver)
+ # - /cacerts requires no authentication
+ # Final authentication decision is delegated to estserver
+ # =========================================================================
+ server {
+ listen 8443 ssl;
+ server_name _;
+
+ # Server certificate chain (estserver.crt + cacert.crt)
+ # Path matches estserver-chain.pem generated by entrypoint.sh
+ ssl_certificate /opt/estserver/estCA/private/estserver-chain.pem;
+ ssl_certificate_key /opt/estserver/estCA/private/estserver.key;
+
+ # TLS versions and cipher suites
+ # Aligned with NIAP niap_security_config.xml allowed-cipher-suites:
+ # TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 (TLS 1.3, managed by NGINX)
+ # TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
+ # TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
+ ssl_protocols TLSv1.2 TLSv1.3;
+ ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
+ ssl_prefer_server_ciphers on;
+
+ # mTLS: client certificate verification
+ ssl_client_certificate /opt/estserver/estCA/cacert.crt;
+ ssl_verify_client optional;
+ ssl_verify_depth 2;
+
+ # -----------------------------------------------------------------------
+ # EST protocol routing (RFC 7030 ยง3.2.2)
+ # Proxy to background estserver
+ # -----------------------------------------------------------------------
+ location /.well-known/est/ {
+ # estserver runs its own TLS, so proxy via HTTPS
+ # SSL verification disabled (self-signed CA within same container)
+ proxy_pass https://127.0.0.1:8085;
+ proxy_ssl_verify off;
+
+ # Forward mTLS verification result to estserver via HTTP headers
+ proxy_set_header X-SSL-Client-Verify $ssl_client_verify;
+ proxy_set_header X-SSL-Client-Subject $ssl_client_s_dn;
+ proxy_set_header X-SSL-Client-Issuer $ssl_client_i_dn;
+ proxy_set_header X-SSL-Client-Serial $ssl_client_serial;
+
+ proxy_set_header Host $host;
+ proxy_set_header X-Real-IP $remote_addr;
+ proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+ proxy_set_header X-Forwarded-Proto https;
+
+ # EST CSR/cert responses are binary โ disable buffering
+ proxy_buffering off;
+ proxy_read_timeout 30s;
+ }
+ }
+
+ # =========================================================================
+ # Server 2: mTLS test endpoint (HTTPS + mTLS required)
+ #
+ # Separate from EST (8443) so mTLS testing is not tied to the EST server.
+ # ssl_verify_client on โ unlike 8443 which uses "optional" for /simpleenroll.
+ # Returns client cert info on success; nginx rejects with 400 if no cert.
+ # =========================================================================
+ server {
+ listen 8081 ssl;
+ server_name _;
+
+ ssl_certificate /opt/estserver/estCA/private/estserver-chain.pem;
+ ssl_certificate_key /opt/estserver/estCA/private/estserver.key;
+
+ ssl_protocols TLSv1.2 TLSv1.3;
+ ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
+ ssl_prefer_server_ciphers on;
+
+ ssl_client_certificate /opt/estserver/estCA/cacert.crt;
+ ssl_verify_client on;
+ ssl_verify_depth 2;
+
+ location /protected/ {
+ add_header Content-Type "text/plain";
+ return 200 "mTLS OK\nClient: $ssl_client_s_dn\nIssuer: $ssl_client_i_dn\nSerial: $ssl_client_serial\n";
+ }
+
+ location / {
+ return 200 "mTLS Test Server\n /protected/ โ requires valid client certificate\n";
+ add_header Content-Type "text/plain";
+ }
+ }
+
+ # =========================================================================
+ # Server 3: Plain HTTP admin interface
+ #
+ # Endpoints:
+ # /cacert.pem ... CA cert download for Android app TrustStore setup
+ # /health ... container health check (Cloud Run compatible)
+ # No TLS, no auth (local dev only โ do not expose in production)
+ # =========================================================================
+ server {
+ listen 8080;
+ server_name _;
+ root /var/www/html;
+
+ # CA cert download
+ location /cacert.pem {
+ add_header Content-Type "application/x-pem-file";
+ add_header Content-Disposition 'attachment; filename="cacert.pem"';
+ add_header Cache-Control "no-cache, no-store";
+ }
+
+ # Health check (for docker-compose / Cloud Run liveness probe)
+ location /health {
+ access_log off;
+ return 200 "OK\n";
+ add_header Content-Type "text/plain";
+ }
+
+ # EST endpoints for Cloud Run (no mTLS โ TLS terminated by Cloud Run proxy)
+ # Used when Cloud Run exposes only port 8080.
+ location /.well-known/est/ {
+ proxy_pass https://127.0.0.1:8085;
+ proxy_ssl_verify off;
+
+ # No client cert available on this path โ send empty headers
+ proxy_set_header X-SSL-Client-Verify "";
+ proxy_set_header X-SSL-Client-Subject "";
+ proxy_set_header X-SSL-Client-Issuer "";
+ proxy_set_header X-SSL-Client-Serial "";
+
+ proxy_set_header Host $host;
+ proxy_set_header X-Real-IP $remote_addr;
+ proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+ proxy_set_header X-Forwarded-Proto https;
+
+ proxy_buffering off;
+ proxy_read_timeout 30s;
+ }
+
+ # Default: brief server info
+ location / {
+ return 200 "EST Validation Server\nEndpoints:\n EST: /.well-known/est/\n CA cert: /cacert.pem\n Health: /health\n";
+ add_header Content-Type "text/plain";
+ }
+ }
+}
diff --git a/niap-cc/niap-android-cert-ext/gradle.properties b/niap-cc/niap-android-cert-ext/gradle.properties
new file mode 100644
index 0000000..abda456
--- /dev/null
+++ b/niap-cc/niap-android-cert-ext/gradle.properties
@@ -0,0 +1,2 @@
+android.useAndroidX=true
+org.gradle.jvmargs=-Xmx4096m -Dfile.encoding=UTF-8
diff --git a/niap-cc/niap-android-cert-ext/gradle/wrapper/gradle-wrapper.jar b/niap-cc/niap-android-cert-ext/gradle/wrapper/gradle-wrapper.jar
new file mode 100644
index 0000000..980502d
Binary files /dev/null and b/niap-cc/niap-android-cert-ext/gradle/wrapper/gradle-wrapper.jar differ
diff --git a/niap-cc/niap-android-cert-ext/gradle/wrapper/gradle-wrapper.properties b/niap-cc/niap-android-cert-ext/gradle/wrapper/gradle-wrapper.properties
new file mode 100644
index 0000000..eeaa4c5
--- /dev/null
+++ b/niap-cc/niap-android-cert-ext/gradle/wrapper/gradle-wrapper.properties
@@ -0,0 +1,8 @@
+#Tue Feb 17 14:07:26 JST 2026
+distributionBase=GRADLE_USER_HOME
+distributionPath=wrapper/dists
+distributionUrl=https\://services.gradle.org/distributions/gradle-8.14.4-bin.zip
+networkTimeout=10000
+validateDistributionUrl=true
+zipStoreBase=GRADLE_USER_HOME
+zipStorePath=wrapper/dists
diff --git a/niap-cc/niap-android-cert-ext/gradlew b/niap-cc/niap-android-cert-ext/gradlew
new file mode 100755
index 0000000..faf9300
--- /dev/null
+++ b/niap-cc/niap-android-cert-ext/gradlew
@@ -0,0 +1,251 @@
+#!/bin/sh
+
+#
+# Copyright ยฉ 2015-2021 the original authors.
+#
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+# https://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+#
+# SPDX-License-Identifier: Apache-2.0
+#
+
+##############################################################################
+#
+# Gradle start up script for POSIX generated by Gradle.
+#
+# Important for running:
+#
+# (1) You need a POSIX-compliant shell to run this script. If your /bin/sh is
+# noncompliant, but you have some other compliant shell such as ksh or
+# bash, then to run this script, type that shell name before the whole
+# command line, like:
+#
+# ksh Gradle
+#
+# Busybox and similar reduced shells will NOT work, because this script
+# requires all of these POSIX shell features:
+# * functions;
+# * expansions ยซ$varยป, ยซ${var}ยป, ยซ${var:-default}ยป, ยซ${var+SET}ยป,
+# ยซ${var#prefix}ยป, ยซ${var%suffix}ยป, and ยซ$( cmd )ยป;
+# * compound commands having a testable exit status, especially ยซcaseยป;
+# * various built-in commands including ยซcommandยป, ยซsetยป, and ยซulimitยป.
+#
+# Important for patching:
+#
+# (2) This script targets any POSIX shell, so it avoids extensions provided
+# by Bash, Ksh, etc; in particular arrays are avoided.
+#
+# The "traditional" practice of packing multiple parameters into a
+# space-separated string is a well documented source of bugs and security
+# problems, so this is (mostly) avoided, by progressively accumulating
+# options in "$@", and eventually passing that to Java.
+#
+# Where the inherited environment variables (DEFAULT_JVM_OPTS, JAVA_OPTS,
+# and GRADLE_OPTS) rely on word-splitting, this is performed explicitly;
+# see the in-line comments for details.
+#
+# There are tweaks for specific operating systems such as AIX, CygWin,
+# Darwin, MinGW, and NonStop.
+#
+# (3) This script is generated from the Groovy template
+# https://github.com/gradle/gradle/blob/HEAD/platforms/jvm/plugins-application/src/main/resources/org/gradle/api/internal/plugins/unixStartScript.txt
+# within the Gradle project.
+#
+# You can find Gradle at https://github.com/gradle/gradle/.
+#
+##############################################################################
+
+# Attempt to set APP_HOME
+
+# Resolve links: $0 may be a link
+app_path=$0
+
+# Need this for daisy-chained symlinks.
+while
+ APP_HOME=${app_path%"${app_path##*/}"} # leaves a trailing /; empty if no leading path
+ [ -h "$app_path" ]
+do
+ ls=$( ls -ld "$app_path" )
+ link=${ls#*' -> '}
+ case $link in #(
+ /*) app_path=$link ;; #(
+ *) app_path=$APP_HOME$link ;;
+ esac
+done
+
+# This is normally unused
+# shellcheck disable=SC2034
+APP_BASE_NAME=${0##*/}
+# Discard cd standard output in case $CDPATH is set (https://github.com/gradle/gradle/issues/25036)
+APP_HOME=$( cd -P "${APP_HOME:-./}" > /dev/null && printf '%s\n' "$PWD" ) || exit
+
+# Use the maximum available, or set MAX_FD != -1 to use that value.
+MAX_FD=maximum
+
+warn () {
+ echo "$*"
+} >&2
+
+die () {
+ echo
+ echo "$*"
+ echo
+ exit 1
+} >&2
+
+# OS specific support (must be 'true' or 'false').
+cygwin=false
+msys=false
+darwin=false
+nonstop=false
+case "$( uname )" in #(
+ CYGWIN* ) cygwin=true ;; #(
+ Darwin* ) darwin=true ;; #(
+ MSYS* | MINGW* ) msys=true ;; #(
+ NONSTOP* ) nonstop=true ;;
+esac
+
+CLASSPATH=$APP_HOME/gradle/wrapper/gradle-wrapper.jar
+
+
+# Determine the Java command to use to start the JVM.
+if [ -n "$JAVA_HOME" ] ; then
+ if [ -x "$JAVA_HOME/jre/sh/java" ] ; then
+ # IBM's JDK on AIX uses strange locations for the executables
+ JAVACMD=$JAVA_HOME/jre/sh/java
+ else
+ JAVACMD=$JAVA_HOME/bin/java
+ fi
+ if [ ! -x "$JAVACMD" ] ; then
+ die "ERROR: JAVA_HOME is set to an invalid directory: $JAVA_HOME
+
+Please set the JAVA_HOME variable in your environment to match the
+location of your Java installation."
+ fi
+else
+ JAVACMD=java
+ if ! command -v java >/dev/null 2>&1
+ then
+ die "ERROR: JAVA_HOME is not set and no 'java' command could be found in your PATH.
+
+Please set the JAVA_HOME variable in your environment to match the
+location of your Java installation."
+ fi
+fi
+
+# Increase the maximum file descriptors if we can.
+if ! "$cygwin" && ! "$darwin" && ! "$nonstop" ; then
+ case $MAX_FD in #(
+ max*)
+ # In POSIX sh, ulimit -H is undefined. That's why the result is checked to see if it worked.
+ # shellcheck disable=SC2039,SC3045
+ MAX_FD=$( ulimit -H -n ) ||
+ warn "Could not query maximum file descriptor limit"
+ esac
+ case $MAX_FD in #(
+ '' | soft) :;; #(
+ *)
+ # In POSIX sh, ulimit -n is undefined. That's why the result is checked to see if it worked.
+ # shellcheck disable=SC2039,SC3045
+ ulimit -n "$MAX_FD" ||
+ warn "Could not set maximum file descriptor limit to $MAX_FD"
+ esac
+fi
+
+# Collect all arguments for the java command, stacking in reverse order:
+# * args from the command line
+# * the main class name
+# * -classpath
+# * -D...appname settings
+# * --module-path (only if needed)
+# * DEFAULT_JVM_OPTS, JAVA_OPTS, and GRADLE_OPTS environment variables.
+
+# For Cygwin or MSYS, switch paths to Windows format before running java
+if "$cygwin" || "$msys" ; then
+ APP_HOME=$( cygpath --path --mixed "$APP_HOME" )
+ CLASSPATH=$( cygpath --path --mixed "$CLASSPATH" )
+
+ JAVACMD=$( cygpath --unix "$JAVACMD" )
+
+ # Now convert the arguments - kludge to limit ourselves to /bin/sh
+ for arg do
+ if
+ case $arg in #(
+ -*) false ;; # don't mess with options #(
+ /?*) t=${arg#/} t=/${t%%/*} # looks like a POSIX filepath
+ [ -e "$t" ] ;; #(
+ *) false ;;
+ esac
+ then
+ arg=$( cygpath --path --ignore --mixed "$arg" )
+ fi
+ # Roll the args list around exactly as many times as the number of
+ # args, so each arg winds up back in the position where it started, but
+ # possibly modified.
+ #
+ # NB: a `for` loop captures its iteration list before it begins, so
+ # changing the positional parameters here affects neither the number of
+ # iterations, nor the values presented in `arg`.
+ shift # remove old arg
+ set -- "$@" "$arg" # push replacement arg
+ done
+fi
+
+
+# Add default JVM options here. You can also use JAVA_OPTS and GRADLE_OPTS to pass JVM options to this script.
+DEFAULT_JVM_OPTS='"-Xmx64m" "-Xms64m"'
+
+# Collect all arguments for the java command:
+# * DEFAULT_JVM_OPTS, JAVA_OPTS, and optsEnvironmentVar are not allowed to contain shell fragments,
+# and any embedded shellness will be escaped.
+# * For example: A user cannot expect ${Hostname} to be expanded, as it is an environment variable and will be
+# treated as '${Hostname}' itself on the command line.
+
+set -- \
+ "-Dorg.gradle.appname=$APP_BASE_NAME" \
+ -classpath "$CLASSPATH" \
+ org.gradle.wrapper.GradleWrapperMain \
+ "$@"
+
+# Stop when "xargs" is not available.
+if ! command -v xargs >/dev/null 2>&1
+then
+ die "xargs is not available"
+fi
+
+# Use "xargs" to parse quoted args.
+#
+# With -n1 it outputs one arg per line, with the quotes and backslashes removed.
+#
+# In Bash we could simply go:
+#
+# readarray ARGS < <( xargs -n1 <<<"$var" ) &&
+# set -- "${ARGS[@]}" "$@"
+#
+# but POSIX shell has neither arrays nor command substitution, so instead we
+# post-process each arg (as a line of input to sed) to backslash-escape any
+# character that might be a shell metacharacter, then use eval to reverse
+# that process (while maintaining the separation between arguments), and wrap
+# the whole thing up as a single "set" statement.
+#
+# This will of course break if any of these variables contains a newline or
+# an unmatched quote.
+#
+
+eval "set -- $(
+ printf '%s\n' "$DEFAULT_JVM_OPTS $JAVA_OPTS $GRADLE_OPTS" |
+ xargs -n1 |
+ sed ' s~[^-[:alnum:]+,./:=@_]~\\&~g; ' |
+ tr '\n' ' '
+ )" '"$@"'
+
+exec "$JAVACMD" "$@"
diff --git a/niap-cc/niap-android-cert-ext/settings.gradle.kts b/niap-cc/niap-android-cert-ext/settings.gradle.kts
new file mode 100644
index 0000000..87ee7d2
--- /dev/null
+++ b/niap-cc/niap-android-cert-ext/settings.gradle.kts
@@ -0,0 +1,40 @@
+/*
+ * Copyright 2026 The Android Open Source Project
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+pluginManagement {
+ repositories {
+ google()
+ mavenCentral()
+ gradlePluginPortal()
+ }
+}
+dependencyResolutionManagement {
+ repositoriesMode.set(RepositoriesMode.PREFER_SETTINGS)
+ repositories {
+ google()
+ mavenCentral()
+ }
+}
+rootProject.name = "niap-android-cert-ext"
+include(":cert-lib")
+include(":cert-manager")
+include(":validator-test-app")
+include(":agent-test")
+include(":cert-test-app")
+
+include(":common-utils")
+project(":common-utils").projectDir = file("../../../testbedui-plugins/common-utils")
+
diff --git a/niap-cc/niap-android-cert-ext/testbed-mcp-reference.md b/niap-cc/niap-android-cert-ext/testbed-mcp-reference.md
new file mode 100644
index 0000000..195c580
--- /dev/null
+++ b/niap-cc/niap-android-cert-ext/testbed-mcp-reference.md
@@ -0,0 +1,398 @@
+# Testbed Automation MCP Reference for LLMs
+
+This document is a comprehensive Model Context Protocol (MCP) tool reference for LLM agents to control and observe physical or emulated devices within the Testbed Automation environment.
+
+It is updated from the baseline specifications and incorporates recent additions (such as streaming and ping utilities), precise parameter definitions, and concrete **execution examples**.
+
+---
+
+## 1. Sensing (Device State and Screen Analysis)
+
+Tools in this category allow agents to inspect screen layouts, query power configurations, and check hardware parameters.
+
+### `get_ui_dump`
+* **Description**: Captures the current screen's UI layout hierarchy. By default, it yields a token-efficient flat list format (~1KB) optimized for LLMs.
+* **Parameters**:
+ * `format` (String / Optional / Default: `"summary"`): Output style. `"summary"` = compact flat list, `"json"` = traditional full-tree JSON.
+ * `include_image` (Boolean / Optional / Default: `false`): Whether to include base64-encoded screenshot data (valid only when `format="json"`).
+ * `image_quality` (Int / Optional / Default: `2`): Screen compression level (1 = 100%, 2 = 50%, 3 = 33%, 4 = 25%).
+* **Returns**:
+ * If `format="summary"`: A plain-text flat list where each line represents a node containing its index, class identifier, human-readable label, action coordinates, and state indicators.
+ * If `format="json"`: A structured JSON payload containing the hierarchical `json_dump` string and optional base64 `screenshot` data.
+* **Examples**:
+ * **Request (Default: summary format)**:
+ ```json
+ {}
+ ```
+ * **Response (summary format)**:
+ ```text
+ Screen: 1080x2400 | App: com.example.app
+ โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
+ [0] ImageButton "Back" tap(73,205) clickable
+ [1] TextView "Settings" at(540,205)
+ [2] CheckBox "Option A" tap(540,484) clickable checked=true โ
+ [3] CheckBox "Option B" tap(540,625) clickable checked=false
+ โโโโโโโโโโโโโโโโโโโโ scrollable: RecyclerView โ
+ ```
+ * **Request (JSON format)**:
+ ```json
+ {
+ "format": "json",
+ "include_image": true
+ }
+ ```
+ * **Response (JSON format)**:
+ ```json
+ {
+ "json_dump": "{\"className\":\"android.widget.FrameLayout\",\"bounds\":\"[0,0][1080,2400]\",\"children\":[...]}"
+ }
+ ```
+
+### `get_device_state`
+* **Description**: Checks screen power state (ON/OFF), screen lock status, and current active foreground package details.
+* **Parameters**: None
+* **Returns**: A JSON state map.
+* **Examples**:
+ * **Request**: `{}`
+ * **Response**:
+ ```json
+ {
+ "is_screen_on": true,
+ "is_locked": false,
+ "foreground_package": "com.google.android.apps.nexuslauncher"
+ }
+ ```
+
+### `get_device_info`
+* **Description**: Queries hardware and operating system parameters from the system (wrapper around `getprop` entries).
+* **Parameters**: None
+* **Returns**: A JSON dictionary containing hardware specifications.
+* **Examples**:
+ * **Request**: `{}`
+ * **Response**:
+ ```json
+ {
+ "model": "Pixel 8",
+ "os_version": "37",
+ "abi": "arm64-v8a",
+ "screen_size": "1080x2400"
+ }
+ ```
+
+### `start_stream` (New)
+* **Description**: Initiates automatic streaming of base64-encoded device screenshots at standard regular intervals.
+* **Parameters**:
+ * `fps` (Float / Optional / Default: `1.0`): Target frames per second.
+ * `image_quality` (Int / Optional / Default: `2`): Screen compression level (1 to 4).
+* **Returns**: Operation status success message.
+* **Examples**:
+ * **Request**:
+ ```json
+ {
+ "fps": 2.0,
+ "image_quality": 3
+ }
+ ```
+ * **Response**: `"Stream started"`
+
+### `stop_stream` (New)
+* **Description**: Terminates active screenshot streaming operations.
+* **Parameters**: None
+* **Returns**: Operation status success message.
+* **Examples**:
+ * **Request**: `{}`
+ * **Response**: `"Stream stopped"`
+
+---
+
+## 2. Action (UI Interactions and Gestures)
+
+These tools execute physical interactions on the device. Following command invocation, they automatically wait for the screen to settle into an idle state and **return a summary of interactable elements only** (a layout list containing only clickable, checkable, or scrollable nodes).
+
+### `tap`
+* **Description**: Simulates a tap action at the specified (x, y) screen coordinates.
+* **Parameters**:
+ * `x` (Int / Required): Target X coordinate.
+ * `y` (Int / Required): Target Y coordinate.
+* **Returns**: An interactable UI elements summary layout list.
+* **Examples**:
+ * **Request**:
+ ```json
+ {
+ "x": 500,
+ "y": 1000
+ }
+ ```
+ * **Response**: (Latest interactable UI layout summary)
+
+### `input_text`
+* **Description**: Sends a raw text string to the currently focused text input control.
+* **Parameters**:
+ * `text` (String / Required): The text string to send. Spaces and special characters are managed and escaped automatically.
+* **Returns**: An interactable UI elements summary layout list.
+* **Examples**:
+ * **Request**:
+ ```json
+ {
+ "text": "Hello World"
+ }
+ ```
+ * **Response**: (Latest interactable UI layout summary)
+
+### `swipe`
+* **Description**: Initiates a linear drag gesture between start and end screen coordinates.
+* **Parameters**:
+ * `start_x` (Int / Required)
+ * `start_y` (Int / Required)
+ * `end_x` (Int / Required)
+ * `end_y` (Int / Required)
+* **Returns**: An interactable UI elements summary layout list.
+* **Examples**:
+ * **Request**:
+ ```json
+ {
+ "start_x": 500,
+ "start_y": 1500,
+ "end_x": 500,
+ "end_y": 500
+ }
+ ```
+ * **Response**: (Latest interactable UI layout summary)
+
+### `press_key`
+* **Description**: Dispatches a standard hardware or system physical key button press.
+* **Parameters**:
+ * `keycode` (String / Required): Key event identifier (e.g., `"BACK"`, `"HOME"`, `"ENTER"`).
+* **Returns**: An interactable UI elements summary layout list.
+* **Examples**:
+ * **Request**:
+ ```json
+ {
+ "keycode": "BACK"
+ }
+ ```
+ * **Response**: (Latest interactable UI layout summary)
+
+---
+
+## 3. System (ADB Commands and Package Administration)
+
+### `execute_adb_shell`
+* **Description**: Executes an arbitrary ADB shell command on the target system.
+* **Parameters**:
+ * `command` (String / Required): Terminal command to run.
+* **Returns**: Combined plain text streams of `stdout` and `stderr`.
+* **Examples**:
+ * **Request**:
+ ```json
+ {
+ "command": "ls -l /sdcard"
+ }
+ ```
+ * **Response**:
+ ```text
+ total 0
+ drwxrwxr-x 2 root sdcard_rw 4096 ...
+ ```
+ *(Note: Depending on individual tool wrapper specifications, stdout/stderr streams might sometimes be delivered inside a structured JSON response object, but they are typically returned as simple text values.)*
+
+### `open_settings`
+* **Description**: Direct-launches specific system settings pages using target system Intents.
+* **Parameters**:
+ * `panel` (String / Required): Settings partition code. Valid keys: `ROOT`, `SECURITY`, `WIFI`, `APP_DETAILS`, `DEVELOPER`.
+* **Returns**: A layout representation string of the opened settings layout.
+* **Examples**:
+ * **Request**:
+ ```json
+ {
+ "panel": "SECURITY"
+ }
+ ```
+ * **Response**: (Settings page UI layout representation)
+
+### `push_file`
+* **Description**: Transports local host files onto target paths of the connected device.
+* **Parameters**:
+ * `host_path` (String / Required): Source file path on the host computer.
+ * `device_path` (String / Required): Destination file path on the target device.
+* **Returns**: Operation status success or error message.
+* **Examples**:
+ * **Request**:
+ ```json
+ {
+ "host_path": "/tmp/test.apk",
+ "device_path": "/data/local/tmp/test.apk"
+ }
+ ```
+ * **Response**: `"File pushed successfully"`
+
+### `pull_file`
+* **Description**: Downloads files from target locations on the device to the host system.
+* **Parameters**:
+ * `device_path` (String / Required): Target file path on the device.
+ * `host_path` (String / Required): Destination path on the host computer.
+* **Returns**: Operation status success or error message.
+* **Examples**:
+ * **Request**:
+ ```json
+ {
+ "device_path": "/sdcard/screenshot.png",
+ "host_path": "/tmp/screenshot.png"
+ }
+ ```
+ * **Response**: `"File pulled successfully"`
+
+### `install_app`
+* **Description**: Installs a target application APK package from the host system.
+* **Parameters**:
+ * `apk_path` (String / Required): Absolute file path to the source APK on the host.
+* **Returns**: Installation terminal output.
+* **Examples**:
+ * **Request**:
+ ```json
+ {
+ "apk_path": "/tmp/app.apk"
+ }
+ ```
+ * **Response**: `"Success"`
+
+### `uninstall_app`
+* **Description**: Removes an application package from the target device system.
+* **Parameters**:
+ * `package_name` (String / Required): Target package unique identifier (e.g., `com.example.app`).
+* **Returns**: Operation status confirmation.
+* **Examples**:
+ * **Request**:
+ ```json
+ {
+ "package_name": "com.example.app"
+ }
+ ```
+ * **Response**: `"Success"`
+
+---
+
+## 4. Observe (Logging and Connection Diagnostics)
+
+### `get_logcat`
+* **Description**: Captures memory-buffered system and application logs via Logcat. Applying specific query filters is highly recommended to protect token budgets.
+* **Parameters**:
+ * `tags` (String[] / Optional / Default: `[]`): Filter logs matching target tag names.
+ * `level` (String / Optional / Default: `"V"`): Filter logs exceeding minimum priority levels (`V`, `D`, `I`, `W`, `E`, `F`).
+ * `grep_pattern` (String / Optional / Default: `""`): Filter entries matching regular expressions.
+ * `max_lines` (Int / Optional / Default: `100`): Maximum lines output boundary.
+ * `process` (String / Optional / Default: `""`): Filter logs matching specific processes. Supports package names (e.g., `"com.android.settings"`) or active PIDs (e.g., `"1234"`). Package strings are resolved to PIDs dynamically (first checking cached structures from ProcessNameResolver, then using `pidof` commands as fallback).
+* **Returns**: A plain-text block of raw logs.
+* **Examples**:
+ * **Targeting Tag Names**:
+ ```json
+ {
+ "tags": ["ActivityManager"],
+ "level": "I",
+ "max_lines": 5
+ }
+ ```
+ * **Targeting Package Processes**:
+ ```json
+ {
+ "process": "com.android.settings",
+ "level": "D",
+ "max_lines": 50
+ }
+ ```
+ * **Response Output**:
+ ```text
+ 04-09 02:00:00.000 1000 1000 I ActivityManager: Start proc ...
+ 04-09 02:00:01.000 1000 1000 I ActivityManager: Activity paused ...
+ ```
+
+### `clear_logcat`
+* **Description**: Purges all log entries currently present inside the system Logcat buffers.
+* **Parameters**: None
+* **Returns**: Operation status success message.
+* **Examples**:
+ * **Request**: `{}`
+ * **Response**: `"Logcat cleared"`
+
+### `ping` (New)
+* **Description**: Verifies continuous message connectivity with the on-device Mutton Agent.
+* **Parameters**: None
+* **Returns**: Latency response confirmation message.
+* **Examples**:
+ * **Request**: `{}`
+ * **Response**: `"pong"`
+
+### `get_agent_version`
+* **Description**: Queries the build version number of the Mutton Agent current running on the device.
+* **Parameters**: None
+* **Returns**: Build version tag.
+* **Examples**:
+ * **Request**: `{}`
+ * **Response**: `"1.0.0"`
+
+---
+
+## 5. Test Control (JUnit Test Orchestration)
+
+These test services are executed by compiling and deploying specialized test JAR plugins directly onto the TestBed Core architecture. Because these programs run inside dedicated processes independent from the targeted systems, they escape common target app sandboxes or Android Instrumentation execution limitations, offering high runtime flexibility.
+
+Management and development of these modules are conducted within the test suite projects (such as `niap-android-cert-ext`). If necessary, compile the plugin targets (including any shared modules like `common-utils`), build the final JAR, and register it inside the `plugins` folder of TestBed Core.
+
+### `junit_test_reload`
+* **Description**: Triggers a hot-reload of registered test JAR assemblies inside TestBed Core.
+* **Parameters**: None
+* **Returns**: Operation reload status metrics.
+
+### `junit_test_list`
+* **Description**: Queries a list of all current runnable test methods registered on the environment.
+* **Parameters**: None
+* **Returns**: A JSON array string of target class and method pointers.
+* **Examples**:
+ * **Request**: `{}`
+ * **Response**: `["com.example.TestClass#testMethod1", "..."]`
+
+### `junit_test_execute`
+* **Description**: Initiates async execution of specified JUnit tests.
+* **Parameters**:
+ * `class_name` (String / Required): Absolute canonical identifier of the target class.
+ * `method_name` (String / Optional): Target test case method identifier.
+* **Returns**: Initialization success message.
+
+### `junit_test_receive`
+* **Description**: Captures current logs or structural exit results of target JUnit tests.
+* **Parameters**: None
+* **Returns**: A JSON payload containing execution statuses (`Running`, `Finished`), step traces, pass/fail state indicators, or exceptions stack traces.
+
+---
+
+## 6. Health (Connection Auditing and Recovery)
+
+### `check_testbed_health`
+* **Description**: Performs a holistic pipeline assessment, monitoring ADB connectivity status, physical devices links, and agent daemon processes.
+* **Parameters**: None
+* **Returns**: Diagnostic metrics JSON.
+* **Examples**:
+ * **Response**:
+ ```json
+ {
+ "adbIsValid": true,
+ "deviceSerial": "localhost:38189",
+ "isRunning": false,
+ "deviceInfo": "..."
+ }
+ ```
+
+### `cleanup_agent`
+* **Description**: Forcefully kills and restarts the on-device automation agent daemon process (essential for recovering from standard system UiAutomation lockouts).
+* **Parameters**: None
+* **Returns**: Status confirmation message.
+
+---
+
+## LLM Tips & Best Practices
+
+1. **Token Conservation**: `get_ui_dump` returns the highly efficient `summary` flat list by default (~1KB). Use `format="json"` only when full coordinate systems or specific layout attributes are strictly necessary. Always target `get_logcat` queries with restrictive `tags`, levels, or `max_lines` scopes.
+2. **Automatic Wait Cycles**: UI action tools (such as `tap` or `input_text`) automatically wait for the screen layout to settle into an idle state before resolving their interactable element summaries. Making separate `get_ui_dump` calls immediately after these actions is redundant.
+3. **Reading Flat Summaries**: Lines are structured using the format: `[Index] ClassName "Label" tap(x,y) flags`. The coordinate map returned by `tap(x,y)` can be passed directly to touch tools. Nodes featuring `at(x,y)` represent non-interactable layout positions.
+4. **Layout Crash Recovery**: If you encounter recurring target acquisition errors (e.g., `rootInActiveWindow returned null` exception messages), issue a `cleanup_agent` command to re-initialize the target context and recover the channel connection.
+5. **Space Escapes in Terminal Commands**: When executing raw terminal commands via `execute_adb_shell` that pass arguments containing space strings (e.g., `input text "hello world"`), be aware of the underlying parser limitations (some environments might require replacing spaces with escape strings like `input text hello%sworld`). High-level tools (such as `input_text`) manage these encodings automatically, but this is an important consideration when using raw terminal execution scripts.
diff --git a/niap-cc/niap-android-cert-ext/validator-test-app/build.gradle.kts b/niap-cc/niap-android-cert-ext/validator-test-app/build.gradle.kts
new file mode 100644
index 0000000..348313f
--- /dev/null
+++ b/niap-cc/niap-android-cert-ext/validator-test-app/build.gradle.kts
@@ -0,0 +1,95 @@
+/*
+ * Copyright 2026 The Android Open Source Project
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+plugins {
+ id("com.android.application")
+ id("org.jetbrains.kotlin.android")
+}
+
+android {
+ namespace = "com.example.niap.cert.ext.testapp"
+ compileSdk = 34
+
+ defaultConfig {
+ applicationId = "com.example.niap.cert.ext.testapp"
+ minSdk = 32
+ targetSdk = 34
+ versionCode = 1
+ versionName = "1.0"
+
+ testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
+ }
+
+ buildFeatures {
+ viewBinding = true
+ }
+
+ buildTypes {
+ release {
+ isMinifyEnabled = false
+ proguardFiles(getDefaultProguardFile("proguard-android-optimize.txt"), "proguard-rules.pro")
+ }
+ }
+ flavorDimensions.add("mode")
+ productFlavors {
+ create("strict") {
+ dimension = "mode"
+ }
+ create("relaxed") {
+ dimension = "mode"
+ }
+ }
+
+ compileOptions {
+ sourceCompatibility = JavaVersion.VERSION_1_8
+ targetCompatibility = JavaVersion.VERSION_1_8
+ }
+ kotlinOptions {
+ jvmTarget = "1.8"
+ }
+}
+
+dependencies {
+ implementation(project(":cert-lib"))
+ implementation("androidx.core:core-ktx:1.12.0")
+ implementation("androidx.appcompat:appcompat:1.6.1")
+ implementation("androidx.work:work-runtime-ktx:2.9.0")
+ implementation("com.squareup.okhttp3:okhttp:4.12.0")
+}
+
+tasks.register("copyApkToCore") {
+ description = "Copies the generated APKs to the TestBed Core resources directory."
+ from(layout.buildDirectory.dir("outputs/apk"))
+ include("**/*-debug.apk")
+ val coreResourcesDir = file("${rootProject.projectDir}/../testbed-core/composeApp/resources")
+ if (!coreResourcesDir.exists()) {
+ coreResourcesDir.mkdirs()
+ }
+ into(coreResourcesDir)
+ eachFile {
+ path = name
+ }
+ includeEmptyDirs = false
+ doLast {
+ println("โ
APKs copied to: ${coreResourcesDir.absolutePath}")
+ }
+}
+
+tasks.configureEach {
+ if (name == "assemble" || name == "assembleDebug" || name.startsWith("assemble")) {
+ finalizedBy("copyApkToCore")
+ }
+}
diff --git a/niap-cc/niap-android-cert-ext/validator-test-app/src/main/AndroidManifest.xml b/niap-cc/niap-android-cert-ext/validator-test-app/src/main/AndroidManifest.xml
new file mode 100644
index 0000000..918d672
--- /dev/null
+++ b/niap-cc/niap-android-cert-ext/validator-test-app/src/main/AndroidManifest.xml
@@ -0,0 +1,37 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/niap-cc/niap-android-cert-ext/validator-test-app/src/main/kotlin/com/example/niap/cert/ext/testapp/MainActivity.kt b/niap-cc/niap-android-cert-ext/validator-test-app/src/main/kotlin/com/example/niap/cert/ext/testapp/MainActivity.kt
new file mode 100644
index 0000000..d2425cc
--- /dev/null
+++ b/niap-cc/niap-android-cert-ext/validator-test-app/src/main/kotlin/com/example/niap/cert/ext/testapp/MainActivity.kt
@@ -0,0 +1,73 @@
+/*
+ * Copyright 2026 The Android Open Source Project
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package com.example.niap.cert.ext.testapp
+
+import androidx.appcompat.app.AppCompatActivity
+import android.os.Bundle
+import android.util.Log
+import androidx.work.Data
+import androidx.work.OneTimeWorkRequest
+import androidx.work.WorkManager
+import com.android.niap.cert.validator.NiapCertValidator
+
+class MainActivity : AppCompatActivity() {
+
+ override fun onCreate(savedInstanceState: Bundle?) {
+ super.onCreate(savedInstanceState)
+
+ setContentView(android.R.layout.simple_list_item_1)
+
+ val textView = findViewById(android.R.id.text1)
+
+ val url = intent.getStringExtra("openurl") ?: "https://www.google.com"
+ val type = intent.getStringExtra("type") ?: "http"
+ val buildTime = "2026-05-15 16:19"
+ Log.d("TestApp", "Build Time: $buildTime")
+ Log.d("TestApp", "URL to test: $url with type: $type")
+
+ textView.text = "Build Time: $buildTime\nTesting $url using $type..."
+
+ val data = Data.Builder()
+ .putString("url", url)
+ .putString("type", type)
+ .build()
+
+ val workRequest = OneTimeWorkRequest.Builder(NetworkWorker::class.java)
+ .setInputData(data)
+ .build()
+
+ Log.d("TestApp", "Enqueuing NetworkWorker...")
+ val workManager = WorkManager.getInstance(applicationContext)
+ workManager.cancelAllWork()
+ workManager.enqueue(workRequest)
+
+ workManager.getWorkInfoByIdLiveData(workRequest.id)
+ .observe(this) { workInfo ->
+ if (workInfo != null) {
+ if (workInfo.state.isFinished) {
+ val status = workInfo.state.name
+ val error = workInfo.outputData.getString("error")
+ if (error != null) {
+ textView.text = "Result: $status\nError: $error"
+ } else {
+ textView.text = "Result: $status"
+ }
+ }
+ }
+ }
+ }
+}
diff --git a/niap-cc/niap-android-cert-ext/validator-test-app/src/main/kotlin/com/example/niap/cert/ext/testapp/NetworkWorker.kt b/niap-cc/niap-android-cert-ext/validator-test-app/src/main/kotlin/com/example/niap/cert/ext/testapp/NetworkWorker.kt
new file mode 100644
index 0000000..dc26e60
--- /dev/null
+++ b/niap-cc/niap-android-cert-ext/validator-test-app/src/main/kotlin/com/example/niap/cert/ext/testapp/NetworkWorker.kt
@@ -0,0 +1,88 @@
+/*
+ * Copyright 2026 The Android Open Source Project
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package com.example.niap.cert.ext.testapp
+
+import android.content.Context
+import android.util.Log
+import androidx.work.Worker
+import androidx.work.WorkerParameters
+import com.android.niap.cert.validator.NiapCertValidator
+import com.android.niap.cert.validator.NiapX509TrustManager
+import java.net.URL
+import javax.net.ssl.HttpsURLConnection
+import javax.net.ssl.SSLContext
+import javax.net.ssl.TrustManagerFactory
+import javax.net.ssl.X509TrustManager
+import okhttp3.OkHttpClient
+import okhttp3.Request
+import com.android.niap.cert.validator.NiapCertHelper
+
+class NetworkWorker(context: Context, params: WorkerParameters) : Worker(context, params) {
+
+ override fun doWork(): Result {
+ val urlString = inputData.getString("url") ?: return Result.failure()
+ val type = inputData.getString("type") ?: "http"
+ Log.d("NetworkWorker", "Starting request to $urlString using $type")
+
+ try {
+ NiapCertHelper.resetInstance()
+ val helper = NiapCertHelper.getInstance(applicationContext)
+ Log.d("NetworkWorker", "Calling validateUrl")
+ helper.validateUrl(urlString)
+ Log.d("NetworkWorker", "validateUrl passed")
+
+ if (type == "okhttp3") {
+ Log.d("NetworkWorker", "Configuring OkHttp")
+ val client = helper.configureOkHttp(OkHttpClient.Builder()).build()
+ Log.d("NetworkWorker", "OkHttp configured")
+
+ val request = Request.Builder()
+ .url(urlString)
+ .build()
+
+ Log.d("NetworkWorker", "Executing OkHttp call")
+ client.newCall(request).execute().use { response ->
+ Log.d("NetworkWorker", "OkHttp Response Code: ${response.code}")
+ return Result.success()
+ }
+ } else {
+ val url = URL(urlString)
+ val connection = helper.openConnection(url)
+ connection.hostnameVerifier = javax.net.ssl.HostnameVerifier { hostname, session ->
+ Log.d("NetworkWorker", "Verifying hostname: $hostname")
+ helper.checkHostname(hostname, session)
+ true
+ }
+ connection.connectTimeout = 5000
+ connection.readTimeout = 5000
+
+ connection.connect()
+ val responseCode = connection.responseCode
+ Log.d("NetworkWorker", "Response Code: $responseCode")
+
+ connection.disconnect()
+ return Result.success()
+ }
+ } catch (e: Exception) {
+ Log.e("NetworkWorker", "Connection failed", e)
+ val output = androidx.work.Data.Builder()
+ .putString("error", e.message)
+ .build()
+ return Result.failure(output)
+ }
+ }
+}
diff --git a/niap-cc/niap-android-cert-ext/validator-test-app/src/main/res/xml/niap_security_config.xml b/niap-cc/niap-android-cert-ext/validator-test-app/src/main/res/xml/niap_security_config.xml
new file mode 100644
index 0000000..532e60b
--- /dev/null
+++ b/niap-cc/niap-android-cert-ext/validator-test-app/src/main/res/xml/niap_security_config.xml
@@ -0,0 +1,59 @@
+
+
+
+
+ true
+
+
+
+ *.COM
+ *.NET
+ *.ORG
+ *.GOV
+ *.EDU
+
+
+
+
+ TLS_AES_128_GCM_SHA256
+ TLS_AES_256_GCM_SHA384
+ TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
+ TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
+ TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
+ TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
+
+
+
+ BOTH_CA
+
+
+
+
+ true
+
+
+ true
+
+
+ true
+
+
+ serverAuth
+
+
+ true
+
diff --git a/niap-cc/niap-android-cert-ext/validator-test-app/src/relaxed/res/xml/niap_security_config.xml b/niap-cc/niap-android-cert-ext/validator-test-app/src/relaxed/res/xml/niap_security_config.xml
new file mode 100644
index 0000000..fdda8d6
--- /dev/null
+++ b/niap-cc/niap-android-cert-ext/validator-test-app/src/relaxed/res/xml/niap_security_config.xml
@@ -0,0 +1,41 @@
+
+
+
+
+ false
+
+
+
+
+
+
+ TLS_AES_128_GCM_SHA256
+ TLS_AES_256_GCM_SHA384
+ TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
+ TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
+ TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
+ TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
+
+
+ BOTH_CA
+
+ true
+ true
+ true
+ serverAuth
+ true
+
diff --git a/niap-cc/sdp-file-encrypt/.gitignore b/niap-cc/sdp-file-encrypt/.gitignore
new file mode 100644
index 0000000..1f7a560
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/.gitignore
@@ -0,0 +1,30 @@
+*.iml
+.gradle
+/.idea
+/.vscode
+/local.properties
+/.idea/caches
+/.idea/libraries
+/.idea/modules.xml
+/.idea/workspace.xml
+/.idea/navEditor.xml
+/.idea/assetWizardSettings.xml
+/locked-device-demo/build
+/encryption-lib/build
+/real-world-demo/build
+.DS_Store
+/build
+/captures
+.externalNativeBuild
+.cxx
+local.properties
+AGENTS.md
+.log
+build_error_*.txt
+build_error.txt
+firebase-debug.log
+*.hprof
+*.img
+/memory-test/*.img
+/memory-test/*.dump
+/.kotlin
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/LICENSE b/niap-cc/sdp-file-encrypt/LICENSE
new file mode 100644
index 0000000..d51936f
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/LICENSE
@@ -0,0 +1,201 @@
+ Apache License
+ Version 2.0, January 2004
+ http://www.apache.org/licenses/
+
+ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+ 1. Definitions.
+
+ "License" shall mean the terms and conditions for use, reproduction,
+ and distribution as defined by Sections 1 through 9 of this document.
+
+ "Licensor" shall mean the copyright owner or entity authorized by
+ the copyright owner that is granting the License.
+
+ "Legal Entity" shall mean the union of the acting entity and all
+ other entities that control, are controlled by, or are under common
+ control with that entity. For the purposes of this definition,
+ "control" means (i) the power, direct or indirect, to cause the
+ direction or management of such entity, whether by contract or
+ otherwise, or (ii) ownership of fifty percent (50%) or more of the
+ outstanding shares, or (iii) beneficial ownership of such entity.
+
+ "You" (or "Your") shall mean an individual or Legal Entity
+ exercising permissions granted by this License.
+
+ "Source" form shall mean the preferred form for making modifications,
+ including but not limited to software source code, documentation
+ source, and configuration files.
+
+ "Object" form shall mean any form resulting from mechanical
+ transformation or translation of a Source form, including but
+ not limited to compiled object code, generated documentation,
+ and conversions to other media types.
+
+ "Work" shall mean the work of authorship, whether in Source or
+ Object form, made available under the License, as indicated by a
+ copyright notice that is included in or attached to the work
+ (an example is provided in the Appendix below).
+
+ "Derivative Works" shall mean any work, whether in Source or Object
+ form, that is based on (or derived from) the Work and for which the
+ editorial revisions, annotations, elaborations, or other modifications
+ represent, as a whole, an original work of authorship. For the purposes
+ of this License, Derivative Works shall not include works that remain
+ separable from, or merely link (or bind by name) to the interfaces of,
+ the Work and Derivative Works thereof.
+
+ "Contribution" shall mean any work of authorship, including
+ the original version of the Work and any modifications or additions
+ to that Work or Derivative Works thereof, that is intentionally
+ submitted to Licensor for inclusion in the Work by the copyright owner
+ or by an individual or Legal Entity authorized to submit on behalf of
+ the copyright owner. For the purposes of this definition, "submitted"
+ means any form of electronic, verbal, or written communication sent
+ to the Licensor or its representatives, including but not limited to
+ communication on electronic mailing lists, source code control systems,
+ and issue tracking systems that are managed by, or on behalf of, the
+ Licensor for the purpose of discussing and improving the Work, but
+ excluding communication that is conspicuously marked or otherwise
+ designated in writing by the copyright owner as "Not a Contribution."
+
+ "Contributor" shall mean Licensor and any individual or Legal Entity
+ on behalf of whom a Contribution has been received by Licensor and
+ subsequently incorporated within the Work.
+
+ 2. Grant of Copyright License. Subject to the terms and conditions of
+ this License, each Contributor hereby grants to You a perpetual,
+ worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+ copyright license to reproduce, prepare Derivative Works of,
+ publicly display, publicly perform, sublicense, and distribute the
+ Work and such Derivative Works in Source or Object form.
+
+ 3. Grant of Patent License. Subject to the terms and conditions of
+ this License, each Contributor hereby grants to You a perpetual,
+ worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+ (except as stated in this section) patent license to make, have made,
+ use, offer to sell, sell, import, and otherwise transfer the Work,
+ where such license applies only to those patent claims licensable
+ by such Contributor that are necessarily infringed by their
+ Contribution(s) alone or by combination of their Contribution(s)
+ with the Work to which such Contribution(s) was submitted. If You
+ institute patent litigation against any entity (including a
+ cross-claim or counterclaim in a lawsuit) alleging that the Work
+ or a Contribution incorporated within the Work constitutes direct
+ or contributory patent infringement, then any patent licenses
+ granted to You under this License for that Work shall terminate
+ as of the date such litigation is filed.
+
+ 4. Redistribution. You may reproduce and distribute copies of the
+ Work or Derivative Works thereof in any medium, with or without
+ modifications, and in Source or Object form, provided that You
+ meet the following conditions:
+
+ (a) You must give any other recipients of the Work or
+ Derivative Works a copy of this License; and
+
+ (b) You must cause any modified files to carry prominent notices
+ stating that You changed the files; and
+
+ (c) You must retain, in the Source form of any Derivative Works
+ that You distribute, all copyright, patent, trademark, and
+ attribution notices from the Source form of the Work,
+ excluding those notices that do not pertain to any part of
+ the Derivative Works; and
+
+ (d) If the Work includes a "NOTICE" text file as part of its
+ distribution, then any Derivative Works that You distribute must
+ include a readable copy of the attribution notices contained
+ within such NOTICE file, excluding those notices that do not
+ pertain to any part of the Derivative Works, in at least one
+ of the following places: within a NOTICE text file distributed
+ as part of the Derivative Works; within the Source form or
+ documentation, if provided along with the Derivative Works; or,
+ within a display generated by the Derivative Works, if and
+ wherever such third-party notices normally appear. The contents
+ of the NOTICE file are for informational purposes only and
+ do not modify the License. You may add Your own attribution
+ notices within Derivative Works that You distribute, alongside
+ or as an addendum to the NOTICE text from the Work, provided
+ that such additional attribution notices cannot be construed
+ as modifying the License.
+
+ You may add Your own copyright statement to Your modifications and
+ may provide additional or different license terms and conditions
+ for use, reproduction, or distribution of Your modifications, or
+ for any such Derivative Works as a whole, provided Your use,
+ reproduction, and distribution of the Work otherwise complies with
+ the conditions stated in this License.
+
+ 5. Submission of Contributions. Unless You explicitly state otherwise,
+ any Contribution intentionally submitted for inclusion in the Work
+ by You to the Licensor shall be under the terms and conditions of
+ this License, without any additional terms or conditions.
+ Notwithstanding the above, nothing herein shall supersede or modify
+ the terms of any separate license agreement you may have executed
+ with Licensor regarding such Contributions.
+
+ 6. Trademarks. This License does not grant permission to use the trade
+ names, trademarks, service marks, or product names of the Licensor,
+ except as required for reasonable and customary use in describing the
+ origin of the Work and reproducing the content of the NOTICE file.
+
+ 7. Disclaimer of Warranty. Unless required by applicable law or
+ agreed to in writing, Licensor provides the Work (and each
+ Contributor provides its Contributions) on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+ implied, including, without limitation, any warranties or conditions
+ of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+ PARTICULAR PURPOSE. You are solely responsible for determining the
+ appropriateness of using or redistributing the Work and assume any
+ risks associated with Your exercise of permissions under this License.
+
+ 8. Limitation of Liability. In no event and under no legal theory,
+ whether in tort (including negligence), contract, or otherwise,
+ unless required by applicable law (such as deliberate and grossly
+ negligent acts) or agreed to in writing, shall any Contributor be
+ liable to You for damages, including any direct, indirect, special,
+ incidental, or consequential damages of any character arising as a
+ result of this License or out of the use or inability to use the
+ Work (including but not limited to damages for loss of goodwill,
+ work stoppage, computer failure or malfunction, or any and all
+ other commercial damages or losses), even if such Contributor
+ has been advised of the possibility of such damages.
+
+ 9. Accepting Warranty or Additional Liability. While redistributing
+ the Work or Derivative Works thereof, You may choose to offer,
+ and charge a fee for, acceptance of support, warranty, indemnity,
+ or other liability obligations and/or rights consistent with this
+ License. However, in accepting such obligations, You may act only
+ on Your own behalf and on Your sole responsibility, not on behalf
+ of any other Contributor, and only if You agree to indemnify,
+ defend, and hold each Contributor harmless for any liability
+ incurred by, or claims asserted against, such Contributor by reason
+ of your accepting any such warranty or additional liability.
+
+ END OF TERMS AND CONDITIONS
+
+ APPENDIX: How to apply the Apache License to your work.
+
+ To apply the Apache License to your work, attach the following
+ boilerplate notice, with the fields enclosed by brackets "[]"
+ replaced with your own identifying information. (Don't include
+ the brackets!) The text should be enclosed in the appropriate
+ comment syntax for the file format. We also recommend that a
+ file or class name and description of purpose be included on the
+ same "printed page" as the copyright notice for easier
+ identification within third-party archives.
+
+ Copyright 2026 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
diff --git a/niap-cc/sdp-file-encrypt/README.md b/niap-cc/sdp-file-encrypt/README.md
new file mode 100644
index 0000000..5fc813b
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/README.md
@@ -0,0 +1,193 @@
+# Android SDP File Encryption Demo
+
+## 1. Project Overview
+
+This project provides an Android file encryption core library (`encryption-lib`) alongside a demonstration application (`locked-device-demo`). It is designed to demonstrate and compare different file encryption strategies, focusing on compliance with the **NIAP Mobile Device Fundamentals Protection Profile (MDF PP) Version 3.3**. Note that while the project is structured as a generic library, implementations of manual or unsafe patterns (such as `RawKeyProvider`) are kept for demonstration and educational purposes.
+
+The primary goal is to compare distinct `EncryptionProvider` implementations:
+- **`RawHybridKeyProvider`**: The **NIAP-compliant** reference implementation. It uses raw JCA primitives to strictly control key memory lifecycles (zeroization) and supports secure lock-state operations.
+- **`HybridKeyProvider`**: A standard implementation using **Google Tink's Hybrid Encryption** (ECIES). While it is theoretically capable of meeting most requirements, strict memory zeroization (`FCS_CKM_EXT.4`) depends entirely on the Tink library's internals. Therefore, a completely compliant implementation is not provided.
+- **`RawKeyProvider`**: A manual implementation using raw Android JCA APIs. It was an earlier candidate, but due to the difficulty of satisfying the strict NIAP requirements, a complete implementation is not provided.
+
+## 2. Security Architecture & Compliance
+
+This library is designed to meet the strict security requirements of the **NIAP Mobile Device Fundamentals Protection Profile (MDF PP) Version 3.3**.
+
+### Key Implementation: `RawHybridKeyProvider`
+Unlike standard high-level wrappers, our `RawHybridKeyProvider` uses raw JCA primitives to ensure full control over the key lifecycle, specifically addressing memory zeroization requirements.
+
+* **Algorithm**: Hybrid Encryption Scheme (EC-DH + HKDF + AES-GCM).
+* **Compliance Features**:
+ * **FCS_CKM_EXT.4 (Key Destruction)**: Explicitly zeroes out (overwrites) plain-text DEKs and shared secrets in volatile memory immediately after use via `finally` blocks. Standard high-level libraries often rely on Garbage Collection, which is insufficient for PP compliance.
+ * **FDP_DAR_EXT.2 (Locked State Operation / Data at Rest)**: Fully and correctly implemented. Supports encryption even when the device is locked (AFU/BFU) by leveraging a cached public key configuration, while keeping the private key securely hardware-backed in the TEE. It also includes an automatic `FDP_DAR_EXT.2.4` sweep-and-rewrap mechanism that transitions files encrypted via asymmetric keys back to a more efficient symmetric encryption as soon as the device is unlocked.
+ * **FCS_CKM_EXT.2 (Key Generation)**: Uses `SecureRandom` for generating ephemeral Data Encryption Keys (DEKs).
+ * **FCS_STG_EXT.2 (Key Storage)**: Implements Envelope Encryption where DEKs are wrapped by a TEE-backed Key Encryption Key (KEK).
+
+## 3. Key Components
+
+### `EncryptionProvider` Implementations
+
+#### `RawHybridKeyProvider` (Compliant)
+- **Strategy**: A robust two-tier envelope encryption designed for Common Criteria evaluation.
+- **KEK (Key-Encrypting Key)**: An `EC` (Elliptic Curve) key pair stored securely in the `AndroidKeyStore` with `unlockedDeviceRequired`.
+- **DEK (Data-Encapsulating Key)**: An ephemeral `AES-256-GCM` key generated via `SecureRandom` for each file.
+- **Lock-State Behavior**:
+ - **Encryption**: Supported in locked state. Uses a pre-shared/cached Public Key to wrap the ephemeral DEK without accessing the Keystore.
+ - **Decryption**: Fails securely when locked. Requires user authentication to access the Private Key in the TEE for unwrapping.
+- **Memory Safety**: Implements explicit zeroization of sensitive byte arrays immediately after use.
+
+#### `HybridKeyProvider` (Tink Standard)
+- **Strategy**: Two-tier envelope encryption using the **Google Tink** library.
+- **KEK**: An `AES` key stored in the `AndroidKeyStore`.
+- **DEK**: A Tink-managed ECIES keyset.
+- **Note**: This implementation demonstrates the standard usage of Tink's Hybrid primitives. While secure for general use, it abstracts memory management, making it difficult to prove strict compliance with NIAP's volatile memory zeroization requirements (`FCS_CKM_EXT.4`). Since explicit zeroization would require modifying Tink itself, a fully compliant implementation is not provided.
+
+#### `RawKeyProvider` (JCA Adapter)
+- **Strategy**: A manual implementation wrapping standard Android JCA APIs (`Cipher`, `AndroidKeyStore`) into the Tink `Aead` interface.
+- **Algorithm**: `AES/CBC/PKCS7Padding`.
+- **Behavior**: Generates software-backed keys and imports them into the Keystore.
+- **Purpose**: Demonstrates how to adapt raw platform APIs to a common interface without using the full Tink library features. It was an earlier candidate for the final implementation, but structural challenges in meeting strict compliance requirements mean a complete, NIAP-compliant version is not provided.
+
+### Core Library (`encryption-lib`)
+- Contains all core encryption logic, including the `EncryptionManager` (the facade API) and the various `EncryptionProvider` implementations.
+- Some providers, like `RawKeyProvider`, represent specific historic or anti-pattern strategies and are deliberately retained to serve as test cases and comparative examples.
+
+### Demo Application (`locked-device-demo`)
+- Contains a `MainActivity` that provides a UI to run encryption/decryption tests for each provider, both in unlocked and locked states, and to display the results.
+- Includes a `DeviceAdminReceiver` required to programmatically lock the screen for the "Lock & Test" feature. The user must grant Device Administrator permissions to the app for this functionality to work.
+
+## 4. How to Build and Run
+
+1. Clone the repository.
+2. Open the project in a recent version of Android Studio.
+3. Build and run the app on an emulator or a physical device.
+4. Use the buttons on the screen to test each encryption provider.
+5. To use the "Lock & Test" feature, you may need to grant Device Administrator permissions to the app via the device's settings.
+
+## 5. Security Verification Procedure (Direct Boot & Authentication)
+
+This section describes how to verify the application's compliance with **FDP_DAR_EXT.2** (Encryption in Locked State) and **FIA_UAU_EXT.1** (Authentication for Decryption) using the included Test Harness.
+
+### Prerequisites
+* Android Device running Android 8.0+ (Pixel device recommended).
+* Screen Lock (PIN/Pattern/Password) **MUST** be set up.
+* ADB tool installed and authorized.
+
+### Verification Steps
+
+**Step 1: Install and Initialize**
+1. Install the application (`app-debug.apk`) on the target device.
+2. Launch the app once and ensure the screen is unlocked to allow initial key generation.
+3. Force stop the app to clear memory state:
+ ```bash
+ adb shell am force-stop com.android.niapsec
+ ```
+
+**Step 2: Reboot into "Before First Unlock" (BFU) State**
+1. Reboot the device using ADB or the power button.
+ ```bash
+ adb reboot
+ ```
+2. **CRITICAL:** When the device boots up, **DO NOT enter your PIN/Password**.
+ * The device must remain in the "Locked" state.
+ * Verify the state using:
+ ```bash
+ adb shell dumpsys activity | grep "mUserUnlocked"
+ ```
+ *Expected Output:* `mUserUnlocked=false`
+
+**Step 3: Execute the Test Harness**
+Trigger the diagnostic receiver via ADB. This component is marked as `directBootAware` and will run even when the user is locked.
+
+1. Start log monitoring in a terminal:
+ ```bash
+ adb logcat -c
+ adb logcat -s DirectBootTest
+ ```
+
+2. In a separate terminal, send the test broadcast:
+ ```bash
+ adb shell am broadcast -a com.android.niapsec.ACTION_TEST_CRYPTO -n com.android.niapsec/.demo.DirectBootTestReceiver
+ ```
+
+**Step 4: Verify Pass/Fail Criteria (Log Analysis)**
+
+Check the log output for the following verification points:
+
+#### A. Environment Validation
+* `User State: LOCKED (BFU State)` -> **MUST** be Locked.
+* `Storage Context: Device Protected (DE)` -> **MUST** use DE storage.
+
+#### B. RawHybridKeyProvider (JCA Implementation)
+* `[RawHybrid_JCA] Attempting Encryption...`
+* `[RawHybrid_JCA] SUCCESS: Encryption completed.` -> **PASS (FDP_DAR_EXT.2 Satisfied)**
+ * *Rationale:* Public Key was successfully retrieved from DE storage and used for encryption.
+* `[RawHybrid_JCA] Attempting Decryption...`
+* `[RawHybrid_JCA] SUCCESS: Decryption failed as expected during lock.` -> **PASS (FIA_UAU_EXT.1 Satisfied)**
+ * *Rationale:* Access to the Private Key (Android Keystore) was correctly blocked by the OS because the user is not authenticated.
+
+#### C. HybridKeyProvider (Tink Implementation)
+* `[Hybrid_Tink] Attempting Encryption...`
+* `[Hybrid_Tink] SUCCESS: Encryption completed.` -> **PASS (FDP_DAR_EXT.2 Satisfied)**
+* `[Hybrid_Tink] Attempting Decryption...`
+* `[Hybrid_Tink] SUCCESS: Decryption failed as expected during lock.` -> **PASS (FIA_UAU_EXT.1 Satisfied)**
+
+---
+
+### Step 5: Verify "After First Unlock" (AFU) Behavior (Optional)
+1. Unlock the screen (enter PIN).
+2. Run the broadcast command again:
+ ```bash
+ adb shell am broadcast -a com.android.niapsec.ACTION_TEST_CRYPTO -n com.android.niapsec/.demo.DirectBootTestReceiver
+ ```
+3. Verify logs:
+ * `User State: UNLOCKED (AFU State)`
+ * `SUCCESS: Decryption succeeded and data matches.` -> **PASS** (Normal operation restored).
+
+
+## 6.Testing Guide
+
+### 1. Symmetric Encrypt โ Symmetric Decrypt
+
+Verifies normal encryption and decryption when the device is unlocked.
+
+1. Tap **Test File**
+2. Tap **Check Status** โ file should show `Symmetric 0x02`
+3. Tap the file entry to decrypt and verify the plaintext
+
+### 2. Asymmetric Encrypt โ Sweep โ Symmetric Decrypt
+
+Verifies that files encrypted while locked are re-wrapped to symmetric after unlock.
+
+1. Tap **Lock & Test** (device will lock and encrypt with asymmetric key)
+2. Unlock the device and return to the app
+3. Tap **Check Status** โ file should show `Symmetric 0x02` (sweep ran automatically on unlock)
+4. Tap the file entry to decrypt and verify the plaintext
+
+### 3. Asymmetric Encrypt โ Asymmetric Decrypt (Sweep Disabled)
+
+Verifies that asymmetric-encrypted files remain unchanged and can still be decrypted without sweep.
+
+1. Open the 3-dot menu in the top bar
+2. Uncheck **Enable DAR_EXT.2.4 sweep**
+3. Tap **Lock & Test** (device will lock and encrypt with asymmetric key)
+4. Unlock the device and return to the app
+5. Tap **Check Status** โ file should show `Asymmetric 0x01` (sweep is disabled)
+6. Tap the file entry to decrypt and verify the plaintext
+
+
+## 7. License
+
+Copyright 2026 The Android Open Source Project
+
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/build.gradle.kts b/niap-cc/sdp-file-encrypt/build.gradle.kts
new file mode 100644
index 0000000..963bc56
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/build.gradle.kts
@@ -0,0 +1,7 @@
+// Top-level build file where you can add configuration options common to all sub-projects/modules.
+plugins {
+ alias(libs.plugins.android.application) apply false
+ alias(libs.plugins.kotlin.android) apply false
+ alias(libs.plugins.kotlin.compose) apply false
+ alias(libs.plugins.ksp) apply false
+}
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/doc/knowledge_base/00_Knowlege_Map.md b/niap-cc/sdp-file-encrypt/doc/knowledge_base/00_Knowlege_Map.md
new file mode 100644
index 0000000..2ce28ec
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/doc/knowledge_base/00_Knowlege_Map.md
@@ -0,0 +1,32 @@
+# Security Evaluation Knowledge Base Map
+
+This directory contains the essential documentation required for the Common Criteria (CC) evaluation of Android Security components.
+AI assistants and human evaluators should refer to this map to understand the structure and precedence of the documents.
+
+## 1. Common Criteria (CC) - Core Standards
+* **CCPART1V3.1R5.md**: Introduction and General Model. Refer to this for definitions of standard terminology (e.g., TOE, TSF).
+* **CCPART2V3.1R5.md**: Security Functional Requirements (SFR). The catalog of functional components (e.g., `FCS_CKM.1`).
+* **CCPART3V3.1R5.md**: Security Assurance Requirements (SAR). The criteria for assurance depth and deliverables (e.g., `ADV_FSP`).
+
+## 2. Methodology - Evaluation Procedures
+* **CEMV3.1R5.md** (ISO/IEC 18045): Common Evaluation Methodology. Contains specific inspection procedures and pass/fail criteria for evaluators.
+
+## 3. Requirements for Mobile - Specific Rules
+* **PP_MDF_V3.3.md**: Mobile Device Fundamentals Protection Profile.
+ * **CRITICAL:** This document defines the specific security requirements for Android devices.
+ * **Precedence:** When checking for implementation requirements, the definitions in this PP **override** or refine the generic definitions in CC Part 2.
+
+## 4. Security Targets (ST) - Implementation Examples
+* **st-samsung-android15.md**: Security Target for Samsung devices (Reference).
+* **st-google-android15.md**: Security Target for Google Pixel devices (Reference).
+* *Note: Use these to understand how specific requirements are typically implemented and documented by major vendors.*
+
+---
+
+## AI System Instructions (Rules of Precedence)
+
+When generating responses or code based on this knowledge base, strictly adhere to the following order of precedence:
+
+1. **Requirement Specifics:** Always prioritize **`PP_MDF_V3.3`**. If the PP defines a specific parameter for an algorithm (e.g., "AES-GCM must use a 96-bit IV"), this takes precedence over generic CC documents.
+2. **Definitions:** For general understanding of requirement IDs (e.g., what `FCS_CKM.1` generally means), refer to **`CCPART2V3.1R5md`**.
+3. **Testing & Assurance:** For questions regarding test depth, coverage analysis, or document detail levels, refer to **`CCPART3V3.1R5.md`** and **`CEMV3.1R5.md`**.
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/doc/knowledge_base/CCPART1V3.1R5.md b/niap-cc/sdp-file-encrypt/doc/knowledge_base/CCPART1V3.1R5.md
new file mode 100644
index 0000000..58fe71b
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/doc/knowledge_base/CCPART1V3.1R5.md
@@ -0,0 +1,6385 @@
+Consider using the pymupdf_layout package for a greatly improved page layout analysis.
+# **Foreword**
+
+This version of the Common Criteria for Information Technology Security Evaluation (CC
+v3.1) is the first major revision since being published as CC v2.3 in 2005.
+
+CC v3.1 aims to: eliminate redundant evaluation activities; reduce/eliminate activities that
+contribute little to the final assurance of a product; clarify CC terminology to reduce
+misunderstanding; restructure and refocus the evaluation activities to those areas where
+security assurance is gained; and add new CC requirements if needed.
+
+CC version 3.1 consists of the following parts:
+
+
+๏ญ Part 1: Introduction and general model
+
+
+๏ญ Part 2: Security functional components
+
+
+๏ญ Part 3: Security assurance components
+
+
+_**Trademarks:**_
+
+
+๏ญ UNIX is a registered trademark of The Open Group in the United States and other
+countries
+
+
+๏ญ Windows is a registered trademark of Microsoft Corporation in the United States
+and other countries
+
+
+Page 2 of 106 Version 3.1 April 2017
+
+
+_**Legal Notice:**_
+
+_The governmental organisations listed below contributed to the development of this version_
+_of the Common Criteria for Information Technology Security Evaluation. As the joint_
+_holders of the copyright in the Common Criteria for Information Technology Security_
+_Evaluation, version_ 3.1 _Parts 1 through 3 (called โCC_ 3.1 _โ), they hereby grant non-_
+_exclusive license to ISO/IEC to use CC_ 3.1 _in the continued development/maintenance of the_
+_ISO/IEC 15408 international standard. However, these governmental organisations retain_
+_the right to use, copy, distribute, translate or modify CC_ 3.1 _as they see fit._
+
+_Australia:_ _The Australian Signals Directorate;_
+_Canada:_ _Communications Security Establishment;_
+_France:_ _Agence Nationale de la Sรฉcuritรฉ des Systรจmes d'Information;_
+_Germany:_ _Bundesamt fรผr Sicherheit in der Informationstechnik;_
+_Japan:_ _Information Technology Promotion Agency;_
+_Netherlands:_ _Netherlands National Communications Security Agency;_
+_New Zealand:_ _Government Communications Security Bureau;_
+_Republic of Korea:_ _National Security Research Institute;_
+_Spain:_ _Ministerio de Administraciones Pรบblicas and_
+_Centro Criptolรณgico Nacional;_
+_Sweden:_ _Swedish Defence Materiel Administration;_
+_United Kingdom:_ _National Cyber Security Centre;_
+_United States:_ _The National Security Agency and the_
+_National Institute of Standards and Technology._
+
+
+April 2017 Version 3.1 Page 3 of 106
+
+
+**Table of contents**
+
+# **Table of Contents**
+
+
+**1** **INTRODUCTION ............................................................................................. 11**
+
+
+**2** **SCOPE ........................................................................................................... 13**
+
+
+**3** **NORMATIVE REFERENCES ......................................................................... 14**
+
+
+**4** **TERMS AND DEFINITIONS ........................................................................... 15**
+
+
+**4.1** **Terms and definitions common in the CC ........................................................................................... 15**
+
+
+**4.2** **Terms and definitions related to the ADV class .................................................................................. 21**
+
+
+**4.3** **Terms and definitions related to the AGD class .................................................................................. 26**
+
+
+**4.4** **Terms and definitions related to the ALC class .................................................................................. 26**
+
+
+**4.5** **Terms and definitions related to the AVA class .................................................................................. 30**
+
+
+**4.6** **Terms and definitions related to the ACO class .................................................................................. 30**
+
+
+**5** **SYMBOLS AND ABBREVIATED TERMS ..................................................... 32**
+
+
+**6** **OVERVIEW ..................................................................................................... 34**
+
+
+**6.1** **The TOE ................................................................................................................................................. 34**
+6.1.1 Different representations of the TOE ............................................................................................. 35
+6.1.2 Different configurations of the TOE ............................................................................................... 35
+
+
+**6.2** **Target audience of the CC ..................................................................................................................... 36**
+6.2.1 Consumers ...................................................................................................................................... 36
+6.2.2 Developers ...................................................................................................................................... 36
+6.2.3 Evaluators ....................................................................................................................................... 36
+6.2.4 Others ............................................................................................................................................. 36
+
+
+**6.3** **The different parts of the CC ................................................................................................................ 37**
+
+
+**6.4** **Evaluation context .................................................................................................................................. 38**
+
+
+**7** **GENERAL MODEL ......................................................................................... 40**
+
+
+**7.1** **Assets and countermeasures .................................................................................................................. 40**
+7.1.1 Sufficiency of the countermeasures ................................................................................................ 42
+7.1.2 Correctness of the TOE .................................................................................................................. 44
+7.1.3 Correctness of the Operational Environment .................................................................................. 44
+
+
+**7.2** **Evaluation ............................................................................................................................................... 45**
+
+
+**8** **TAILORING SECURITY REQUIREMENTS ................................................... 47**
+
+
+**8.1** **Operations .............................................................................................................................................. 47**
+8.1.1 The iteration operation.................................................................................................................... 48
+
+
+Page 4 of 106 Version 3.1 April 2017
+
+
+**Table of contents**
+
+
+8.1.2 The assignment operation ............................................................................................................... 48
+8.1.3 The selection operation ................................................................................................................... 49
+8.1.4 The refinement operation ................................................................................................................ 49
+
+
+**8.2** **Dependencies between components ...................................................................................................... 50**
+
+
+**8.3** **Extended components ............................................................................................................................ 51**
+
+
+**9** **PROTECTION PROFILES AND PACKAGES ................................................ 52**
+
+
+**9.1** **Introduction ............................................................................................................................................ 52**
+
+
+**9.2** **Packages .................................................................................................................................................. 52**
+
+
+**9.3** **Protection Profiles .................................................................................................................................. 52**
+
+
+**9.4** **Using PPs and packages ......................................................................................................................... 55**
+
+
+**9.5** **Using Multiple Protection Profiles ........................................................................................................ 56**
+
+
+**9.6** **Protection Profiles, PP-Modules and PP-Configurations ................................................................... 56**
+9.6.1 Introduction .................................................................................................................................... 56
+9.6.2 PP-Modules .................................................................................................................................... 56
+9.6.3 PP-Configurations........................................................................................................................... 57
+9.6.4 Using PP-Modules and PP-Configurations in security targets ....................................................... 57
+
+
+**10** **EVALUATION RESULTS ............................................................................... 59**
+
+
+**10.1** **Introduction ....................................................................................................................................... 59**
+
+
+**10.2** **Results of a PP evaluation ................................................................................................................. 60**
+
+
+**10.3** **Results of a PP-Configuration evaluation ....................................................................................... 60**
+
+
+**10.4** **Results of an ST/TOE evaluation ..................................................................................................... 60**
+
+
+**10.5** **Conformance claim ........................................................................................................................... 61**
+
+
+**10.6** **Use of ST/TOE evaluation results .................................................................................................... 62**
+
+
+**A** **SPECIFICATION OF SECURITY TARGETS ................................................. 64**
+
+
+**A.1** **Goal and structure of this Annex ..................................................................................................... 64**
+
+
+**A.2** **Mandatory contents of an ST ........................................................................................................... 64**
+
+
+**A.3** **Using an ST ........................................................................................................................................ 66**
+A.3.1 How an ST should be used ............................................................................................................. 66
+A.3.2 How an ST should not be used ....................................................................................................... 66
+
+
+**A.4** **ST Introduction (ASE_INT) ............................................................................................................. 66**
+A.4.1 ST reference and TOE reference .................................................................................................... 67
+A.4.2 TOE overview ................................................................................................................................. 67
+A.4.3 TOE description .............................................................................................................................. 69
+
+
+**A.5** **Conformance claims (ASE_CCL) .................................................................................................... 70**
+
+
+April 2017 Version 3.1 Page 5 of 106
+
+
+**Table of contents**
+
+
+**A.6** **Security problem definition (ASE_SPD) ......................................................................................... 70**
+A.6.1 Introduction .................................................................................................................................... 70
+A.6.2 Threats ............................................................................................................................................ 71
+A.6.3 Organisational security policies (OSPs) ......................................................................................... 71
+A.6.4 Assumptions ................................................................................................................................... 72
+
+
+**A.7** **Security objectives (ASE_OBJ) ........................................................................................................ 73**
+A.7.1 High-level solution ......................................................................................................................... 73
+A.7.2 Part wise solutions .......................................................................................................................... 73
+A.7.3 Relation between security objectives and the security problem definition ..................................... 74
+A.7.4 Security objectives: conclusion ...................................................................................................... 76
+
+
+**A.8** **Extended Components Definition (ASE_ECD)............................................................................... 76**
+
+
+**A.9** **Security requirements (ASE_REQ) ................................................................................................. 77**
+A.9.1 Security functional requirements (SFRs) ........................................................................................ 77
+A.9.2 Security assurance requirements (SARs) ........................................................................................ 79
+A.9.3 SARs and the security requirement rationale ................................................................................. 79
+A.9.4 Security requirements: conclusion .................................................................................................. 80
+
+
+**A.10** **TOE summary specification (ASE_TSS) ......................................................................................... 80**
+
+
+**A.11** **Questions that may be answered with an ST .................................................................................. 81**
+
+
+**A.12** **Low assurance Security Targets ...................................................................................................... 82**
+
+
+**A.13** **Referring to other standards in an ST ............................................................................................. 83**
+
+
+**B** **SPECIFICATION OF PROTECTION PROFILES ........................................... 85**
+
+
+**B.1** **Goal and structure of this Annex ..................................................................................................... 85**
+
+
+**B.2** **Mandatory contents of a PP ............................................................................................................. 85**
+
+
+**B.3** **Using the PP ....................................................................................................................................... 86**
+B.3.1 How a PP should be used ............................................................................................................... 86
+B.3.2 How a PP should not be used ......................................................................................................... 87
+
+
+**B.4** **PP introduction (APE_INT) ............................................................................................................. 87**
+B.4.1 PP reference .................................................................................................................................... 87
+B.4.2 TOE overview ................................................................................................................................ 88
+
+
+**B.5** **Conformance claims (APE_CCL) .................................................................................................... 89**
+
+
+**B.6** **Security problem definition (APE_SPD) ......................................................................................... 89**
+
+
+**B.7** **Security objectives (APE_OBJ)........................................................................................................ 89**
+
+
+**B.8** **Extended components definition (APE_ECD) ................................................................................ 89**
+
+
+**B.9** **Security requirements (APE_REQ) ................................................................................................. 89**
+
+
+**B.10** **TOE summary specification ............................................................................................................. 89**
+
+
+**B.11** **Low assurance Protection Profiles ................................................................................................... 89**
+
+
+**B.12** **Referring to other standards in a PP ............................................................................................... 90**
+
+
+**B.13** **Interpretation of PP-Configuration as a standard PP ................................................................... 91**
+
+
+Page 6 of 106 Version 3.1 April 2017
+
+
+**Table of contents**
+
+
+B.13.1 TOE type .................................................................................................................................... 91
+B.13.2 Conformance claims .................................................................................................................. 91
+B.13.3 Security problem definition ....................................................................................................... 91
+B.13.4 Security objectives ..................................................................................................................... 91
+B.13.5 Extended functional components definition ............................................................................... 91
+B.13.6 Security functional requirements ............................................................................................... 92
+
+
+**B.14** **Specification of PP-Modules ............................................................................................................. 92**
+B.14.1 Mandatory content of a PP-Module ........................................................................................... 92
+B.14.2 Using the PP-Module ................................................................................................................. 93
+B.14.3 PP-Module introduction ............................................................................................................. 93
+B.14.4 Consistency rationale ................................................................................................................. 94
+B.14.5 Conformance claims .................................................................................................................. 95
+B.14.6 Security problem definition ....................................................................................................... 95
+B.14.7 Security objectives ..................................................................................................................... 96
+B.14.8 Extended functional components definition ............................................................................... 97
+B.14.9 Security functional requirements ............................................................................................... 97
+B.14.10 Guidance for inclusion of elements from Base-PP .................................................................... 97
+
+
+**B.15** **Specification of PP-Configurations .................................................................................................. 98**
+B.15.1 Mandatory content of a PP-Configuration ................................................................................. 98
+B.15.2 Using the PP-Configuration ....................................................................................................... 98
+B.15.3 PP-Configuration reference........................................................................................................ 98
+B.15.4 PP-Configuration components statement ................................................................................... 99
+B.15.5 PP-Configuration conformance statement ................................................................................. 99
+B.15.6 PP-Configuration SAR statement .............................................................................................. 99
+B.15.7 Evaluation of a PP-Configuration .............................................................................................. 99
+
+
+**C** **GUIDANCE FOR OPERATIONS .................................................................. 100**
+
+
+**C.1** **Introduction ..................................................................................................................................... 100**
+
+
+**C.2** **Examples of operations ................................................................................................................... 100**
+C.2.1 The iteration operation .................................................................................................................. 100
+C.2.2 The assignment operation ............................................................................................................. 100
+C.2.3 The selection operation ................................................................................................................. 101
+C.2.4 The refinement operation .............................................................................................................. 101
+
+
+**C.3** **Organisation of components ........................................................................................................... 102**
+C.3.1 Class ............................................................................................................................................. 102
+C.3.2 Family ........................................................................................................................................... 102
+C.3.3 Component.................................................................................................................................... 102
+C.3.4 Element ......................................................................................................................................... 102
+
+
+**C.4** **Extended components ..................................................................................................................... 103**
+C.4.1 How to define extended components ............................................................................................ 103
+
+
+**D** **PP CONFORMANCE ................................................................................... 104**
+
+
+**D.1** **Introduction ..................................................................................................................................... 104**
+
+
+**D.2** **Strict conformance .......................................................................................................................... 104**
+
+
+**D.3** **Demonstrable conformance ............................................................................................................ 105**
+
+
+**E** **BIBLIOGRAPHY .......................................................................................... 106**
+
+
+April 2017 Version 3.1 Page 7 of 106
+
+
+**Table of contents**
+
+
+**E.1** **ISO/IEC standards and guidance .................................................................................................. 106**
+
+
+**E.2** **Other standards and guidance ....................................................................................................... 106**
+
+
+Page 8 of 106 Version 3.1 April 2017
+
+
+**List of figures**
+
+# **List of figures**
+
+
+Figure 1 - Terminology in CM and in the product life-cycle ................................................ 30
+Figure 2 - Security concepts and relationships ...................................................................... 41
+Figure 3 - Evaluation concepts and relationships .................................................................. 42
+Figure 4 - Evaluation results .................................................................................................. 59
+Figure 5 - Security Target contents ....................................................................................... 65
+Figure 6 - Tracings between security objectives and security problem definition ................ 75
+Figure 7 - Relations between the security problem definition, the security objectives and the
+security requirements ............................................................................................................. 80
+Figure 8 - Contents of a Low Assurance Security Target ..................................................... 83
+Figure 9 - Protection Profile contents .................................................................................... 86
+Figure 10 - Contents of a Low Assurance Protection Profile ................................................ 90
+Figure 11 - PP-Module content ............................................................................................. 92
+
+
+April 2017 Version 3.1 Page 9 of 106
+
+
+**List of tables**
+
+# **List of tables**
+
+
+Table 1 - Road map to the Common Criteria ........................................................................ 38
+
+
+Page 10 of 106 Version 3.1 April 2017
+
+
+**Introduction**
+
+# **1 Introduction**
+
+
+1 The CC permits comparability between the results of independent security
+evaluations. The CC does so by providing a common set of requirements for
+the security functionality of IT products and for assurance measures applied
+to these IT products during a security evaluation. These IT products may be
+implemented in hardware, firmware or software.
+
+
+2 The evaluation process establishes a level of confidence that the security
+functionality of these IT products and the assurance measures applied to
+these IT products meet these requirements. The evaluation results may help
+consumers to determine whether these IT products fulfil their security needs.
+
+
+3 The CC is useful as a guide for the development, evaluation and/or
+procurement of IT products with security functionality.
+
+
+4 The CC is intentionally flexible, enabling a range of evaluation methods to
+be applied to a range of security properties of a range of IT products.
+Therefore users of the standard are cautioned to exercise care that this
+flexibility is not misused. For example, using the CC in conjunction with
+unsuitable evaluation methods, irrelevant security properties, or
+inappropriate IT products, may result in meaningless evaluation results.
+
+
+5 Consequently, the fact that an IT product has been evaluated has meaning
+only in the context of the security properties that were evaluated and the
+evaluation methods that were used. Evaluation authorities are advised to
+carefully check the products, properties and methods to determine that an
+evaluation will provide meaningful results. Additionally, purchasers of
+evaluated products are advised to carefully consider this context to determine
+whether the evaluated product is useful and applicable to their specific
+situation and needs.
+
+
+6 The CC addresses protection of assets from unauthorised disclosure,
+modification, or loss of use. The categories of protection relating to these
+three types of failure of security are commonly called confidentiality,
+integrity, and availability, respectively. The CC may also be applicable to
+aspects of IT security outside of these three. The CC is applicable to risks
+arising from human activities (malicious or otherwise) and to risks arising
+from non-human activities. Apart from IT security, the CC may be applied in
+other areas of IT, but makes no claim of applicability in these areas.
+
+
+7 Certain topics, because they involve specialised techniques or because they
+are somewhat peripheral to IT security, are considered to be outside the
+scope of the CC. Some of these are identified below.
+
+
+a) The CC does not contain security evaluation criteria pertaining to
+administrative security measures not related directly to the IT security
+functionality. However, it is recognised that significant security can
+often be achieved through or supported by administrative measures
+such as organisational, personnel, physical, and procedural controls.
+
+
+April 2017 Version 3.1 Page 11 of 106
+
+
+**Introduction**
+
+
+b) The evaluation of some technical physical aspects of IT security such
+as electromagnetic emanation control is not specifically covered,
+although many of the concepts addressed will be applicable to that
+area.
+
+
+c) The CC does not address the evaluation methodology under which
+the criteria should be applied. This methodology is given in the CEM.
+
+
+d) The CC does not address the administrative and legal framework
+under which the criteria may be applied by evaluation authorities.
+However, it is expected that the CC will be used for evaluation
+purposes in the context of such a framework.
+
+
+e) The procedures for use of evaluation results in accreditation are
+outside the scope of the CC. Accreditation is the administrative
+process whereby authority is granted for the operation of an IT
+product (or collection thereof) in its full operational environment
+including all of its non-IT parts. The results of the evaluation process
+are an input to the accreditation process. However, as other
+techniques are more appropriate for the assessments of non-IT related
+properties and their relationship to the IT security parts, accreditors
+should make separate provisions for those aspects.
+
+
+f) The subject of criteria for the assessment of the inherent qualities of
+cryptographic algorithms is not covered in the CC. Should
+independent assessment of mathematical properties of cryptography
+be required, the evaluation scheme under which the CC is applied
+must make provision for such assessments.
+
+
+8 ISO terminology, such as "can", "informative", "may", "normative", "shall"
+and "should" used throughout the document are defined in the ISO/IEC
+Directives, Part 2. Note that the term "should" has an additional meaning
+applicable when using this standard. See the note below. The following
+definition is given for the use of โshouldโ in the CC.
+
+
+9 **should** ๏พ within normative text, โshouldโ indicates โthat among several
+possibilities one is recommended as particularly suitable, without mentioning
+or excluding others, or that a certain course of action is preferred but not
+necessarily required.โ (ISO/IEC Directives, Part 2).
+
+
+The CC interprets โnot necessarily requiredโ to mean that the choice of
+another possibility requires a justification of why the preferred option was
+not chosen.
+
+
+Page 12 of 106 Version 3.1 April 2017
+
+
+**Scope**
+
+# **2 Scope**
+
+
+10 This part of the CC establishes the general concepts and principles of IT
+security evaluation and specifies the general model of evaluation given by
+various parts of the standard which in its entirety is meant to be used as the
+basis for evaluation of security properties of IT products.
+
+
+11 Part one provides an overview of all parts of the CC standard. It describes the
+various parts of the standard; defines the terms and abbreviations to be used
+in all parts of the standard; establishes the core concept of a Target of
+Evaluation (TOE); the evaluation context and describes the audience to
+which the evaluation criteria are addressed. An introduction to the basic
+security concepts necessary for evaluation of IT products is given.
+
+
+12 It defines the various operations by which the functional and assurance
+components given in CC Part 2 and CC Part 3 may be tailored through the
+use of permitted operations.
+
+
+13 The key concepts of protection profiles (PP), packages of security
+requirements and the topic of conformance are specified and the
+consequences of evaluation, evaluation results are described. This part of the
+CC gives guidelines for the specification of Security Targets (ST) and
+provides a description of the organization of components throughout the
+model. General information about the evaluation methodology are given in
+the CEM and the scope of evaluation schemes is provided.
+
+
+April 2017 Version 3.1 Page 13 of 106
+
+
+**Normative references**
+
+# **3 Normative references**
+
+
+14 The following referenced documents are indispensable for the application of
+this CC part 1. For dated references, only the edition cited applies. For
+undated references, the latest edition of the referenced document (including
+any amendments) applies.
+
+
+[CC-2] Common Criteria for Information Technology
+Security Evaluation, Version 3.1, revision 5, April
+2017. Part 2: Functional security components.
+
+
+[CC-3] Common Criteria for Information Technology
+Security Evaluation, Version 3.1, revision 5, April
+2017. Part 3: Assurance security components.
+
+
+[CEM] Common Methodology for Information Technology
+Security Evaluation, Version 3.1, revision 5, April
+2017.
+
+
+Page 14 of 106 Version 3.1 April 2017
+
+
+**Terms and definitions**
+
+# **4 Terms and definitions**
+
+
+15 For the purpose of the CC, the following terms and definitions apply.
+
+
+16 This Chapter 4 contains only those terms which are used in a specialised way
+throughout the CC. Some combinations of common terms used in the CC,
+while not meriting inclusion in this Chapter 4, are explained for clarity in the
+context where they are used.
+
+## **4.1 Terms and definitions common in the CC**
+
+
+17 **adverse actions** ๏พ actions performed by a threat agent on an asset
+
+
+18 **assets** ๏พ entities that the owner of the TOE presumably places value upon
+
+
+19 **assignment** ๏พ the specification of an identified parameter in a component
+(of the CC) or requirement
+
+
+20 **assurance** ๏พ grounds for confidence that a TOE meets the SFRs
+
+
+21 **attack potential** ๏พ measure of the effort to be expended in attacking a TOE,
+expressed in terms of an attacker's expertise, resources and motivation
+
+
+22 **augmentation** ๏พ addition of one or more requirement(s) to a package
+
+
+23 **authentication data** ๏พ information used to verify the claimed identity of a
+user
+
+
+24 **authorised user** ๏พ TOE user who may, in accordance with the SFRs,
+perform an operation
+
+
+25 **Base Protection Profile** ๏พ Protection Profile used as a basis to build a
+Protection Profile Configuration
+
+
+26 **class** ๏พ set of CC families that share a common focus
+
+
+27 **coherent** ๏พ logically ordered and having discernible meaning
+
+
+For documentation, this addresses both the actual text and the structure of the
+document, in terms of whether it is understandable by its target audience.
+
+
+28 **complete** ๏พ property where all necessary parts of an entity have been
+provided
+
+
+In terms of documentation, this means that all relevant information is
+covered in the documentation, at such a level of detail that no further
+explanation is required at that level of abstraction.
+
+
+29 **component** ๏พ smallest selectable set of elements on which requirements
+may be based
+
+
+April 2017 Version 3.1 Page 15 of 106
+
+
+**Terms and definitions**
+
+
+30 **composed assurance package** ๏พ assurance package consisting of
+requirements drawn from CC Part 3 (predominately from the ACO class),
+representing a point on the CC predefined composition assurance scale
+
+
+31 **confirm** ๏พ declare that something has been reviewed in detail with an
+independent determination of sufficiency
+
+
+The level of rigour required depends on the nature of the subject matter. This
+term is only applied to evaluator actions.
+
+
+32 **connectivity** ๏พ property of the TOE allowing interaction with IT entities
+external to the TOE
+
+
+This includes exchange of data by wire or by wireless means, over any
+distance in any environment or configuration.
+
+
+33 **consistent** ๏พ relationship between two or more entities such that there are
+no apparent contradictions between these entities
+
+
+34 **counter, verb** ๏พ meet an attack where the impact of a particular threat is
+mitigated but not necessarily eradicated
+
+
+35 **demonstrable conformance** ๏พ relation between an ST and a PP, where the
+ST provides a solution which solves the generic security problem in the PP
+
+
+The PP and the ST may contain entirely different statements that discuss
+different entities, use different concepts etc. Demonstrable conformance is
+also suitable for a TOE type where several similar PPs already exist, thus
+allowing the ST author to claim conformance to these PPs simultaneously,
+thereby saving work.
+
+
+36 **demonstrate** ๏พ provide a conclusion gained by an analysis which is less
+rigorous than a โproofโ
+
+
+37 **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
+
+
+38 **describe** ๏พ provide specific details of an entity
+
+
+39 **determine** ๏พ affirm a particular conclusion based on independent analysis
+with the objective of reaching a particular conclusion
+
+
+The usage of this term implies a truly independent analysis, usually in the
+absence of any previous analysis having been performed. Compare with the
+terms โconfirmโ or โverifyโ which imply that an analysis has already been
+performed which needs to be reviewed
+
+
+40 **development environment** ๏พ environment in which the TOE is developed
+
+
+Page 16 of 106 Version 3.1 April 2017
+
+
+**Terms and definitions**
+
+
+41 **element** ๏พ indivisible statement of a security need
+
+
+42 **ensure** ๏พ guarantee a strong causal relationship between an action and its
+consequences
+
+
+When this term is preceded by the word โhelpโ it indicates that the
+consequence is not fully certain, on the basis of that action alone.
+
+
+43 **evaluation** ๏พ assessment of a PP, an ST or a TOE, against defined criteria
+
+
+44 **evaluation assurance level** ๏พ set of assurance requirements drawn from CC
+Part 3, representing a point on the CC predefined assurance scale, that form
+an assurance package
+
+
+45 **evaluation authority** ๏พ body that sets the standards and monitors the
+quality of evaluations conducted by bodies within a specific community and
+implements the CC for that community by means of an evaluation scheme
+
+
+46 **evaluation scheme** ๏พ administrative and regulatory framework under which
+the CC is applied by an evaluation authority within a specific community
+
+
+47 **exhaustive** ๏พ characteristic of a methodical approach taken to perform an
+analysis or activity according to an unambiguous plan
+
+
+This term is used in the CC with respect to conducting an analysis or other
+activity. It is related to โsystematicโ but is considerably stronger, in that it
+indicates not only that a methodical approach has been taken to perform the
+analysis or activity according to an unambiguous plan, but that the plan that
+was followed is sufficient to ensure that all possible avenues have been
+exercised.
+
+
+48 **explain** ๏พ give argument accounting for the reason for taking a course of
+action
+
+
+This term differs from both โdescribeโ and โdemonstrateโ. It is intended to
+answer the question โWhy?โ without actually attempting to argue that the
+course of action that was taken was necessarily optimal.
+
+
+49 **extension** ๏พ addition to an ST or PP of functional requirements not
+contained in CC Part 2 and/or assurance requirements not contained in CC
+Part 3
+
+
+50 **external entity** ๏พ human or IT entity possibly interacting with the TOE
+from outside of the TOE boundary
+
+
+51 **family** ๏พ set of components that share a similar goal but differ in emphasis
+or rigour
+
+
+52 **formal** ๏พ expressed in a restricted syntax language with defined semantics
+based on well-established mathematical concepts
+
+
+April 2017 Version 3.1 Page 17 of 106
+
+
+**Terms and definitions**
+
+
+53 **guidance documentation** ๏พ documentation that describes the delivery,
+preparation, operation, management and/or use of the TOE
+
+
+54 **identity** ๏พ representation uniquely identifying entities (e.g. a user, a process
+or a disk) within the context of the TOE
+
+
+An example of such a representation is a string. For a human user, the
+representation can be the full or abbreviated name or a (still unique)
+pseudonym.
+
+
+55 **informal** ๏พ expressed in natural language
+
+
+56 **inter TSF transfers** ๏พ communicating data between the TOE and the
+security functionality of other trusted IT products
+
+
+57 **internal communication channel** ๏พ communication channel between
+separated parts of the TOE
+
+
+58 **internal TOE transfer** ๏พ communicating data between separated parts of
+the TOE
+
+
+59 **internally consistent** ๏พ no apparent contradictions exist between any
+aspects of an entity
+
+
+In terms of documentation, this means that there can be no statements within
+the documentation that can be taken to contradict each other.
+
+
+60 **iteration** ๏พ use of the same component to express two or more distinct
+requirements
+
+
+61 **justification** ๏พ analysis leading to a conclusion
+
+
+โJustificationโ is more rigorous than a demonstration. This term requires
+significant rigour in terms of very carefully and thoroughly explaining every
+step of a logical argument.
+
+
+62 **object** ๏พ passive entity in the TOE, that contains or receives information,
+and upon which subjects perform operations
+
+
+63 **operation (on a component of the CC)** ๏พ modification or repetition of a
+component
+
+
+Allowed operations on components are assignment, iteration, refinement and
+selection.
+
+
+64 **operation (on an object)** ๏พ specific type of action performed by a subject
+on an object
+
+
+65 **operational environment** ๏พ environment in which the TOE is operated
+
+
+Page 18 of 106 Version 3.1 April 2017
+
+
+**Terms and definitions**
+
+
+66 **organisational security policy** ๏พ set of security rules, procedures, or
+guidelines for an organisation
+
+
+A policy may pertain to a specific operational environment.
+
+
+67 **package** ๏พ named set of either security functional or security assurance
+requirements
+
+
+An example of a package is โEAL 3โ.
+
+
+68 **Protection Profile Configuration** ๏พ Protection Profile composed of Base
+Protection Profiles and Protection Profile Module
+
+
+69 **Protection Profile evaluation** ๏พ assessment of a PP against defined criteria
+
+
+70 **Protection Profile** ๏พ implementation-independent statement of security
+needs for a TOE type
+
+
+71 **Protection Profile Module** ๏พ implementation-independent statement of
+security needs for a TOE type complementary to one or more Base
+Protection Profiles
+
+
+72 **prove** ๏พ show correspondence by formal analysis in its mathematical sense
+
+
+It is completely rigorous in all ways. Typically, โproveโ is used when there is
+a desire to show correspondence between two TSF representations at a high
+level of rigour.
+
+
+73 **refinement** ๏พ addition of details to a component
+
+
+74 **role** ๏พ predefined set of rules establishing the allowed interactions between
+a user and the TOE
+
+
+75 **secret** ๏พ information that must be known only to authorised users and/or the
+TSF in order to enforce a specific SFP
+
+
+76 **secure state** ๏พ state in which the TSF data are consistent and the TSF
+continues correct enforcement of the SFRs
+
+
+77 **security attribute** ๏พ property of subjects, users (including external IT
+products), objects, information, sessions and/or resources that is used in
+defining the SFRs and whose values are used in enforcing the SFRs
+
+
+78 **security function policy** ๏พ set of rules describing specific security
+behaviour enforced by the TSF and expressible as a set of SFRs
+
+
+79 **security objective** ๏พ statement of an intent to counter identified threats
+and/or satisfy identified organisation security policies and/or assumptions
+
+
+80 **security problem** ๏พ statement which in a formal manner defines the nature
+and scope of the security that the TOE is intended to address
+
+
+April 2017 Version 3.1 Page 19 of 106
+
+
+**Terms and definitions**
+
+
+This statement consists of a combination of:
+
+
+๏ญ threats to be countered by the TOE and its operational environment,
+
+
+๏ญ the OSPs enforced by the TOE and its operational environment, and
+
+
+๏ญ the assumptions that are upheld for the operational environment of
+the TOE.
+
+
+81 **security requirement** ๏พ requirement, stated in a standardised language,
+which is meant to contribute to achieving the security objectives for a TOE
+
+
+82 **Security Target** ๏พ implementation-dependent statement of security needs
+for a specific identified TOE
+
+
+83 **selection** ๏พ specification of one or more items from a list in a component
+
+
+84 **semiformal** ๏พ expressed in a restricted syntax language with defined
+semantics
+
+
+85 **specify** ๏พ provide specific details about an entity in a rigorous and precise
+manner
+
+
+86 **strict conformance** ๏พ hierarchical relationship between a PP and an ST
+where all the requirements in the PP also exist in the ST
+
+
+This relation can be roughly defined as โthe ST shall contain all statements
+that are in the PP, but may contain moreโ. Strict conformance is expected to
+be used for stringent requirements that are to be adhered to in a single
+manner.
+
+
+87 **ST evaluation** ๏พ assessment of an ST against defined criteria
+
+
+88 **subject** ๏พ active entity in the TOE that performs operations on objects
+
+
+89 **target of evaluation** ๏พ set of software, firmware and/or hardware possibly
+accompanied by guidance
+
+
+90 **threat agent** ๏พ entity that can adversely act on assets
+
+
+91 **TOE evaluation** ๏พ assessment of a TOE against defined criteria
+
+
+92 **TOE resource** ๏พ anything useable or consumable in the TOE
+
+
+93 **TOE security functionality** ๏พ combined functionality of all hardware,
+software, and firmware of a TOE that must be relied upon for the correct
+enforcement of the SFRs
+
+
+94 **trace, verb** ๏พ perform an informal correspondence analysis between two
+entities with only a minimal level of rigour
+
+
+Page 20 of 106 Version 3.1 April 2017
+
+
+**Terms and definitions**
+
+
+95 **transfers outside of the TOE** ๏พ TSF mediated communication of data to
+entities not under the control of the TSF
+
+
+96 **translation** ๏พ describes the process of describing security requirements in a
+standardised language.
+
+
+use of the term translation in this context is not literal and does not imply
+that every SFR expressed in standardised language can also be translated
+back to the security objectives.
+
+
+97 **trusted channel** ๏พ a means by which a TSF and another trusted IT product
+can communicate with necessary confidence
+
+
+98 **trusted IT product** ๏พ IT product, other than the TOE, which has its
+security functional requirements administratively coordinated with the TOE
+and which is assumed to enforce its security functional requirements
+correctly
+
+
+An example of a trusted IT product would be one that has been separately
+evaluated.
+
+
+99 **trusted path** ๏พ means by which a user and a TSF can communicate with the
+necessary confidence
+
+
+100 **TSF data** ๏พ data for the operation of the TOE upon which the enforcement
+of the SFR relies
+
+
+101 **TSF interface** ๏พ means by which external entities (or subjects in the TOE
+but outside of the TSF) supply data to the TSF, receive data from the TSF
+and invoke services from the TSF
+
+
+102 **user** ๏พ see external entity
+
+
+103 **user data** ๏พ data for the user, that does not affect the operation of the TSF
+
+
+104 **verify** ๏พ rigorously review in detail with an independent determination of
+sufficiency
+
+
+Also see โconfirmโ. This term has more rigorous connotations. The term
+โverifyโ is used in the context of evaluator actions where an independent
+effort is required of the evaluator.
+
+## **4.2 Terms and definitions related to the ADV class**
+
+
+105 The following terms are used in the requirements for software internal
+structuring. Some of these are derived from the [IEEE Std 610.121990] _IEEE Std 610.12-1990, Standard glossary of software engineering_
+_terminology, Institute of Electrical and Electronics Engineers_ .
+
+
+106 **administrator** ๏พ entity that has a level of trust with respect to all policies
+implemented by the TSF
+
+
+April 2017 Version 3.1 Page 21 of 106
+
+
+**Terms and definitions**
+
+
+Not all PPs or STs assume the same level of trust for administrators.
+Typically administrators are assumed to adhere at all times to the policies in
+the ST of the TOE. Some of these policies may be related to the functionality
+of the TOE, others may be related to the operational environment.
+
+
+107 **call tree** ๏พ identifies the modules in a system in diagrammatic form
+showing which modules call one another
+
+
+Adapted from [IEEE Std 610.12-1990]
+
+
+108 **cohesion** ๏พ module strength manner and degree to which the tasks
+performed by a single software module are related to one another
+
+
+[IEEE Std 610.12-1990]
+
+
+Types of cohesion include coincidental, communicational, functional, logical,
+sequential, and temporal. These types of cohesion are described by the
+relevant term entry.
+
+
+109 **coincidental cohesion** ๏พ module with the characteristic of performing
+unrelated, or loosely related, activities
+
+
+[IEEE Std 610.12-1990]
+
+
+See โcohesionโ.
+
+
+110 **communicational cohesion** ๏พ module containing functions that produce
+output for, or use output from, other functions within the module
+
+
+[IEEE Std 610.12-1990]
+
+
+111 See โcohesionโ.
+
+
+112 An example of a communicationally cohesive module is an access check
+module that includes mandatory, discretionary, and capability checks.
+
+
+113 **complexity** ๏พ measure of how difficult software is to understand, and thus
+to analyse, test, and maintain
+
+
+[IEEE Std 610.12-1990]
+
+
+114 Reducing complexity is the ultimate goal for using modular decomposition,
+layering and minimisation. Controlling coupling and cohesion contributes
+significantly to this goal.
+
+
+115 A good deal of effort in the software engineering field has been expended in
+attempting to develop metrics to measure the complexity of source code.
+Most of these metrics use easily computed properties of the source code,
+such as the number of operators and operands, the complexity of the control
+flow graph (cyclomatic complexity), the number of lines of source code, the
+ratio of comments to executable code, and similar measures. Coding
+
+
+Page 22 of 106 Version 3.1 April 2017
+
+
+**Terms and definitions**
+
+
+standards have been found to be a useful tool in generating code that is more
+readily understood.
+
+
+116 The TSF internals (ADV_INT) family calls for a complexity analysis in all
+components. It is expected that the developer will provide support for the
+claims that there has been a sufficient reduction in complexity. This support
+could include the developer's programming standards, and an indication that
+all modules meet the standard (or that there are some exceptions that are
+justified by software engineering arguments). It could include the results of
+tools used to measure some of the properties of the source code, or it could
+include other support that the developer finds appropriate.
+
+
+117 **coupling** ๏พ manner and degree of interdependence between software
+modules
+
+
+[IEEE Std 610.12-1990]
+
+
+Types of coupling include call, common and content coupling. These are
+characterised below:
+
+
+118 **call coupling** ๏พ relationship between two modules
+
+
+Examples of call coupling are data, stamp, and control:
+
+
+119 **call coupling (data)** ๏พ relationship between two modules communicating
+strictly through the use of call parameters that represent single data items.
+
+
+See โcall couplingโ
+
+
+120 **call coupling (stamp)** ๏พ relationship between two modules through the use
+of call parameters that comprise multiple fields or that have meaningful
+internal structures.
+
+
+See โcall couplingโ
+
+
+121 **call coupling (control)** ๏พ relationship between two modules if one passes
+information that is intended to influence the internal logic of the other.
+
+
+See โcall couplingโ
+
+
+122 **common coupling** ๏พ relationship between two modules sharing a common
+data area or other common system resource
+
+
+123 Global variables indicate that modules using those global variables are
+common coupled. Common coupling through global variables is generally
+allowed, but only to a limited degree.
+
+
+124 For example, variables that are placed into a global area, but are used by only
+a single module, are inappropriately placed, and should be removed. Other
+factors that need to be considered in assessing the suitability of global
+variables are:
+
+
+April 2017 Version 3.1 Page 23 of 106
+
+
+**Terms and definitions**
+
+
+a) The number of modules that modify a global variable: In general,
+only a single module should be allocated the responsibility for
+controlling the contents of a global variable, but there may be
+situations in which a second module may share that responsibility; in
+such a case, sufficient justification must be provided. It is
+unacceptable for this responsibility to be shared by more than two
+modules. (In making this assessment, care should be given to
+determining the module actually responsible for the contents of the
+variable; for example, if a single routine is used to modify the
+variable, but that routine simply performs the modification requested
+by its caller, it is the calling module that is responsible, and there may
+be more than one such module). Further, as part of the complexity
+determination, if two modules are responsible for the contents of a
+global variable, there should be clear indications of how the
+modifications are coordinated between them.
+
+
+b) The number of modules that reference a global variable: Although
+there is generally no limit on the number of modules that reference a
+global variable, cases in which many modules make such a reference
+should be examined for validity and necessity.
+
+
+125 **content coupling** ๏พ relationship between two modules where one makes
+direct reference to the internals of the other
+
+
+Examples include modifying code of, or referencing labels internal to, the
+other module. The result is that some or all of the content of one module are
+effectively included in the other. Content coupling can be thought of as using
+unadvertised module interfaces; this is in contrast to call coupling, which
+uses only advertised module interfaces.
+
+
+126 **domain separation** ๏พ security architecture property whereby the TSF
+defines separate security domains for each user and for the TSF and ensures
+that no user process can affect the contents of a security domain of another
+user or of the TSF
+
+
+127 **functional cohesion** ๏พ functional property of a module which performs
+activities related to a single purpose
+
+
+[IEEE Std 610.12-1990]
+
+
+A functionally cohesive module transforms a single type of input into a
+single type of output, such as a stack manager or a queue manager. See also
+โcohesionโ.
+
+
+128 **interaction** ๏พ general communication-based activity between entities
+
+
+129 **interface** ๏พ means of communication with an entity
+
+
+130 **layering** ๏พ design technique where separate groups of modules (the layers)
+are hierarchically organised to have separate responsibilities such that one
+
+
+Page 24 of 106 Version 3.1 April 2017
+
+
+**Terms and definitions**
+
+
+layer depends only on layers below it in the hierarchy for services, and
+provides its services only to the layers above it
+
+
+Strict layering adds the constraint that each layer receives services only from
+the layer immediately beneath it, and provides services only to the layer
+immediately above it.
+
+
+131 **logical cohesion** ๏พ procedural cohesion characteristics of a module
+performing similar activities on different data structures
+
+
+A module exhibits logical cohesion if its functions perform related, but
+different, operations on different inputs. See also โcohesionโ.
+
+
+132 **modular decomposition** ๏พ process of breaking a system into components
+to facilitate design, development and evaluation
+
+
+[IEEE Std 610.12-1990]
+
+
+133 **non-bypassability (of the TSF)** ๏พ security architecture property whereby
+all SFR-related actions are mediated by the TSF
+
+
+134 **procedural cohesion** ๏พ See โlogical cohesionโ
+
+
+135 **security domains** ๏พ environments provided by the TSF for the use by
+untrusted entities in such a way that these environments are isolated and
+protected from each other
+
+
+136 **sequential cohesion** ๏พ module containing functions each of whose output is
+input for the following function in the module
+
+
+[IEEE Std 610.12-1990]
+
+
+An example of a sequentially cohesive module is one that contains the
+functions to write audit records and to maintain a running count of the
+accumulated number of audit violations of a specified type.
+
+
+137 **software engineering** ๏พ application of a systematic, disciplined,
+quantifiable approach to the development and maintenance of software; that
+is, the application of engineering to software
+
+
+[IEEE Std 610.12-1990]
+
+
+As with engineering practices in general, some amount of judgement must be
+used in applying engineering principles. Many factors affect choices, not just
+the application of measures of modular decomposition, layering, and
+minimisation. For example, a developer may design a system with future
+applications in mind that will not be implemented initially. The developer
+may choose to include some logic to handle these future applications without
+fully implementing them; further, the developer may include some calls to
+as-yet unimplemented modules, leaving call stubs. The developer's
+justification for such deviations from well-structured programs will have to
+
+
+April 2017 Version 3.1 Page 25 of 106
+
+
+**Terms and definitions**
+
+
+be assessed using judgement, as well as the application of good software
+engineering discipline.
+
+
+138 **temporal cohesion** ๏พ characteristics of a module containing functions that
+need to be executed at about the same time
+
+
+Adapted from [IEEE Std 610.12-1990]. Examples of temporally cohesive
+modules include initialisation, recovery, and shutdown modules.
+
+
+139 **TSF self-protection** ๏พ security architecture property whereby the TSF
+cannot be corrupted by non-TSF code or entities
+
+## **4.3 Terms and definitions related to the AGD class**
+
+
+140 **installation** ๏พ procedure performed by a human user embedding the TOE in
+its operational environment and putting it into an operational state
+
+
+This operation is performed normally only once, after receipt and acceptance
+of the TOE. The TOE is expected to be progressed to a configuration
+allowed by the ST. If similar processes have to be performed by the
+developer they are denoted as โgenerationโ throughout ALC: Life-cycle
+support. If the TOE requires an initial start-up that does not need to be
+repeated regularly, this process would be classified as installation.
+
+
+141 **operation** ๏พ usage phase of the TOE including โnormal usageโ,
+administration and maintenance of the TOE after delivery and preparation
+
+
+142 **preparation** ๏พ activity in the life-cycle phase of a product, comprising the
+customer's acceptance of the delivered TOE and its installation which may
+include such things as booting, initialisation, start-up and progressing the
+TOE to a state ready for operation
+
+## **4.4 Terms and definitions related to the ALC class**
+
+
+143 **acceptance criteria** ๏พ criteria to be applied when performing the
+acceptance procedures (e.g. successful document review, or successful
+testing in the case of software, firmware or hardware)
+
+
+144 **acceptance procedures** ๏พ procedures followed in order to accept newly
+created or modified configuration items as part of the TOE, or to move them
+to the next step of the life-cycle
+
+
+145 These procedures identify the roles or individuals responsible for the
+acceptance and the criteria to be applied in order to decide on the acceptance.
+
+
+146 There are several types of acceptance situations some of which may overlap:
+
+
+a) acceptance of an item into the configuration management system for
+the first time, in particular inclusion of software, firmware and
+hardware components from other manufacturers into the TOE
+(โintegrationโ);
+
+
+Page 26 of 106 Version 3.1 April 2017
+
+
+**Terms and definitions**
+
+
+b) progression of configuration items to the next life-cycle phase at each
+stage of the construction of the TOE (e.g. module, subsystem, quality
+control of the finished TOE);
+
+
+c) subsequent to transports of configuration items (for example parts of
+the TOE or preliminary products) between different development
+sites;
+
+
+d) subsequent to the delivery of the TOE to the consumer.
+
+
+147 **configuration** **management** ๏พ discipline applying technical and
+administrative direction and surveillance to: identify and document the
+functional and physical characteristics of a configuration item, control
+changes to those characteristics, record and report change processing and
+implementation status, and verify compliance with specified requirements.
+
+
+[IEEE Std 610.12-1990]
+
+
+148 **CM documentation** ๏พ all CM documentation including CM output, CM list
+(configuration list), CM system records, CM plan and CM usage
+documentation
+
+
+149 **configuration management evidence** ๏พ everything that may be used to
+establish confidence in the correct operation of the CM system
+
+
+For example, CM output, rationales provided by the developer, observations,
+experiments or interviews made by the evaluator during a site visit.
+
+
+150 **configuration item** ๏พ object managed by the CM system during the TOE
+development
+
+
+These may be either parts of the TOE or objects related to the development
+of the TOE like evaluation documents or development tools. CM items may
+be stored in the CM system directly (for example files) or by reference (for
+example hardware parts) together with their version.
+
+
+151 **configuration list** ๏พ configuration management output document listing all
+configuration items for a specific product together with the exact version of
+each configuration management item relevant for a specific version of the
+complete product
+
+
+This list allows distinguishing the items belonging to the evaluated version
+of the product from other versions of these items belonging to other versions
+of the product. The final configuration management list is a specific
+document for a specific version of a specific product. (Of course the list can
+be an electronic document inside of a configuration management tool. In that
+case it can be seen as a specific view into the system or a part of the system
+rather than an output of the system. However, for the practical use in an
+evaluation the configuration list will probably be delivered as a part of the
+evaluation documentation.) The configuration list defines the items that are
+under the configuration management requirements of ALC_CMC.
+
+
+April 2017 Version 3.1 Page 27 of 106
+
+
+**Terms and definitions**
+
+
+152 **configuration management output** ๏พ results, related to configuration
+management, produced or enforced by the configuration management system
+
+
+These configuration management related results could occur as documents
+(for example filled paper forms, configuration management system records,
+logging data, hard-copies and electronic output data) as well as actions (for
+example manual measures to fulfil configuration management instructions).
+Examples of such configuration management outputs are configuration lists,
+configuration management plans and/or behaviours during the product lifecycle.
+
+
+153 **configuration management plan** ๏พ description of how the configuration
+management system is used for the TOE
+
+
+The objective of issuing a configuration management plan is that staff
+members can see clearly what they have to do. From the point of view of the
+overall configuration management system this can be seen as an output
+document (because it may be produced as part of the application of the
+configuration management system). From the point of view of the concrete
+project it is a usage document because members of the project team use it in
+order to understand the steps that they have to perform during the project.
+The configuration management plan defines the usage of the system for the
+specific product; the same system may be used to a different extent for other
+products. That means the configuration management plan defines and
+describes the output of the configuration management system of a company
+which is used during the TOE development.
+
+
+154 **configuration management system** ๏พ set of procedures and tools
+(including their documentation) used by a developer to develop and maintain
+configurations of his products during their life-cycles
+
+
+Configuration management systems may have varying degrees of rigour and
+function. At higher levels, configuration management systems may be
+automated, with flaw remediation, change controls, and other tracking
+mechanisms.
+
+
+155 **configuration management system records** ๏พ output produced during the
+operation of the configuration management system documenting important
+configuration management activities
+
+
+Examples of configuration management system records are configuration
+management item change control forms or configuration management item
+access approval forms.
+
+
+156 **configuration management tools** ๏พ manually operated or automated tools
+realising or supporting a configuration management system
+
+
+For example tools for the version management of the parts of the TOE.
+
+
+157 **configuration management usage documentation** ๏พ part of the
+configuration management system, which describes, how the configuration
+
+
+Page 28 of 106 Version 3.1 April 2017
+
+
+**Terms and definitions**
+
+
+management system is defined and applied by using for example handbooks,
+regulations and/or documentation of tools and procedures
+
+
+158 **delivery** ๏พ transmission of the finished TOE from the production
+environment into the hands of the customer
+
+
+This product life-cycle phase may include packaging and storage at the
+development site, but does not include transportations of the unfinished TOE
+or parts of the TOE between different developers or different development
+sites.
+
+
+159 **developer** ๏พ organisation responsible for the development of the TOE
+
+
+160 **development** ๏พ product life-cycle phase which is concerned with generating
+the implementation representation of the TOE
+
+
+Throughout the ALC: Life-cycle support requirements, development and
+related terms (developer, develop) are meant in the more general sense to
+comprise development and production.
+
+
+161 **development tools** ๏พ tools (including test software, if applicable)
+supporting the development and production of the TOE
+
+
+For example for a software TOE, development tools are usually
+programming languages, compilers, linkers and generating tools.
+
+
+162 **implementation representation** ๏พ least abstract representation of the TSF,
+specifically the one that is used to create the TSF itself without further design
+refinement
+
+
+Source code that is then compiled or a hardware drawing that is used to build
+the actual hardware are examples of parts of an implementation
+representation.
+
+
+163 **life-cycle** ๏พ sequence of stages of existence of an object (for example a
+product or a system) in time
+
+
+164 **life-cycle definition** ๏พ definition of the life-cycle model
+
+
+165 **life cycle model** ๏พ description of the stages and their relations to each other
+that are used in the management of the life-cycle of a certain object, how the
+sequence of stages looks like and which high level characteristics the stages
+have
+
+
+166 **production** ๏พ production life-cycle phase follows the development phase
+and consists of transforming the implementation representation into the
+implementation of the TOE, i.e. into a state acceptable for delivery to the
+customer
+
+
+This phase may comprise manufacturing, integration, generation, internal
+transports, storage, and labelling of the TOE.
+
+
+April 2017 Version 3.1 Page 29 of 106
+
+
+**Terms and definitions**
+
+
+**Figure 1 - Terminology in CM and in the product life-cycle**
+
+## **4.5 Terms and definitions related to the AVA class**
+
+
+167 **covert channel** ๏พ enforced, illicit signalling channel that allows a user to
+surreptitiously contravene the multi-level separation policy and
+unobservability requirements of the TOE
+
+
+168 **encountered potential vulnerabilities** ๏พ potential weakness in the TOE
+identified by the evaluator while performing evaluation activities that could
+be used to violate the SFRs
+
+
+169 **exploitable vulnerability** ๏พ weakness in the TOE that can be used to
+violate the SFRs in the operational environment for the TOE
+
+
+170 **monitoring attacks** ๏พ generic category of attack methods that includes
+passive analysis techniques aiming at disclosure of sensitive internal data of
+the TOE by operating the TOE in the way that corresponds to the guidance
+documents
+
+
+171 **potential vulnerability** ๏พ suspected, but not confirmed, weakness
+
+
+Suspicion is by virtue of a postulated attack path to violate the SFRs.
+
+
+172 **residual vulnerability** ๏พ weakness that cannot be exploited in the
+operational environment for the TOE, but that could be used to violate the
+SFRs by an attacker with greater attack potential than is anticipated in the
+operational environment for the TOE
+
+
+173 **vulnerability** ๏พ weakness in the TOE that can be used to violate the SFRs
+in some environment
+
+## **4.6 Terms and definitions related to the ACO class**
+
+
+174 **base component** ๏พ entity in a composed TOE, which has itself been the
+subject of an evaluation, providing services and resources to a dependent
+component
+
+
+Page 30 of 106 Version 3.1 April 2017
+
+
+**Terms and definitions**
+
+
+175 **compatible (components)** ๏พ property of a component able to provide the
+services required by the other component, through the corresponding
+interfaces of each component, in consistent operational environments
+
+
+176 **component TOE** ๏พ successfully evaluated TOE that is part of another
+composed TOE
+
+
+177 **composed TOE** ๏พ TOE comprised solely of two or more components that
+have been successfully evaluated
+
+
+178 **dependent component** ๏พ entity in a composed TOE, which is itself the
+subject of an evaluation, relying on the provision on services by a base
+component
+
+
+179 **functional interface** ๏พ external interface providing a user with access to
+functionality of the TOE which is not directly involved in enforcing security
+functional requirements
+
+
+In a composed TOE these are the interfaces provided by the base component
+that are required by the dependent component to support the operation of the
+composed TOE.
+
+
+April 2017 Version 3.1 Page 31 of 106
+
+
+**Symbols and abbreviated terms**
+
+# **5 Symbols and abbreviated terms**
+
+
+180 The following abbreviations are used in one or more parts of the CC:
+
+
+**API** Application Programming Interface
+
+**CAP** Composed Assurance Package
+
+**CC** Common Criteria
+
+**CCRA** Arrangement on the Recognition of Common Criteria
+Certificates in the field of IT Security
+
+**CM** Configuration Management
+
+**DAC** Discretionary Access Control
+
+**EAL** Evaluation Assurance Level
+
+**GHz** Gigahertz
+
+**GUI** Graphical User Interface
+
+**IC** Integrated Circuit
+
+**IOCTL** Input Output Control
+
+**IP** Internet Protocol
+
+**IT** Information Technology
+
+**MB** Mega Byte
+
+**OS** Operating System
+
+**OSP** Organisational Security Policy
+
+**PC** Personal Computer
+
+**PCI** Peripheral Component Interconnect
+
+**PKI** Public Key Infrastructure
+
+**PP** Protection Profile
+
+**RAM** Random Access Memory
+
+**RPC** Remote Procedure Call
+
+**SAR** Security Assurance Requirement
+
+**SFR** Security Functional Requirement
+
+**SFP** Security Function Policy
+
+**SPD** Security Problem Definition
+
+**ST** Security Target
+
+**TCP** Transmission Control Protocol
+
+**TOE** Target of Evaluation
+
+**TSF** TOE Security Functionality
+
+**TSFI** TSF Interface
+
+
+Page 32 of 106 Version 3.1 April 2017
+
+
+**Symbols and abbreviated terms**
+
+
+**VPN** Virtual Private Network
+
+
+April 2017 Version 3.1 Page 33 of 106
+
+
+**Overview**
+
+# **6 Overview**
+
+
+181 This Chapter introduces the main concepts of the CC. It identifies the
+concept โTOEโ, the target audience of the CC, and the approach taken to
+present the material in the remainder of the CC.
+
+## **6.1 The TOE**
+
+
+182 The CC is flexible in what to evaluate and is therefore not tied to the
+boundaries of IT products as commonly understood. Therefore in the context
+of evaluation, the CC uses the term โTOEโ (Target of Evaluation).
+
+
+183 A TOE is defined as a set of software, firmware and/or hardware possibly
+accompanied by guidance.
+
+
+184 While there are cases where a TOE consists of an IT product, this need not
+be the case. The TOE may be an IT product, a part of an IT product, a set of
+IT products, a unique technology that may never be made into a product, or a
+combination of these.
+
+
+185 As far as the CC is concerned, the precise relation between the TOE and any
+IT products is only important in one aspect: the evaluation of a TOE
+containing only part of an IT product should not be misrepresented as the
+evaluation of the entire IT product.
+
+
+186 Examples of TOEs include:
+
+
+๏ญ A software application;
+
+
+๏ญ An operating system;
+
+
+๏ญ A software application in combination with an operating system;
+
+
+๏ญ A software application in combination with an operating system and
+a workstation;
+
+
+๏ญ An operating system in combination with a workstation;
+
+
+๏ญ A smart card integrated circuit;
+
+
+๏ญ The cryptographic co-processor of a smart card integrated circuit;
+
+
+๏ญ A Local Area Network including all terminals, servers, network
+equipment and software;
+
+
+๏ญ A database application excluding the remote client software normally
+associated with that database application.
+
+
+Page 34 of 106 Version 3.1 April 2017
+
+
+**Overview**
+
+
+**6.1.1** **Different representations of the TOE**
+
+
+187 In the CC, a TOE can occur in several representations, such as (for a
+software TOE):
+
+
+๏ญ a list of files in a configuration management system;
+
+
+๏ญ a single master copy, that has just been compiled;
+
+
+๏ญ a box containing a CD-ROM and a manual, ready to be shipped to a
+customer;
+
+
+๏ญ an installed and operational version.
+
+
+188 All of these are considered to be a TOE: and wherever the term โTOEโ is
+used in the remainder of the CC, the context determines the representation
+that is meant.
+
+
+**6.1.2** **Different configurations of the TOE**
+
+
+189 In general, IT products can be configured in many ways: installed in different
+ways, with different options enabled or disabled. As, during a CC evaluation,
+it will be determined whether a TOE meets certain requirements, this
+flexibility in configuration may lead to problems, as all possible
+configurations of the TOE must meet the requirements. For these reasons, it
+is often the case that the guidance part of the TOE strongly constrains the
+possible configurations of the TOE. That is: the guidance of the TOE may be
+different from the general guidance of the IT product.
+
+
+190 An example is an operating system IT product. This product can be
+configured in many ways (e.g. types of users, number of users, types of
+external connections allowed/disallowed, options enabled/disabled etc.).
+
+
+191 If the same IT product is to be a TOE, and is evaluated against a reasonable
+set of requirements, the configuration should be much more tightly
+controlled, as many options (e.g. allow all types of external connections or
+the system administrator does not need to be authenticated) will lead to a
+TOE not meeting the requirements.
+
+
+192 For this reason, there would normally be a difference between the guidance
+of the IT product (allowing many configurations) and the guidance of the
+TOE (allowing only one or only configurations that do not differ in securityrelevant ways).
+
+
+193 Note that if the guidance of the TOE still allows more than one configuration,
+these configurations are collectively called โthe TOEโ and each such
+configuration must meet the requirements levied on the TOE.
+
+
+April 2017 Version 3.1 Page 35 of 106
+
+
+**Overview**
+
+## **6.2 Target audience of the CC**
+
+
+194 There are three groups with a general interest in evaluation of the security
+properties of TOEs: consumers, developers and evaluators. The criteria
+presented in this CC part 1 have been structured to support the needs of all
+three groups. They are all considered to be the principal users of the CC. The
+three groups can benefit from the criteria as explained in the following
+paragraphs.
+
+
+**6.2.1** **Consumers**
+
+
+195 The CC is written to ensure that evaluation fulfils the needs of the consumers
+as this is the fundamental purpose and justification for the evaluation process.
+
+
+196 Consumers can use the results of evaluations to help decide whether a TOE
+fulfils their security needs. These security needs are typically identified as a
+result of both risk analysis and policy direction. Consumers can also use the
+evaluation results to compare different TOEs.
+
+
+197 The CC gives consumers, especially in consumer groups and communities of
+interest, an implementation-independent structure, termed the Protection
+Profile (PP), in which to express their security requirements in an
+unambiguous manner.
+
+
+**6.2.2** **Developers**
+
+
+198 The CC is intended to support developers in preparing for and assisting in
+the evaluation of their TOEs and in identifying security requirements to be
+satisfied by those TOEs. These requirements are contained in an
+implementation-dependent construct termed the Security Target (ST). This
+ST may be based on one or more PPs to show that the ST conforms to the
+security requirements from consumers as laid down in those PPs.
+
+
+199 The CC can then be used to determine the responsibilities and actions to
+provide evidence that is necessary to support the evaluation of the TOE
+against these requirements. It also defines the content and presentation of
+that evidence.
+
+
+**6.2.3** **Evaluators**
+
+
+200 The CC contains criteria to be used by evaluators when forming judgements
+about the conformance of TOEs to their security requirements. The CC
+describes the set of general actions the evaluator is to carry out. Note that the
+CC does not specify procedures to be followed in carrying out those actions.
+More information on these procedures may be found in Section 6.4.
+
+
+**6.2.4** **Others**
+
+
+201 While the CC is oriented towards specification and evaluation of the IT
+security properties of TOEs, it may also be useful as reference material to all
+parties with an interest in or responsibility for IT security. Some of the
+
+
+Page 36 of 106 Version 3.1 April 2017
+
+
+**Overview**
+
+
+additional interest groups that can benefit from information contained in the
+CC are:
+
+
+a) system custodians and system security officers responsible for
+determining and meeting organisational IT security policies and
+requirements;
+
+
+b) auditors, both internal and external, responsible for assessing the
+adequacy of the security of an IT solution (which may consist of or
+contain a TOE);
+
+
+c) security architects and designers responsible for the specification of
+security properties of IT products;
+
+
+d) accreditors responsible for accepting an IT solution for use within a
+particular environment;
+
+
+e) sponsors of evaluation responsible for requesting and supporting an
+evaluation; and
+
+
+f) evaluation authorities responsible for the management and oversight
+of IT security evaluation programmes.
+
+## **6.3 The different parts of the CC**
+
+
+202 The CC is presented as a set of distinct but related parts as identified below.
+Terms used in the description of the parts are explained in Chapter 7.
+
+
+a) **Part 1, Introduction and general model** is the introduction to the
+CC. It defines the general concepts and principles of IT security
+evaluation and presents a general model of evaluation.
+
+
+b) **Part 2, Security functional components** establishes a set of
+functional components that serve as standard templates upon which to
+base functional requirements for TOEs. CC Part 2 catalogues the set
+of functional components and organises them in families and classes.
+
+
+c) **Part 3, Security assurance components** establishes a set of
+assurance components that serve as standard templates upon which to
+base assurance requirements for TOEs. CC Part 3 catalogues the set
+of assurance components and organises them into families and classes.
+CC Part 3 also defines evaluation criteria for PPs and STs and
+presents seven pre-defined assurance packages which are called the
+Evaluation Assurance Levels (EALs).
+
+
+203 In support of the three parts of the CC listed above, other documents have
+been published, the CEM provides the methodology for IT security
+evaluation using the CC as a basis. It is anticipated that other documents will
+be published, including technical rationale material and guidance documents.
+
+
+204 The following table presents, for the three key target audience groupings,
+how the parts of the CC will be of interest.
+
+
+April 2017 Version 3.1 Page 37 of 106
+
+
+**Overview**
+
+
+
+
+
+
+
+
+
+
+|Col1|Consumers|Developers|Evaluators|
+|---|---|---|---|
+|Part
1|Use for background
information and are
obliged to use for
reference purposes.
Guidance structure
for PPs.|Use for background
information and reference
purposes. Are obliged to
use for the development
of security specifications
for TOEs.|Are obliged to use
for reference
purposes and for
guidance in the
structure for PPs and
STs.|
+|Part
2|Use for guidance and
reference when
formulating
statements of
requirements for a
TOE.|Are obliged to use for
reference when
interpreting statements of
functional requirements
and formulating
functional specifications
for TOEs.|Are obliged to use
for reference when
interpreting
statements of
functional
requirements.|
+|Part
3|Use for guidance
when determining
required levels of
assurance.|Use for reference when
interpreting statements of
assurance requirements
and determining
assurance approaches of
TOEs.|Use for reference
when interpreting
statements of
assurance
requirements.|
+
+
+
+**Table 1 - Road map to the Common Criteria**
+
+## **6.4 Evaluation context**
+
+
+205 In order to achieve greater comparability between evaluation results,
+evaluations should be performed within the framework of an authoritative
+evaluation scheme that sets the standards, monitors the quality of the
+evaluations and administers the regulations to which the evaluation facilities
+and evaluators must conform.
+
+
+206 The CC does not state requirements for the regulatory framework. However,
+consistency between the regulatory frameworks of different evaluation
+authorities will be necessary to achieve the goal of mutual recognition of the
+results of such evaluations.
+
+
+207 A second way of achieving greater comparability between evaluation results
+is using a common methodology to achieve these results. For the CC, this
+methodology is given in the CEM.
+
+
+208 Use of a common evaluation methodology contributes to the repeatability
+and objectivity of the results but is not by itself sufficient. Many of the
+evaluation criteria require the application of expert judgement and
+background knowledge for which consistency is more difficult to achieve. In
+order to enhance the consistency of the evaluation findings, the final
+evaluation results may be submitted to a certification process.
+
+
+209 The certification process is the independent inspection of the results of the
+evaluation leading to the production of the final certificate or approval,
+which is normally publicly available. The certification process is a means of
+gaining greater consistency in the application of IT security criteria.
+
+
+Page 38 of 106 Version 3.1 April 2017
+
+
+**Overview**
+
+
+210 The evaluation schemes and certification processes are the responsibility of
+the evaluation authorities that run such schemes and processes and are
+outside the scope of the CC.
+
+
+April 2017 Version 3.1 Page 39 of 106
+
+
+**General model**
+
+# **7 General model**
+
+
+211 This chapter presents the general concepts used throughout the CC, including
+the context in which the concepts are to be used and the CC approach for
+applying the concepts. CC Part 2 and CC Part 3, which are obliged to be
+consulted by users of the CC Part 1, expand on the use of these concepts and
+assume that the approach described is used. Further, for users of the CC who
+intend to perform evaluation activities the CEM is applicable. This chapter
+assumes some knowledge of IT security and does not propose to act as a
+tutorial in this area.
+
+
+212 The CC discusses security using a set of security concepts and terminology.
+An understanding of these concepts and the terminology is a prerequisite to
+the effective use of the CC. However, the concepts themselves are quite
+general and are not intended to restrict the class of IT security problems to
+which the CC is applicable.
+
+## **7.1 Assets and countermeasures**
+
+
+213 Security is concerned with the protection of assets. Assets are entities that
+someone places value upon. Examples of assets include:
+
+
+๏ญ contents of a file or a server;
+
+
+๏ญ the authenticity of votes cast in an election;
+
+
+๏ญ the availability of an electronic commerce process;
+
+
+๏ญ the ability to use an expensive printer;
+
+
+๏ญ access to a classified facility.
+
+
+but given that value is highly subjective, almost anything can be an asset.
+
+
+214 The environment(s) in which these assets are located is called the operational
+environment. Examples of (aspects of) operational environments are:
+
+
+a) the computer room of a bank;
+
+
+b) a computer network connected to the Internet;
+
+
+c) a LAN;
+
+
+d) a general office environment.
+
+
+215 Many assets are in the form of information that is stored, processed and
+transmitted by IT products to meet requirements laid down by owners of the
+information. Information owners may require that availability, dissemination
+and modification of any such information are strictly controlled and that the
+
+
+Page 40 of 106 Version 3.1 April 2017
+
+
+**General model**
+
+
+assets are protected from threats by countermeasures. Figure 2 illustrates
+these high level concepts and relationships.
+
+
+**Figure 2 - Security concepts and relationships**
+
+
+216 Safeguarding assets of interest is the responsibility of owners who place
+value on those assets. Actual or presumed threat agents may also place value
+on the assets and seek to abuse assets in a manner contrary to the interests of
+the owner. Examples of threat agents include hackers, malicious users, nonmalicious users (who sometimes make errors), computer processes and
+accidents.
+
+
+217 The owners of the assets will perceive such threats as potential for
+impairment of the assets such that the value of the assets to the owners would
+be reduced. Security-specific impairment commonly includes, but is not
+limited to: loss of asset confidentiality, loss of asset integrity and loss of
+asset availability.
+
+
+218 These threats therefore give rise to risks to the assets, based on the likelihood
+of a threat being realised and the impact on the assets when that threat is
+realised. Subsequently countermeasures are imposed to reduce the risks to
+assets. These countermeasures may consist of IT countermeasures (such as
+firewalls and smart cards) and non-IT countermeasures (such as guards and
+procedures). See also ISO/IEC 27001 and ISO/IEC 27002 for a more general
+discussion on security countermeasures (controls).
+
+
+219 Owners of assets may be (held) responsible for those assets and therefore
+should be able to defend the decision to accept the risks of exposing the
+assets to the threats.
+
+
+April 2017 Version 3.1 Page 41 of 106
+
+
+**General model**
+
+
+220 Two important elements in defending this decision are being able to
+demonstrate that:
+
+
+๏ญ the countermeasures are sufficient: if the countermeasures do what
+they claim to do, the threats to the assets are countered;
+
+
+๏ญ the countermeasures are correct: the countermeasures do what they
+claim to do.
+
+
+221 Many owners of assets lack the knowledge, expertise or resources necessary
+to judge sufficiency and correctness of the countermeasures, and they may
+not wish to rely solely on the assertions of the developers of the
+countermeasures. These consumers may therefore choose to increase their
+confidence in the sufficiency and correctness of some or all of their
+countermeasures by ordering an evaluation of these countermeasures.
+
+
+**Figure 3 - Evaluation concepts and relationships**
+
+
+**7.1.1** **Sufficiency of the countermeasures**
+
+
+222 In an evaluation, sufficiency of the countermeasures is analysed through a
+construct called the Security Target. In this Section a simplified view on this
+construct is provided: a more detailed and complete description may be
+found in Annex A.
+
+
+223 The Security Target begins with describing the assets and the threats to those
+assets. The Security Target then describes the countermeasures (in the form
+of Security Objectives) and demonstrates that these countermeasures are
+
+
+Page 42 of 106 Version 3.1 April 2017
+
+
+**General model**
+
+
+sufficient to counter these threats: if the countermeasures do what they claim
+to do, the threats are countered.
+
+
+224 The Security Target then divides these countermeasures in two groups:
+
+
+a) the security objectives for the TOE: these describe the
+countermeasure(s) for which correctness will be determined in the
+evaluation;
+
+
+b) the security objectives for the Operational Environment: these
+describe the countermeasures for which correctness will not be
+determined in the evaluation.
+
+
+225 The reasons for this division are:
+
+
+๏ญ The CC is only suitable for assessing the correctness of IT
+countermeasures. Therefore the non-IT countermeasures (e.g. human
+security guards, procedures) are always in the Operational
+Environment.
+
+
+๏ญ Assessing correctness of countermeasures costs time and money,
+possibly making it infeasible to assess the correctness of all IT
+countermeasures.
+
+
+๏ญ The correctness of some IT countermeasures may already have been
+assessed in another evaluation. It is therefore not cost-effective to
+assess this correctness again.
+
+
+226 For the TOE (the IT countermeasures whose correctness will be assessed
+during the evaluation), the Security Target requires a further detailing of the
+security objectives for the TOE in Security Functional Requirements (SFRs).
+These SFRs are formulated in a standardised language (described in CC Part
+2) to ensure exactness and facilitate comparability.
+
+
+227 In summary, the Security Target demonstrates that:
+
+
+๏ญ The SFRs meet the security objectives for the TOE;
+
+
+๏ญ The security objectives for the TOE and the security objectives for
+the operational environment counter the threats;
+
+
+๏ญ And therefore, the SFRs and the security objectives for the
+operational environment counter the threats.
+
+
+228 From this it follows that a correct TOE (meeting the SFRs) in combination
+with a correct operational environment (meeting the security objectives for
+the operational environment) will counter the threats. In the next two
+sections correctness of the TOE and correctness of the operational
+environment are discussed separately.
+
+
+April 2017 Version 3.1 Page 43 of 106
+
+
+**General model**
+
+
+**7.1.2** **Correctness of the TOE**
+
+
+229 A TOE may be incorrectly designed and implemented, and may therefore
+contain errors that lead to vulnerabilities. By exploiting these vulnerabilities,
+attackers may still damage and/or abuse the assets.
+
+
+230 These vulnerabilities may arise from accidental errors made during
+development, poor design, intentional addition of malicious code, poor
+testing etc.
+
+
+231 To determine correctness of the TOE, various activities can be performed
+such as:
+
+
+๏ญ testing the TOE;
+
+
+๏ญ examining various design representations of the TOE;
+
+
+๏ญ examining the physical security of the development environment of
+the TOE.
+
+
+232 The Security Target provides a structured description of these activities to
+determine correctness in the form of Security Assurance Requirements
+(SARs). These SARs are formulated in a standardised language (described in
+CC Part 3) to ensure exactness and facilitate comparability.
+
+
+233 If the SARs are met, there exists assurance in the correctness of the TOE and
+the TOE is therefore less likely to contain vulnerabilities that can be
+exploited by attackers. The amount of assurance that exists in the correctness
+of the TOE is determined by the SARs themselves: a few โweakโ SARs will
+lead to a little assurance, a lot of โstrongโ SARs will lead to a lot of
+assurance.
+
+
+**7.1.3** **Correctness of the Operational Environment**
+
+
+234 The operational environment may also be incorrectly designed and
+implemented, and may therefore contain errors that lead to vulnerabilities.
+By exploiting these vulnerabilities, attackers may still damage and/or abuse
+the assets.
+
+
+235 However, in the CC, no assurance is obtained regarding the correctness of
+the operational environment. Or, in other words, the operational environment
+is not evaluated (see the next Section).
+
+
+236 As far as the evaluation is concerned, the operational environment is
+assumed to be a 100% correct instantiation of the security objectives for the
+operational environment.
+
+
+237 This does not preclude a consumer of the TOE from using other methods to
+determine the correctness of his operational environment, such as:
+
+
+๏ญ If, for an OS TOE, the security objectives for the operational
+environment state โThe operational environment shall ensure that
+
+
+Page 44 of 106 Version 3.1 April 2017
+
+
+**General model**
+
+
+entities from an untrusted network (e.g. the Internet) can only access
+the TOE by ftpโ, the consumer could select an evaluated firewall, and
+configure it to only allow ftp access to the TOE;
+
+
+๏ญ If the security objectives for the operational environment state โThe
+operational environment shall ensure that all administrative personnel
+will not behave maliciouslyโ, the consumer could adapt his contracts
+with administrative personnel to include punitive sanctions for
+malicious behaviour, but this determination is not part of a CC
+evaluation.
+
+## **7.2 Evaluation**
+
+
+238 The CC recognises two types of evaluation: an ST/TOE evaluation, which is
+described below, and an evaluation of PPs, which is defined in CC Part 3. In
+many places, the CC uses the term evaluation (without qualifiers) to refer to
+an ST/TOE evaluation.
+
+
+239 In the CC an ST/TOE evaluation proceeds in two steps:
+
+
+a) An ST evaluation: where the sufficiency of the TOE and the
+operational environment are determined;
+
+
+b) A TOE evaluation: where the correctness of the TOE is determined.
+As said earlier, the TOE evaluation does not assess correctness of the
+operational environment.
+
+
+240 The ST evaluation is carried out by applying the Security Target evaluation
+criteria (which are defined in CC Part 3) to the Security Target. The precise
+method to apply the ASE criteria is determined by the evaluation
+methodology that is used.
+
+
+241 The TOE evaluation is more complex. The principal inputs to a TOE
+evaluation are: the evaluation evidence, which includes the TOE and ST, but
+will usually also include input from the development environment, such as
+design documents or developer test results.
+
+
+242 The TOE evaluation consists of applying the SARs (from the Security
+Target) to the evaluation evidence. The precise method to apply a specific
+SAR is determined by the evaluation methodology that is used.
+
+
+243 How the results of applying the SARs are documented, and what reports
+need to be generated and in what detail, is determined by both the evaluation
+methodology that is used and the evaluation scheme under which the
+evaluation is carried out.
+
+
+244 The result of the TOE evaluation process is either:
+
+
+๏ญ A statement that not all SARs have been met and that therefore there
+is not the specified level of assurance that the TOE meets the SFRs as
+stated in the ST;
+
+
+April 2017 Version 3.1 Page 45 of 106
+
+
+**General model**
+
+
+๏ญ A statement that all SARs have been met, and that therefore there is
+the specified level of assurance that the TOE meets the SFRs as
+stated in the ST.
+
+
+245 The TOE evaluation may be carried out after TOE development has finished,
+or in parallel with TOE development.
+
+
+246 The method of stating ST/TOE evaluation results is described in Chapter 10.
+These results also identify the PP(s) and package(s) to which the TOE claims
+conformance, and these constructs are described in the next Chapter.
+
+
+Page 46 of 106 Version 3.1 April 2017
+
+
+**Tailoring Security Requirements**
+
+# **8 Tailoring Security Requirements**
+
+## **8.1 Operations**
+
+
+247 The CC functional and assurance components may be used exactly as
+defined in CC Part 2 and CC Part 3, or they may be tailored through the use
+of permitted operations. When using operations, the PP/ST author should be
+careful that the dependency needs of other requirements that depend on this
+requirement are satisfied. The permitted operations are selected from the
+following set:
+
+
+๏ญ Iteration: allows a component to be used more than once with varying
+operations;
+
+
+๏ญ Assignment: allows the specification of parameters;
+
+
+๏ญ Selection: allows the specification of one or more items from a list;
+and
+
+
+๏ญ Refinement: allows the addition of details.
+
+
+248 The assignment and selection operations are permitted only where
+specifically indicated in a component. Iteration and refinement are permitted
+for all components. The operations are described in more detail below.
+
+
+249 The CC Part 2 Annexes provide the guidance on the valid completion of
+selections and assignments. This guidance provides normative instructions
+on how to complete operations, and those instructions shall be followed
+unless the PP/ST author justifies the deviation:
+
+
+a) โNoneโ is only available as a choice for the completion of a selection
+if explicitly provided.
+
+
+The lists provided for the completion of selections must be nonempty. If a โNoneโ option is chosen, no additional selection options
+may be chosen. If โNoneโ is not given as an option in a selection, it is
+permissible to combine the choices in a selection with โandโs and
+โorโs, unless the selection explicitly states โchoose one ofโ.
+
+
+Selection operations may be combined by iteration where needed. In
+this case, the applicability of the option chosen for each iteration
+should not overlap the subject of the other iterated selection, since
+they are intended to be exclusive.
+
+
+b) For the completion of assignments, the CC Part 2 Annexes shall be
+consulted in order to determine when โNoneโ would be a valid
+completion.
+
+
+April 2017 Version 3.1 Page 47 of 106
+
+
+**Tailoring Security Requirements**
+
+
+**8.1.1** **The iteration operation**
+
+
+250 The iteration operation may be performed on every component. The PP/ST
+author performs an iteration operation by including multiple requirements
+based on the same component. Each iteration of a component shall be
+different from all other iterations of that component, which is realised by
+completing assignments and selections in a different way, or by applying
+refinements to it in a different way.
+
+
+251 Different iterations should be uniquely identified to allow clear rationales
+and tracings to and from these requirements.
+
+
+252 It is important to note that sometimes an iteration operation can be used with
+components where could also be possible to perform an assignment
+operation with a range or list of values instead of iterate them. In that case
+the author can select the most appropriate alternative, considering if there is a
+necessity of providing a whole rationale for the range of values or if it is
+necessary to have a separate one for each of them. The author should also
+keep in mind if individual traces are required for those values.
+
+
+**8.1.2** **The assignment operation**
+
+
+253 An assignment operation occurs where a given component contains an
+element with a parameter that may be set by the PP/ST author. The
+parameter may be an unrestricted variable, or a rule that narrows the variable
+to a specific range of values.
+
+
+254 Whenever an element in a PP contains an assignment, a PP author shall do
+one of four things:
+
+
+a) leave the assignment uncompleted. The PP author could include
+FIA_AFL.1.2 โWhen the defined number of unsuccessful
+authentication attempts has been met or surpassed, the TSF shall
+
+**[assignment: list of actions]** .โ in the PP.
+
+
+b) complete the assignment. As an example, the PP author could include
+FIA_AFL.1.2 โWhen the defined number of unsuccessful
+authentication attempts has been met or surpassed, the TSF shall
+**prevent that external entity from binding to any subject in the**
+**future** .โ in the PP.
+
+
+c) narrow the assignment, to further limit the range of values that is
+allowed. As an example, the PP author could include FIA_AFL.1.1
+โThe TSF shall **detect when [assignment: positive integer between**
+**4 and 9] unsuccessful authentication attempts occur ...** โ in the PP.
+
+
+d) transform the assignment to a selection, thereby narrowing the
+assignment. As an example, the PP author could include
+FIA_AFL.1.2 โWhen the defined number of unsuccessful
+authentication attempts has been met or surpassed, the TSF shall
+
+
+Page 48 of 106 Version 3.1 April 2017
+
+
+**Tailoring Security Requirements**
+
+
+**[selection: prevent that user from binding to any subject in the**
+**future, notify the administrator]** .โ in the PP.
+
+
+255 Whenever an element in an ST contains an assignment, an ST author shall
+complete that assignment, as indicated in b) above. Options a), c) and d) are
+not allowed for STs.
+
+
+256 The values chosen in options b), c) and d) shall conform to the indicated type
+required by the assignment.
+
+
+257 When an assignment is to be completed with a set (e.g. subjects), one may
+list a set of subjects, but also some description of the set from which the
+elements of the set can be derived such as:
+
+
+๏ญ all subjects
+
+
+๏ญ all subjects of type X
+
+
+๏ญ all subjects except subject a
+
+
+๏ญ as long as it is clear which subjects are meant.
+
+
+**8.1.3** **The selection operation**
+
+
+258 The selection operation occurs where a given component contains an element
+where a choice from several items has to be made by the PP/ST author.
+
+
+259 Whenever an element in a PP contains a selection, the PP author may do one
+of three things:
+
+
+a) leave the selection uncompleted.
+
+
+b) complete the selection by choosing one or more items.
+
+
+c) restrict the selection by removing some of the choices, but leaving
+two or more.
+
+
+260 Whenever an element in an ST contains a selection, an ST author shall
+complete that selection, as indicated in b) above. Options a) and c) are not
+allowed for STs.
+
+
+261 The item or items chosen in b) and c) shall be taken from the items provided
+in the selection.
+
+
+**8.1.4** **The refinement operation**
+
+
+262 The refinement operation can be performed on every requirement. The
+PP/ST author performs a refinement by altering that requirement. The first
+rule for a refinement is that a TOE meeting the refined requirement also
+meets the unrefined requirement in the context of the PP/ST (i.e. a refined
+requirement must be โstricterโ than the original requirement). If a refinement
+
+
+April 2017 Version 3.1 Page 49 of 106
+
+
+**Tailoring Security Requirements**
+
+
+does not meet this rule, the resulting refined requirement is considered to be
+an extended requirement and shall be treated as such.
+
+
+263 The first rule for a refinement is that a TOE meeting the refined requirement
+also meets the unrefined requirement in the context of the PP/ST (i.e. a
+refined requirement must be โstricterโ than the original requirement)
+
+
+264 The only exception to this rule is that a PP/ST author is allowed to refine a
+SFR to apply to some but not all subjects, objects, operations, security
+attributes and/or external entities.
+
+
+265 However, this exception does not apply to refining SFRs that are taken from
+PPs that compliance is being claimed to; these SFRs may not be refined to
+apply to fewer subjects, objects, operations, security attributes and/or
+external entities than the SFR in the PP.
+
+
+266 The second rule for a refinement is that the refinement shall be related to the
+original component.
+
+
+267 A special case of refinement is an editorial refinement, where a small change
+is made in a requirement, i.e. rephrasing a sentence due to adherence to
+proper English grammar, or to make it more understandable to the reader.
+This change is not allowed to modify the meaning of the requirement in any
+way.
+
+## **8.2 Dependencies between components**
+
+
+268 Dependencies may exist between components. Dependencies arise when a
+component is not self sufficient and relies upon the presence of another
+component to provide security functionality or assurance.
+
+
+269 The functional components in CC Part 2 typically have dependencies on
+other functional components as do some of the assurance components in CC
+Part 3 which may have dependencies on other CC Part 3 components. CC
+Part 2 dependencies on CC Part 3 components may also be defined. However,
+this does not preclude extended functional components having dependencies
+on assurance components or vice versa.
+
+
+270 Component dependency descriptions are determined by consulting the CC
+Part 2 and CC Part 3 component definitions. In order to ensure completeness
+of the TOE security requirements, dependencies should be satisfied when
+requirements based on components with dependencies are incorporated into
+PPs and STs. Dependencies should also be considered when constructing
+packages.
+
+
+271 In other words: if component A has a dependency on component B, this
+means that whenever a PP/ST contains a security requirement based on
+component A, the PP/ST shall also contain one of :
+
+
+a) a security requirement based on component B, or
+
+
+Page 50 of 106 Version 3.1 April 2017
+
+
+**Tailoring Security Requirements**
+
+
+b) a security requirement based on a component that is hierarchically
+higher than B, or
+
+
+c) a justification why the PP/ST does not contain a security requirement
+based on component B.
+
+
+272 In cases a) and b), when a security requirement is included because of a
+dependency, it may be necessary to complete operations (assignment,
+iteration, refinement, selection) on that security requirement in a particular
+manner to make sure that it actually satisfies the dependency.
+
+
+273 In case c), the justification that a security requirement is not included should
+address either:
+
+
+๏ญ why the dependency is not necessary or useful, or
+
+
+๏ญ that the dependency has been addressed by the operational
+environment of the TOE, in which case the justification should
+describe how the security objectives for the operational environment
+address this dependency, or
+
+
+๏ญ that the dependency has been addressed by the other SFRs in some
+other manner (extended SFRs, combinations of SFRs etc.)
+
+## **8.3 Extended components**
+
+
+274 In the CC it is mandatory to base requirements on components from CC Part
+2 or CC Part 3 with two exceptions:
+
+
+a) there are security objectives for the TOE that can not be translated to
+Part 2 SFRs, or there are third party requirements (e.g., laws,
+standards) that can not be translated to Part 3 SARs (e.g. regarding
+evaluation of cryptography);
+
+
+b) a security objective can be translated, but only with great difficulty
+and/or complexity based on components in CC Part 2 and/or CC Part
+3.
+
+
+275 In both cases the PP/ST author is required to define his own components.
+These newly defined components are called extended components. A
+precisely defined extended component is needed to provide context and
+meaning to the extended SFRs and SARs based on that component.
+
+
+276 After the new components have been defined correctly, the PP/ST author can
+then base one or more SFRs or SARs on these newly defined extended
+components and use them in the same way as the other SFRs and SARs.
+From this point on, there is no further distinction between SARs and SFRs
+based on the CC and SARs and SFRs based on extended components. Refer
+to CC Part 3 Extended components definition (APE_ECD) and Extended
+components definition (ASE_ECD) for further requirements on extended
+components.
+
+
+April 2017 Version 3.1 Page 51 of 106
+
+
+**Protection Profiles and Packages**
+
+# **9 Protection Profiles and Packages**
+
+## **9.1 Introduction**
+
+
+277 To allow consumer groups and communities of interest to express their
+security needs, and to facilitate writing STs, this part of the CC provides two
+special constructs: packages and Protection Profiles (PPs). In the following
+two sections these constructs are described in more detail, followed by a
+section on how these constructs can be used.
+
+## **9.2 Packages**
+
+
+278 A package is a named set of security requirements. A package is either
+
+
+๏ญ a functional package, containing only SFRs, or
+
+
+๏ญ an assurance package, containing only SARs.
+
+
+279 Mixed packages containing both SFRs and SARs are not allowed.
+
+
+280 A package can be defined by any party and is intended to be re-usable. To
+this goal it should contain requirements that are useful and effective in
+combination. Packages can be used in the construction of larger packages,
+PPs and STs. At present there are no criteria for the evaluation of packages,
+therefore any set of SFRs or SARs can be a package.
+
+
+281 Examples of assurance packages are the evaluation assurance levels (EALs)
+that are defined in CC Part 3. At the time of writing there are no functional
+packages for this version of the CC.
+
+## **9.3 Protection Profiles**
+
+
+282 Whereas an ST always describes a specific TOE (e.g. the MinuteGap v18.5
+Firewall), a PP is intended to describe a TOE type (e.g. firewalls). The same
+PP may therefore be used as a template for many different STs to be used in
+different evaluations. A detailed description of PPs is given in Annex B.
+
+
+283 In general an ST describes requirements for a TOE and is written by the
+developer of that TOE, while a PP describes the general requirements for a
+TOE type, and is therefore typically written by:
+
+
+๏ญ A user community seeking to come to a consensus on the
+requirements for a given TOE type;
+
+
+๏ญ A developer of a TOE, or a group of developers of similar TOEs
+wishing to establish a minimum baseline for that type of TOE;
+
+
+๏ญ A government or large corporation specifying its requirements as part
+of its acquisition process.
+
+
+Page 52 of 106 Version 3.1 April 2017
+
+
+**Protection Profiles and Packages**
+
+
+284 The PP determines the allowed type of conformance of the ST to the PP.
+That is, the PP states (in the PP conformance statement, see section B.5)
+what the allowed types of conformance for the ST are:
+
+
+๏ญ if the PP states that strict conformance is required, the ST shall
+conform to the PP in a strict manner;
+
+
+๏ญ if the PP states that demonstrable conformance is required, the ST
+shall conform to the PP in a strict or demonstrable manner.
+
+
+285 Restating this in other words, an ST is only allowed to conform in a PP in a
+demonstrable manner, if the PP explicitly allows this.
+
+
+286 If an ST claims conformance to multiple PPs, it shall conform (as described
+above) to each PP in the manner ordained by that PP. This may mean that the
+ST conforms strictly to some PPs and demonstrably to other PPs.
+
+
+287 Note that either the ST conforms to the PP in question or it does not. The CC
+does not recognise โpartialโ conformance. It is therefore the responsibility of
+the PP author to ensure the PP is not overly onerous, prohibiting PP/ST
+authors in claiming conformance to the PP.
+
+
+288 An ST is equivalent or more restrictive than a PP if:
+
+
+๏ญ all TOEs that meet the ST also meet the PP, and
+
+
+๏ญ all operational environments that meet the PP also meet the ST.
+
+
+or, informally, the ST shall levy the same or more, restrictions on the TOE
+and the same or less restrictions on the operational environment of the TOE.
+
+
+289 This general statement can be made more specific for various sections of the
+ST:
+
+
+a) **Security problem definition** : The conformance rationale in the ST
+shall demonstrate that the security problem definition in the ST is
+equivalent (or more restrictive) than the security problem definition
+in the PP. This means that:
+
+
+๏ญ all TOEs that would meet the security problem definition in
+the ST also meet the security problem definition in the PP;
+
+
+๏ญ all operational environments that would meet the security
+problem definition in the PP would also meet the security
+problem definition in the ST.
+
+
+b) **Security objectives** : The conformance rationale in the ST shall
+demonstrate that the security objectives in the ST is equivalent (or
+more restrictive) than the security objectives in the PP. This means
+that:
+
+
+April 2017 Version 3.1 Page 53 of 106
+
+
+**Protection Profiles and Packages**
+
+
+๏ญ all TOEs that would meet the security objectives for the TOE
+in the ST also meet the security objectives for the TOE in the
+PP;
+
+
+๏ญ all operational environments that would meet the security
+objectives for the operational environment in the PP would
+also meet the security objectives for the operational
+environment in the ST.
+
+
+290 If strict conformance for protection profiles is specified then the following
+requirements apply:
+
+
+a) **Security problem definition** :
+
+
+๏ญ The ST shall contain the security problem definition of the PP
+and may specify additional threats and OSPs; it shall contain
+all assumptions as defined in the PP, with two possible
+exceptions as explained in the next two bullets;
+
+
+๏ญ an assumption (or a part of an assumption) specified in the PP
+may be omitted from the ST, if all security objectives for the
+operational environment defined in the PP addressing this
+assumption (or this part of an assumption) are replaced by
+security objectives for the TOE in the ST;
+
+
+๏ญ a new assumption may be added in the ST to the set of
+assumptions defined in the PP, if this new assumption does
+not mitigate a threat (or part of a threat) meant to be addressed
+by security objectives for the TOE in the PP and if this
+assumption doesn't fulfil an OSP (or a part of an OSP) meant
+to be addressed by security objectives for the TOE in the PP;
+
+
+b) **Security objectives** : The ST:
+
+
+๏ญ shall contain all security objectives for the TOE of the PP but
+may specify additional security objectives for the TOE;
+
+
+๏ญ shall contain all security objectives for the operational
+environment as defined in the PP with two exceptions as
+explained in the next two bullet points;
+
+
+๏ญ may specify that certain objectives for the operational
+environment in the PP are security objectives for the TOE in
+the ST. This is called re-assigning a security objective. If a
+security objective is re-assigned to the TOE the security
+objectives justification has to make clear which assumption or
+part of the assumption may not be necessary any more;
+
+
+๏ญ may specify additional objectives for the operational
+environment, if these new objectives do not mitigate a threat
+(or part of a threat) meant to be addressed by security
+
+
+Page 54 of 106 Version 3.1 April 2017
+
+
+**Protection Profiles and Packages**
+
+
+objectives of the TOE in the PP and if these new objectives do
+not fulfil an OSP (or a part of an OSP) meant to be addressed
+by security objectives of the TOE in the PP
+
+
+c) **Security requirements** : The ST shall contain all SFRs and SARs in
+the PP, but may claim additional or hierarchically stronger SFRs and
+SARs. The completion of operations in the ST must be consistent
+with that in the PP; either the same completion will be used in the ST
+as that in the PP or one that makes the requirement more restrictive
+(the rules of refinement apply).
+
+
+291 If demonstrable conformance for protection profiles is specified then the
+following requirements apply:
+
+
+๏ญ the ST shall contain a rationale on why the ST is considered to be
+โequivalent or more restrictiveโ than the PP.
+
+
+๏ญ Demonstrable conformance allows a PP author to describe a common
+security problem to be solved and provide generic guidelines to the
+requirements necessary for its resolution, in the knowledge that there
+is likely to be more than one way of specifying a resolution.
+
+
+292 PP evaluation is optional. Evaluation is performed by applying the APE
+criteria to them as listed in CC Part 3. The goal of such an evaluation is to
+demonstrate that the PP is complete, consistent, and technically sound and
+suitable for use as a template on which to build another PP or an ST.
+
+
+293 Basing a PP/ST on an evaluated PP has two advantages:
+
+
+๏ญ There is much less risk that there are errors, ambiguities or gaps in
+the PP. If any problems with a PP (that would have been caught by
+evaluating that PP) are found during the writing or evaluation of the
+new ST, significant time may elapse before the PP is corrected.
+
+
+๏ญ Evaluation of the new PP/ST may often re-use evaluation results of
+the evaluated PP, resulting in less effort for evaluating the new PP/ST.
+
+## **9.4 Using PPs and packages**
+
+
+294 If an ST claims to be conformant to one or more packages and/or Protection
+Profiles, the evaluation of that ST will (among other properties of that ST)
+demonstrate that the ST actually conforms to these packages and/or PPs that
+they claim conformance to. Details of this determination of conformance can
+be found in Annex A.
+
+
+295 This allows the following process:
+
+
+a) An organisation seeking to acquire a particular type of IT security
+product develops their security needs into a PP, then has this
+evaluated and publishes it;
+
+
+April 2017 Version 3.1 Page 55 of 106
+
+
+**Protection Profiles and Packages**
+
+
+b) A developer takes this PP, writes an ST that claims conformance to
+the PP and has this ST evaluated;
+
+
+c) The developer then builds a TOE (or uses an existing one) and has
+this evaluated against the ST.
+
+
+296 The result is that the developer can prove that his TOE is conformant to the
+security needs of the organisation: the organisation can therefore acquire that
+TOE. A similar line of reasoning applies to packages.
+
+## **9.5 Using Multiple Protection Profiles**
+
+
+297 The CC also allows PPs to conform to other PPs, allowing chains of PPs to
+be constructed, each based on the previous one(s).
+
+
+298 For instance, one could take a PP for an Integrated Circuit and a PP for a
+Smart Card OS, and use these to construct a Smart Card PP (IC and OS) that
+claims conformance to the other two. One could then write a PP on Smart
+Cards for Public Transport based on the Smart Card PP and a PP on Applet
+Loading. Finally, a developer could then construct an ST based on this Smart
+Cards for Public Transport PP.
+
+## **9.6 Protection Profiles, PP-Modules and PP-Configurations**
+
+
+**9.6.1** **Introduction**
+
+
+299 To allow the definition of modular Protection Profiles that address optional
+TOE's security features, this chapter introduces two constructs: PP-Modules
+and PP-Configurations, as well as the way they can be used to evaluate
+compliant products.
+
+
+**9.6.2** **PP-Modules**
+
+
+300 A PP-Module is a consistent set of elements (threats, assumptions,
+organisational policies, objectives and security requirements) with a unique
+reference.
+
+
+301 Unlike Protection Profiles, PP-Modules address optional security features of
+a given type of TOE that cannot be required uniformly for all products of this
+kind.
+
+
+302 Each PP-Module refers to at least one Base Protection Profile (or Base-PP)
+that provides the definition of the TOE type and the mandatory requirements
+to fulfill. The PP-Module specifies the modified TOE type, complements
+these requirements and has to be used with the Base-PPs: a PP-Module may
+introduce new elements to the Base-PPs and may also refine or interpret
+some of the elements of the Base-PPs.
+
+
+303 If the PP-Module refers to several Base Protection Profiles, this set of BasePPs have to be used simultaneously for the evaluation and usage of the PPModule.
+
+
+Page 56 of 106 Version 3.1 April 2017
+
+
+**Protection Profiles and Packages**
+
+
+304 The PP-Module can also refer to alternative sets of Base-PPs, in the case the
+PP-Module could comply with alternative Base-PPs depending of the usage.
+
+
+305 The evaluation of a PP-Module alone is meaningless. A PP-Module has to be
+evaluated as part of a PP-Configuration, at least with its mandatory Base-PPs.
+
+
+**9.6.3** **PP-Configurations**
+
+
+306 A PP-Configuration results from the combination of at least one PP-Module
+with its Base-PPs, without any additional content: a PP-Configuration is
+much like a Protection Profile that would include all the elements from the
+Base-PPs and the PP-Modules.
+
+
+307 A PP-Configuration can select more PPs than the Base-PPs of the PPModules, but at least all of the Base-PPs of the referred PP-Modules must be
+included in the PP-Configuration.
+
+
+308 If the PP-Module defines alternative sets of Base-PPs, only one of these sets
+must be used in the PP-Configuration.
+
+
+309 A PP-Configuration holds a unique reference and identifies all the PP
+components: selected Base-PPs and selected PP-Modules.
+
+
+310 A PP-Configuration can only combine certified Base-PPs to PP-Modules.
+
+
+311 Evaluation rules for PP-Configurations are similar to the ones for standard
+PPs. These rules are described in Class ACE, in CC Part 3.
+
+
+**9.6.4** **Using PP-Modules and PP-Configurations in security targets**
+
+
+312 PP-Modules are used to build specific PP-Configurations on top of one or
+more Base-PPs. PP-Modules are used in Security Targets only as part of
+well-identified PP-Configurations.
+
+
+313 PP-Configurations are used like Protection Profiles. A Security Target can
+claim conformity to a PP-Configuration provided this PP-Configuration has
+been evaluated. Henceforth, the evaluation of the ST can rely on the results
+of the PP-Configuration evaluation results as usual.
+
+
+314 Note that the evaluation of a PP-Configuration can arise in two situations,
+with no impact on the evaluation methodology:
+
+
+๏ญ Independently of any product evaluation, or
+
+
+๏ญ As the first step of the evaluation of a Security Target that claims
+conformity with the PP-Configuration. Otherwise the conformance
+claim is meaningless and the ST evaluation would fail in this aspect.
+
+
+315 In practice, a ST that claims conformance with a non-certified PPConfiguration can still be evaluated with a conformance claim against the
+Base-PP of the PP-Configuration; the elements of the ST that meet the PP
+
+April 2017 Version 3.1 Page 57 of 106
+
+
+**Protection Profiles and Packages**
+
+
+Modules of the PP-Configuration would be evaluated as standard additions
+to the Base-PP, proper to the TOE.
+
+
+Page 58 of 106 Version 3.1 April 2017
+
+
+**Evaluation results**
+
+# **10 Evaluation results**
+
+## **10.1 Introduction**
+
+
+316 This chapter presents the expected results from PP and ST/TOE evaluations
+performed according to the CEM.
+
+
+317 PP evaluations lead to catalogues of evaluated PPs.
+
+
+318 An ST evaluation leads to intermediate results that are used in the frame of a
+TOE evaluation.
+
+
+319 ST/TOE evaluations lead to catalogues of evaluated TOEs. In many cases
+these catalogues will refer to the IT products that the TOEs are derived from
+rather than the specific TOE. Therefore, the existence of an IT product in a
+catalogue should not be construed as meaning that the whole IT product has
+been evaluated; instead the actual extent of the ST/TOE evaluation is defined
+by the ST. Refer to the bibliography for examples of such catalogues.
+
+
+**Figure 4 - Evaluation results**
+
+
+320 STs may be based on packages, evaluated PPs or non-evaluated PPs however this is not mandatory, as STs do not have to be based on anything at
+all.
+
+
+321 Evaluation should lead to objective and repeatable results that can be cited as
+evidence, even if there is no absolute objective scale for representing the
+results of a security evaluation. The existence of a set of evaluation criteria is
+a necessary pre-condition for evaluation to lead to a meaningful result and
+provides a technical basis for mutual recognition of evaluation results
+between evaluation authorities.
+
+
+April 2017 Version 3.1 Page 59 of 106
+
+
+**Evaluation results**
+
+
+322 An evaluation result represents the findings of a specific type of investigation
+of the security properties of a TOE. Such a result does not automatically
+guarantee fitness for use in any particular application environment. The
+decision to accept a TOE for use in a specific application environment is
+based on consideration of many security issues including the evaluation
+findings.
+
+## **10.2 Results of a PP evaluation**
+
+
+323 CC Part 3 contains the evaluation criteria that an evaluator is obliged to
+consult in order to state whether a PP is complete, consistent, and technically
+sound and hence suitable for use in developing an ST.
+
+
+324 The results of the evaluation shall also include a โConformance Claimโ (see
+Section 10.5)).
+
+## **10.3 Results of a PP-Configuration evaluation**
+
+
+325 This chapter presents the expected results from PP-Configuration evaluation
+and ST/TOE evaluations according to the Class ACE (Protection Profile
+Configuration Evaluation) presented in CEM class ACE.
+
+
+326 The evaluated PP-Configurations integrate the catalogue of evaluated PPs,
+linked to the Base-PPs of the PP-Configurations.
+
+
+327 STs may be based on packages, evaluated PPs or non-evaluated PPs,
+evaluated PP-Configurations or non-evaluated PP-Configurations, or built-in
+independently.
+
+
+328 CC Part 3 ACE contains the evaluation criteria that an evaluator is obliged to
+follow in order to state whether a PP-Configuration is complete, consistent,
+and technically sound and hence suitable for use in developing an ST.
+
+
+329 The results of the evaluation shall also include a "Conformance Claim" (see
+Section 10.5).
+
+## **10.4 Results of an ST/TOE evaluation**
+
+
+330 CC Part 3 contains the evaluation criteria that an evaluator is obliged to
+consult in order to determine whether sufficient assurance exists that the
+TOE satisfies the SFRs in the ST. Evaluation of the TOE shall therefore
+result in a pass/fail statement for the ST. If both the ST and the TOE
+evaluation have resulted in a pass statement, the underlying product is
+eligible for inclusion in a registry. The results of evaluation shall also include
+a โConformance Claimโ as defined in the next section.
+
+
+331 It may be the case that the evaluation results are subsequently used in a
+certification process, but this certification process is outside the scope of the
+CC.
+
+
+Page 60 of 106 Version 3.1 April 2017
+
+
+**Evaluation results**
+
+## **10.5 Conformance claim**
+
+
+332 The conformance claim indicates the source of the collection of requirements
+that is met by a PP or ST that passes its evaluation. This conformance claim
+contains a CC conformance claim that:
+
+
+a) describes the version of the CC to which the PP or ST claims
+conformance.
+
+
+b) describes the conformance to CC Part 2 (security functional
+requirements) as either:
+
+
+๏ญ **CC Part 2 conformant** - A PP or ST is CC Part 2 conformant
+if all SFRs in that PP or ST are based only upon functional
+components in CC Part 2, or
+
+
+๏ญ **CC Part 2 extended** - A PP or ST is CC Part 2 extended if at
+least one SFR in that PP or ST is not based upon functional
+components in CC Part 2.
+
+
+c) describes the conformance to CC Part 3 (security assurance
+requirements) as either:
+
+
+๏ญ **CC Part 3 conformant** - A PP or ST is CC Part 3 conformant
+if all SARs in that PP or ST are based only upon assurance
+components in CC Part 3, or
+
+
+๏ญ **CC Part 3 extended** - A PP or ST is CC Part 3 extended if at
+least one SAR in that PP or ST is not based upon assurance
+components in CC Part 3.
+
+
+333 Additionally, the conformance claim may include a statement made with
+respect to packages, in which case it consists of one of the following:
+
+
+๏ญ _Package name Conformant_ - A PP or ST is conformant to a predefined package (e.g. EAL) if:
+
+
+๏ญ the SFRs of that PP or ST are identical to the SFRs in the
+package, or
+
+
+๏ญ the SARs of that PP or ST are identical to the SARs in the
+package.
+
+
+๏ญ _Package name Augmented_ - A PP or ST is an augmentation of a
+predefined package if:
+
+
+๏ญ the SFRs of that PP or ST contain all SFRs in the package, but
+have at least one additional SFR or one SFR that is
+hierarchically higher than an SFR in the package.
+
+
+April 2017 Version 3.1 Page 61 of 106
+
+
+**Evaluation results**
+
+
+๏ญ the SARs of that PP or ST contain all SARs in the package,
+but have at least one additional SAR or one SAR that is
+hierarchically higher than an SAR in the package.
+
+
+334 Note that when a TOE is successfully evaluated to a given ST, any
+conformance claims of the ST also hold for the TOE. A TOE can therefore
+also be e.g. CC Part 2 conformant.
+
+
+335 Finally, the conformance claim may also include two statements with respect
+to Protection Profiles:
+
+
+a) _PP Conformant_ - A PP or TOE meets specific PP(s), which are listed
+as part of the conformance result.
+
+
+b) _Conformance Statement_ (Only for PPs) - This statement describes the
+manner in which PPs or STs must conform to this PP: strict or
+demonstrable. For more information on this Conformance Statement,
+see Annex B.
+
+
+336 Besides the standard CC conformance claim regarding the version of the CC,
+the CC Part 2 and Part 3, the SFR and SAR packages, and the standard PP
+claim,
+
+
+๏ญ a PP-Configuration has to provide a conformance statement
+applicable to the conformant STs, either _strict_ or _demonstrable_, that
+meet the conformance statements of the Base-PP(s),
+
+
+๏ญ a ST may claim conformity with one or more PP-Configurations.
+
+## **10.6 Use of ST/TOE evaluation results**
+
+
+337 Once an ST and a TOE have been evaluated, asset owners can have the
+assurance (as defined in the ST) that the TOE, together with the operational
+environment, counters the threats. The evaluation results may be used by the
+asset owner in deciding whether to accept the risk of exposing the assets to
+the threats.
+
+
+338 However, the asset owner should carefully check whether:
+
+
+a) the Security Problem Definition in the ST matches the security
+problem of the asset owner;
+
+
+b) the Operational Environment of the asset owner conforms (or can be
+made to conform) to the security objectives for the Operational
+Environment described in the ST.
+
+
+339 If either of these is not the case, the TOE may not be suitable for the
+purposes of the asset owner.
+
+
+340 Additionally, once an evaluated TOE is in operation, it is still possible that
+previously unknown errors or vulnerabilities in the TOE may surface. In that
+case, the developer may correct the TOE (to repair the vulnerabilities) or
+
+
+Page 62 of 106 Version 3.1 April 2017
+
+
+**Evaluation results**
+
+
+change the ST to exclude the vulnerabilities from the scope of the evaluation.
+In either case, the old evaluation results may no longer be valid.
+
+
+341 If it is deemed necessary that confidence is regained, re-evaluation is needed.
+The CC may be used for this re-evaluation, but detailed procedures for reevaluation are outside the scope of this part of the CC.
+
+
+April 2017 Version 3.1 Page 63 of 106
+
+
+**Specification of Security Targets**
+
+# **A Specification of Security Targets** **(informative)**
+
+## **A.1 Goal and structure of this Annex**
+
+
+342 The goal of this annex is to explain the Security Target (ST) concept. This
+annex does not define the ASE criteria; this definition can be found in CC
+Part 3 and is supported by the documents given in the bibliography.
+
+
+343 This annex consists of four major parts:
+
+
+a) _What an ST must contain_ . This is summarised in Section A.2, and
+described in more detail in Sections A.4 - A.10. These sections
+describe the mandatory contents of the ST, the interrelationships
+between these contents, and provide examples.
+
+
+b) _How an ST should be used_ . This is summarised in Section A.3, and
+described in more detail in section A.11. These sections describe how
+an ST should be used, and some of the questions that can be
+answered with an ST.
+
+
+c) _Low Assurance STs_ . Low Assurance STs are STs with reduced
+content. They are described in detail in section A.12.
+
+
+d) _Claiming compliance with standards_ . Section A.13 describes how an
+ST writer can claim that the TOE meets a particular standard.
+
+## **A.2 Mandatory contents of an ST**
+
+
+344 Figure 5 portrays the mandatory contents of an ST that are given in CC Part
+3. Figure 5 may also be used as a structural outline of the ST, though
+alternative structures are allowed. For instance, if the security requirements
+rationale is particularly bulky, it could be included in an appendix of the ST
+instead of in the security requirements section. The separate sections of an
+ST and the contents of those sections are briefly summarised below and
+explained in much more detail in sections A.4 to A.10. An ST normally
+contains:
+
+
+a) _an ST introduction_ containing three narrative descriptions of the TOE
+on different levels of abstraction;
+
+
+b) _a conformance claim_, showing whether the ST claims conformance
+to any PPs and/or packages, and if so, to which PPs and/or packages;
+
+
+c) _a security problem definition_, showing threats, OSPs and
+assumptions;
+
+
+Page 64 of 106 Version 3.1 April 2017
+
+
+**Specification of Security Targets**
+
+
+d) _security objectives_, showing how the solution to the security problem
+is divided between security objectives for the TOE and security
+objectives for the operational environment of the TOE;
+
+
+e) _extended components definition_ (optional), where new components
+(i.e. those not included in CC Part 2 or CC Part 3) may be defined.
+These new components are needed to define extended functional and
+extended assurance requirements;
+
+
+f) _security requirements_, where a translation of the security objectives
+for the TOE into a standardised language is provided. This
+standardised language is in the form of SFRs. Additionally this
+section defines the SARs;
+
+
+g) _a TOE summary specification_, showing how the SFRs are
+implemented in the TOE.
+
+
+345 There also exists low assurance STs which have reduced contents; these are
+described in detail in section A.12. All other parts of this Annex assume an
+ST with full contents.
+
+
+**Figure 5 - Security Target contents**
+
+
+April 2017 Version 3.1 Page 65 of 106
+
+
+**Specification of Security Targets**
+
+## **A.3 Using an ST**
+
+
+**A.3.1** **How an ST should be used**
+
+
+346 A typical ST fulfils two roles:
+
+
+๏ญ Before and during the evaluation, the ST specifies โwhat is to be
+evaluatedโ. In this role, the ST serves as a basis for agreement
+between the developer and the evaluator on the exact security
+properties of the TOE and the exact scope of the evaluation.
+Technical correctness and completeness are major issues for this role.
+Section A.7 describes how the ST should be used in this role.
+
+
+๏ญ After the evaluation, the ST specifies โwhat was evaluatedโ. In this
+role, the ST serves as a basis for agreement between the developer or
+re-seller of the TOE and the potential consumer of the TOE. The ST
+describes the exact security properties of the TOE in an abstract
+manner, and the potential consumer can rely on this description
+because the TOE has been evaluated to meet the ST. Ease of use and
+understandability are major issues for this role. Section A.11
+describes how the ST should be used in this role.
+
+
+**A.3.2** **How an ST should not be used**
+
+
+347 Two roles (among many) that an ST should not fulfil are:
+
+
+๏ญ _a detailed specification_ : An ST is designed to be a security
+specification on a relatively high level of abstraction. An ST should,
+in general, not contain detailed protocol specifications, detailed
+descriptions of algorithms and/or mechanisms, long description of
+detailed operations etc.
+
+
+๏ญ _a complete specification_ : An ST is designed to be a security
+specification and not a general specification. Unless security-relevant,
+properties such as interoperability, physical size and weight, required
+voltage etc. should not be part of an ST. This means that in general an
+ST may be a part of a complete specification, but not a complete
+specification itself.
+
+## **A.4 ST Introduction (ASE_INT)**
+
+
+348 The ST introduction describes the TOE in a narrative way on three levels of
+abstraction:
+
+
+a) the ST reference and the TOE reference, which provide identification
+material for the ST and the TOE that the ST refers to;
+
+
+b) the TOE overview, which briefly describes the TOE;
+
+
+c) the TOE description, which describes the TOE in more detail.
+
+
+Page 66 of 106 Version 3.1 April 2017
+
+
+**Specification of Security Targets**
+
+
+**A.4.1** **ST reference and TOE reference**
+
+
+349 An ST contains a clear ST reference that identifies that particular ST. A
+typical ST reference consists of title, version, authors and publication date.
+An example of an ST reference is โMauveRAM Database ST, version 1.3,
+MauveCorp Specification Team, 11 October 2002โ.
+
+
+350 An ST also contains a TOE reference that identifies the TOE that claims
+conformance to the ST. A typical TOE reference consists of developer name,
+TOE name and TOE version number. An example of a TOE reference is
+โMauveCorp MauveRAM Database v2.11โ. As a single TOE may be
+evaluated multiple times, for instance by different consumers of that TOE,
+and therefore have multiple STs, this reference is not necessarily unique.
+
+
+351 If the TOE is constructed from one or more well-known products, it is
+allowed to reflect this in the TOE reference, by referring to the product
+name(s). However, this should not be used to mislead consumers: situations
+where major parts or security functionalities were not considered in the
+evaluation, yet the TOE reference does not reflect this are not allowed.
+
+
+352 The ST reference and the TOE reference facilitate indexing and referencing
+the ST and TOE and their inclusion in summaries of lists of evaluated
+TOEs/Products.
+
+
+**A.4.2** **TOE overview**
+
+
+353 The TOE overview is aimed at potential consumers of a TOE who are
+looking through lists of evaluated TOEs/Products to find TOEs that may
+meet their security needs, and are supported by their hardware, software and
+firmware. The typical length of a TOE overview is several paragraphs.
+
+
+354 To this end, the TOE overview briefly describes the usage of the TOE and its
+major security features, identifies the TOE type and identifies any major
+non-TOE hardware/software/firmware required by the TOE.
+
+
+**A.4.2.1** Usage and major security features of a TOE
+
+
+355 The description of the usage and major security features of the TOE is
+intended to give a very general idea of what the TOE is capable of in terms
+of security, and what it can be used for in a security context. This section
+should be written for (potential) TOE consumers, describing TOE usage and
+major security features in terms of business operations, using language that
+TOE consumers understand.
+
+
+356 An example of this is โThe MauveCorp MauveRAM Database v2.11 is a
+multi-user database intended to be used in a networked environment. It
+allows 1024 users to be active simultaneously. It allows password/token and
+biometric authentication, protects against accidental data corruption, and can
+roll-back ten thousand transactions. Its audit features are highly configurable,
+so as to allow detailed audit to be performed for some users and transactions,
+while protecting the privacy of other users and transactions.โ
+
+
+April 2017 Version 3.1 Page 67 of 106
+
+
+**Specification of Security Targets**
+
+
+**A.4.2.2** TOE type
+
+
+357 The TOE overview identifies the general type of TOE, such as: firewall,
+VPN-firewall, smart card, crypto-modem, intranet, web server, database,
+web server and database, LAN, LAN with web server and database, etc.
+
+
+358 It may be the case that the TOE is not of a readily available type, in which
+case โnoneโ would be acceptable.
+
+
+359 In some cases, a TOE type can mislead consumers. Examples include:
+
+
+๏ญ certain functionality can be expected of the TOE because of its TOE
+type, but the TOE does not have this functionality. Examples include:
+
+
+๏ญ an ATM-card type TOE, which does not support any
+identification/authentication functionality;
+
+
+๏ญ a firewall type TOE, which does not support protocols that are
+almost universally used;
+
+
+๏ญ a PKI-type TOE, which has no certificate revocation
+functionality.
+
+
+๏ญ the TOE can be expected to operate in certain operational
+environments because of its TOE type, but it cannot do so. Examples
+include:
+
+
+๏ญ a PC-operating system type TOE, which is unable to function
+securely unless the PC has no network connection, floppy
+drive, and CD/DVD-player;
+
+
+๏ญ a firewall, which is unable to function securely unless all
+users that can connect through that firewall are benign.
+
+
+**A.4.2.3** Required non-TOE hardware/software/firmware
+
+
+360 While some TOEs do not rely upon other IT, many TOEs (notably software
+TOEs) rely on additional, non-TOE, hardware, software and/or firmware. In
+the latter case, the TOE overview is required to identify such non-TOE
+hardware,software and/or firmware . A complete and fully detailed
+identification of the additional hardware, software and/or firmware is not
+necessary, but the identification should be complete and detailed enough for
+potential consumers to determine the major hardware,software and/or
+firmware needed to use the TOE.
+
+
+361 Example hardware/software/firmware identifications are:
+
+
+๏ญ a standard PC with a 1GHz or faster processor and 512MB or more
+RAM, running version 3.0 Update 6b, c, or 7, or version 4.0 of the
+Yaiza operating system;
+
+
+Page 68 of 106 Version 3.1 April 2017
+
+
+**Specification of Security Targets**
+
+
+๏ญ a standard PC with a 1GHz or faster version processor and 512MB or
+more RAM, running version 3.0 Update 6d of the Yaiza operating
+system and the WonderMagic 1.0 Graphics card with the 1.0 WM
+Driver Set;
+
+
+๏ญ a standard PC with version 3.0 of the Yaiza OS (or higher);
+
+
+๏ญ a CleverCard SB2067 integrated circuit;
+
+
+๏ญ a CleverCard SB2067 integrated circuit running v2.0 of the QuickOS
+smart card operating system;
+
+
+๏ญ the December 2002 installation of the LAN of the Director-General's
+Office of the Department of Traffic.
+
+
+**A.4.3** **TOE description**
+
+
+362 A TOE description is a narrative description of the TOE, likely to run to
+several pages. The TOE description should provide evaluators and potential
+consumers with a general understanding of the security capabilities of the
+TOE, in more detail than was provided in the TOE overview. The TOE
+description may also be used to describe the wider application context into
+which the TOE will fit.
+
+
+363 The TOE description discusses the physical scope of the TOE: a list of all
+hardware, firmware, software and guidance parts that constitute the TOE.
+This list should be described at a level of detail that is sufficient to give the
+reader a general understanding of those parts.
+
+
+364 The TOE description should also discuss the logical scope of the TOE: the
+logical security features offered by the TOE at a level of detail that is
+sufficient to give the reader a general understanding of those features. This
+description is expected to be in more detail than the major security features
+described in the TOE overview.
+
+
+365 An important property of the physical and logical scopes is that they describe
+the TOE in such a way that there remains no doubt on whether a certain part
+or feature is in the TOE or whether this part or feature is outside the TOE.
+This is especially important when the TOE is intertwined with and cannot be
+easily separated from non-TOE entities.
+
+
+366 Examples where the TOE is intertwined with non-TOE entities are:
+
+
+๏ญ the TOE is a cryptographic co-processor of a smart card IC, instead
+of the entire IC;
+
+
+๏ญ the TOE is a smart card IC, except for the cryptographic processor;
+
+
+๏ญ the TOE is the Network Address Translation part of the MinuteGap
+Firewall v18.5.
+
+
+April 2017 Version 3.1 Page 69 of 106
+
+
+**Specification of Security Targets**
+
+## **A.5 Conformance claims (ASE_CCL)**
+
+
+367 This section of an ST describes how the ST conforms with:
+
+
+๏ญ Part 2 and Part 3 of this International Standard;
+
+
+๏ญ Protection Profiles (if any);
+
+
+๏ญ Packages (if any).
+
+
+368 The description of how the ST conforms to the CC consists of two items: the
+version of the CC that is used and whether the ST contains extended security
+requirements or not (see Section A.8).
+
+
+369 The description of conformance of the ST to Protection Profiles means that
+the ST lists the packages that conformance is being claimed to. For an
+explanation of this, see Section 10.5.
+
+
+370 The description of conformance of the ST to packages means that the ST lists
+the packages that conformance is being claimed to. For an explanation of this,
+see Section 10.5.
+
+
+371 A Security Target can use PP-Configurations in the same way as standard
+Protection Profiles. That is, the _Conformance claim_ of a ST can contain a _PP_
+_claim_ that identifies the PP-Configurations the ST is conformant with.
+
+## **A.6 Security problem definition (ASE_SPD)**
+
+
+**A.6.1** **Introduction**
+
+
+372 The security problem definition defines the security problem that is to be
+addressed. The security problem definition is, as far as the CC is concerned,
+axiomatic. That is, the process of deriving the security problem definition
+falls outside the scope of the CC.
+
+
+373 However, it should be noted that the usefulness of the results of an
+evaluation strongly depends on the ST, and the usefulness of the ST strongly
+depends on the quality of the security problem definition. It is therefore often
+worthwhile to spend significant resources and use well-defined processes and
+analyses to derive a good security problem definition.
+
+
+374 Note that according to CC Part 3 it is not mandatory to have statements in all
+sections, an ST with threats does not need to have OSPs and vice versa. Also,
+any ST may omit assumptions.
+
+
+375 Also note that where the TOE is physically distributed, it may be better to
+discuss the relevant threats, OSPs and assumptions separately for distinct
+domains of the TOE operational environment.
+
+
+Page 70 of 106 Version 3.1 April 2017
+
+
+**Specification of Security Targets**
+
+
+**A.6.2** **Threats**
+
+
+376 This section of the security problem definition shows the threats that are to
+be countered by the TOE, its operational environment, or a combination of
+the two.
+
+
+377 A threat consists of an adverse action performed by a threat agent on an asset.
+
+
+378 Adverse actions are actions performed by a threat agent on an asset. These
+actions influence one or more properties of an asset from which that asset
+derives its value.
+
+
+379 Threat agents may be described as individual entities, but in some cases it
+may be better to describe them as types of entities, groups of entities etc.
+
+
+380 Examples of threat agents are hackers, users, computer processes, and
+accidents. Threat agents may be further described by aspects such as
+expertise, resources, opportunity and motivation.
+
+
+381 Examples of threats are:
+
+
+๏ญ a hacker (with substantial expertise, standard equipment, and being
+paid to do so) remotely copying confidential files from a company
+network;
+
+
+๏ญ a worm seriously degrading the performance of a wide-area network;
+
+
+๏ญ a system administrator violating user privacy;
+
+
+๏ญ someone on the Internet listening in on confidential electronic
+communication.
+
+
+**A.6.3** **Organisational security policies (OSPs)**
+
+
+382 This section of the security problem definition shows the OSPs that are to be
+enforced by the TOE, its operational environment, or a combination of the
+two.
+
+
+383 OSPs are security rules, procedures, or guidelines imposed (or presumed to
+be imposed) now and/or in the future by an actual or hypothetical
+organisation in the operational environment. OSPs may be laid down by an
+organisation controlling the operational environment of the TOE, or they
+may be laid down by legislative or regulatory bodies. OSPs can apply to the
+TOE and/or the operational environment of the TOE.
+
+
+384 Examples of OSPs are:
+
+
+๏ญ All products that are used by the Government must conform to the
+National Standard for password generation and encryption;
+
+
+April 2017 Version 3.1 Page 71 of 106
+
+
+**Specification of Security Targets**
+
+
+๏ญ Only users with System Administrator privilege and clearance of
+Department Secret shall be allowed to manage the Department
+Fileserver.
+
+
+**A.6.4** **Assumptions**
+
+
+385 This section of the security problem definition shows the assumptions that
+are made on the operational environment in order to be able to provide
+security functionality. If the TOE is placed in an operational environment
+that does not meet these assumptions, the TOE may not be able to provide all
+of its security functionality anymore. Assumptions can be on physical,
+personnel and connectivity of the operational environment.
+
+
+386 Examples of assumptions are:
+
+
+๏ญ Assumptions on physical aspects of the operational environment:
+
+
+๏ญ It is assumed that the TOE will be placed in a room that is
+designed to minimise electromagnetic emanations;
+
+
+๏ญ It is assumed that the administrator consoles of the TOE will
+be placed in a restricted access area.
+
+
+๏ญ Assumptions on personnel aspects of the operational environment:
+
+
+๏ญ It is assumed that users of the TOE will be trained sufficiently
+in order to operate the TOE;
+
+
+๏ญ It is assumed that users of the TOE are approved for
+information that is classified as National Secret;
+
+
+๏ญ It is assumed that users of the TOE will not write down their
+passwords.
+
+
+๏ญ Assumptions on connectivity aspects of the operational environment:
+
+
+๏ญ It is assumed that a PC workstation with at least 10GB of disk
+space is available to run the TOE on;
+
+
+๏ญ It is assumed that the TOE is the only non-OS application
+running on this workstation;
+
+
+๏ญ It is assumed that the TOE will not be connected to an
+untrusted network.
+
+
+387 Note that during the evaluation these assumptions are considered to be true:
+they are not tested in any way. For these reasons, assumptions can only be
+made on the operational environment. Assumptions can never be made on
+the behaviour of the TOE because an evaluation consists of evaluating
+assertions made about the TOE and not by assuming that assertions on the
+TOE are true.
+
+
+Page 72 of 106 Version 3.1 April 2017
+
+
+**Specification of Security Targets**
+
+## **A.7 Security objectives (ASE_OBJ)**
+
+
+388 The security objectives are a concise and abstract statement of the intended
+solution to the problem defined by the security problem definition. The role
+of the security objectives is threefold:
+
+
+๏ญ provide a high-level, natural language solution of the problem;
+
+
+๏ญ divide this solution into two part wise solutions, that reflect that
+different entities each have to address a part of the problem;
+
+
+๏ญ demonstrate that these part wise solutions form a complete solution to
+the problem.
+
+
+**A.7.1** **High-level solution**
+
+
+389 The security objectives consist of a set of short and clear statements without
+overly much detail that together form a high-level solution to the security
+problem. The level of abstraction of the security objectives aims at being
+clear and understandable to knowledgeable potential consumers of the TOE.
+The security objectives are in natural language.
+
+
+**A.7.2** **Part wise solutions**
+
+
+390 In an ST the high-level security solution, as described by the security
+objectives, is divided into two part wise solutions. These part wise solutions
+are called the security objectives for the TOE and the security objectives for
+the operational environment. This reflects that these part wise solutions are
+to be provided by two different entities: the TOE, and the operational
+environment.
+
+
+**A.7.2.1** Security objectives for the TOE
+
+
+391 The TOE provides security functionality to solve a certain part of the
+problem defined by the security problem definition. This part wise solution is
+called the security objectives for the TOE and consists of a set of objectives
+that the TOE should achieve in order to solve its part of the problem.
+
+
+392 Examples of security objectives for the TOE are:
+
+
+๏ญ The TOE shall keep confidential the content of all files transmitted
+between it and a Server;
+
+
+๏ญ The TOE shall identify and authenticate all users before allowing
+them access to the Transmission Service provided by the TOE;
+
+
+๏ญ The TOE shall restrict user access to data according to the Data
+Access policy described in Annex 3 of the ST.
+
+
+April 2017 Version 3.1 Page 73 of 106
+
+
+**Specification of Security Targets**
+
+
+393 If the TOE is physically distributed, it may be better to subdivide the ST
+section containing the security objectives for the TOE into several subsections to reflect this.
+
+
+**A.7.2.2** Security objectives for the operational environment
+
+
+394 The operational environment of the TOE implements technical and
+procedural measures to assist the TOE in correctly providing its security
+functionality (which is defined by the security objectives for the TOE). This
+part wise solution is called the security objectives for the operational
+environment and consists of a set of statements describing the goals that the
+operational environment should achieve.
+
+
+395 Examples of security objectives for the operational environment are:
+
+
+๏ญ The operational environment shall provide a workstation with the OS
+Inux version 3.01b to execute the TOE on;
+
+
+๏ญ The operational environment shall ensure that all human TOE users
+receive appropriate training before allowing them to work with the
+TOE;
+
+
+๏ญ The operational environment of the TOE shall restrict physical access
+to the TOE to administrative personnel and maintenance personnel
+accompanied by administrative personnel;
+
+
+๏ญ The operational environment shall ensure the confidentiality of the
+audit logs generated by the TOE before sending them to the central
+Audit Server.
+
+
+396 If the operational environment of the TOE consists of multiple sites, each
+with different properties, it may be better to subdivide the ST section
+containing the security objectives for the operational environment into
+several sub-sections to reflect this.
+
+
+**A.7.3** **Relation between security objectives and the security problem**
+**definition**
+
+
+397 The ST also contains a security objectives rationale containing two sections:
+
+
+๏ญ a tracing that shows which security objectives address which threats,
+OSPs and assumptions;
+
+
+๏ญ a set of justifications that shows that all threats, OSPs, and
+assumptions are effectively addressed by the security objectives.
+
+
+**A.7.3.1** Tracing between security objectives and the security problem
+definition
+
+
+398 The tracing shows how the security objectives trace back to the threats, OSPs
+and assumptions as described in the security problem definition.
+
+
+Page 74 of 106 Version 3.1 April 2017
+
+
+**Specification of Security Targets**
+
+
+a) _No spurious objectives_ : Each security objective traces to at least one
+threat, OSP or assumption.
+
+
+b) _Complete with respect to the security problem definition_ : Each threat,
+OSP and assumption has at least one security objective tracing to it.
+
+
+c) _Correct tracing_ : Since assumptions are always made by the TOE on
+the operational environment, security objectives for the TOE do not
+trace back to assumptions. The tracings allowed by CC Part 3 are
+depicted in Figure 6.
+
+
+**Figure 6 - Tracings between security objectives and security problem definition**
+
+
+399 Multiple security objectives may trace to the same threat, indicating that the
+combination of those security objectives counters that threat. A similar
+argument holds for OSPs and assumptions.
+
+
+**A.7.3.2** Providing a justification for the tracing
+
+
+400 The security objectives rationale also demonstrates that the tracing is
+effective: All the given threats, OSPs and assumption are addressed (i.e.
+countered, enforced and upheld respectively) if all security objectives tracing
+to a particular threat, OSP or assumption are achieved.
+
+
+401 This demonstration analyses the effect of achieving the relevant security
+objectives on countering the threats, enforcing the OSPs and upholding the
+assumptions and leads to the conclusion that this is indeed the case.
+
+
+402 In some cases, where parts of the security problem definition very closely
+resemble some security objectives, the demonstration can be very simple. An
+example is: a threat โT17: Threat agent X reads the Confidential Information
+in transit between A and Bโ, a security objective for the TOE: โOT12: The
+TOE shall ensure that all information transmitted between A and B is kept
+confidentialโ, and a demonstration โT17 is directly countered by OT12โ.
+
+
+**A.7.3.3** On countering threats
+
+
+403 Countering a threat does not necessarily mean removing that threat, it can
+also mean sufficiently diminishing that threat or sufficiently mitigating that
+threat.
+
+
+404 Examples of removing a threat are:
+
+
+April 2017 Version 3.1 Page 75 of 106
+
+
+**Specification of Security Targets**
+
+
+๏ญ removing the ability to execute the adverse action from the threat
+agent;
+
+
+๏ญ moving, changing or protecting the asset in such a way that the
+adverse action is no longer applicable to it;
+
+
+๏ญ removing the threat agent (e.g. removing machines from a network
+that frequently crash that network).
+
+
+405 Examples of diminishing a threat are:
+
+
+๏ญ restricting the ability of a threat agent to perform adverse actions;
+
+
+๏ญ restricting the opportunity to execute an adverse action of a threat
+agent;
+
+
+๏ญ reducing the likelihood of an executed adverse action being
+successful;
+
+
+๏ญ reducing the motivation to execute an adverse action of a threat agent
+by deterrence;
+
+
+๏ญ requiring greater expertise or greater resources from the threat agent.
+
+
+406 Examples of mitigating the effects of a threat are:
+
+
+๏ญ making frequent back-ups of the asset;
+
+
+๏ญ obtaining spare copies of an asset;
+
+
+๏ญ insuring an asset;
+
+
+๏ญ ensuring that successful adverse actions are always timely detected,
+so that appropriate action can be taken.
+
+
+**A.7.4** **Security objectives: conclusion**
+
+
+407 Based on the security objectives and the security objectives rationale, the
+following conclusion can be drawn: if all security objectives are achieved
+then the security problem as defined in Security problem definition
+(ASE_SPD) is solved: all threats are countered, all OSPs are enforced, and
+all assumptions are upheld.
+
+## **A.8 Extended Components Definition (ASE_ECD)**
+
+
+408 In many cases the security requirements (see the next section) in an ST are
+based on components in CC Part 2 or CC Part 3. However, in some cases,
+there may be requirements in an ST that are not based on components in CC
+Part 2 or CC Part 3. In this case, new components (extended components)
+must be defined, and this definition should be done in the Extended
+Components Definition. For more information on this, see Annex C.4.
+
+
+Page 76 of 106 Version 3.1 April 2017
+
+
+**Specification of Security Targets**
+
+
+409 Note that this section is intended to contain only the extended components
+and not the extended requirements (requirements based on extended
+components). The extended requirements should be included in the security
+requirements (see the next section) and are for all purposes the same as
+requirements based on components in CC Part 2 or CC Part 3.
+
+## **A.9 Security requirements (ASE_REQ)**
+
+
+410 The security requirements consist of two groups of requirements:
+
+
+a) _the security functional requirements_ (SFRs): a translation of the
+security objectives for the TOE into a standardised language;
+
+
+b) _the security assurance requirements_ (SARs): a description of how
+assurance is to be gained that the TOE meets the SFRs.
+
+
+411 These two groups are discussed in the following two sections:
+
+
+**A.9.1** **Security functional requirements (SFRs)**
+
+
+412 The SFRs are a translation of the security objectives for the TOE. They are
+usually at a more detailed level of abstraction, but they have to be a complete
+translation (the security objectives must be completely addressed) and be
+independent of any specific technical solution (implementation). The CC
+requires this translation into a standardised language for several reasons:
+
+
+๏ญ to provide an exact description of what is to be evaluated. As security
+objectives for the TOE are usually formulated in natural language,
+translation into a standardised language enforces a more exact
+description of the functionality of the TOE.
+
+
+๏ญ to allow comparison between two STs. As different ST authors may
+use different terminology in describing their security objectives, the
+standardised language enforces using the same terminology and
+concepts. This allows easy comparison.
+
+
+413 There is no translation required in the CC for the security objectives for the
+operational environment, because the operational environment is not
+evaluated and does therefore not require a description aimed at its evaluation.
+See the bibliography for items relevant to the security assessment of
+operational systems.
+
+
+414 It may be the case that parts of the operational environment are evaluated in
+another evaluation, but this is out of scope for the current evaluation. For
+example: an OS TOE may require a firewall to be present in its operational
+environment. Another evaluation may subsequently evaluate the firewall, but
+this evaluation has nothing to do with the evaluation of the OS TOE.
+
+
+**A.9.1.1** How the CC supports this translation
+
+
+415 The CC supports this translation in three ways:
+
+
+April 2017 Version 3.1 Page 77 of 106
+
+
+**Specification of Security Targets**
+
+
+a) by providing a predefined precise โlanguageโ designed to describe
+exactly what is to be evaluated. This language is defined as a set of
+components defined in CC Part 2. The use of this language as a welldefined translation of the security objectives for the TOE to SFRs is
+mandatory, though some exceptions exist (see Section 8.3).
+
+
+b) by providing operations: mechanisms that allow the ST writer to
+modify the SFRs to provide a more accurate translation of the
+security objectives for the TOE. This part of the CC defines the four
+allowed operations: assignment, selection, iteration, and refinement.
+These are described further in Section 8.1.
+
+
+c) by providing dependencies: a mechanism that supports a more
+complete translation to SFRs. In the CC Part 2 language, an SFR can
+have a dependency on other SFRs. This signifies that if an ST uses
+that SFR, it generally needs to use those other SFRs as well. This
+makes it much harder for the ST writer to overlook including
+necessary SFRs and thereby improves the completeness of the ST.
+Dependencies are described further in Section 8.2.
+
+
+**A.9.1.2** Relation between SFRs and security objectives
+
+
+416 The ST also contains a security requirements rationale, consisting of two
+sections about SFRs:
+
+
+๏ญ a tracing that shows which SFRs address which security objectives
+for the TOE;
+
+
+๏ญ a set of justifications that shows that all security objectives for the
+TOE are effectively addressed by the SFRs.
+
+
+**A.9.1.2.1** Tracing between SFRs and the security objectives for the TOE
+
+
+417 The tracing shows how the SFRs trace back to the security objectives for the
+TOE as follows:
+
+
+a) _No spurious SFRs_ : Each SFR traces back to at least one security
+objective.
+
+
+b) _Complete with respect to the security objectives for the TOE_ : Each
+security objective for the TOE has at least one SFR tracing to it.
+
+
+418 Multiple SFRs may trace to the same security objective for the TOE,
+indicating that the combination of those security requirements meets that
+security objective for the TOE.
+
+
+**A.9.1.2.2** Providing a justification for the tracing
+
+
+419 The security requirements rationale demonstrates that the tracing is effective:
+if all SFRs tracing to a particular security objective for the TOE are satisfied,
+that security objective for the TOE is achieved.
+
+
+Page 78 of 106 Version 3.1 April 2017
+
+
+**Specification of Security Targets**
+
+
+420 This demonstration should analyse the effects of satisfying the relevant SFRs
+on achieving the security objective for the TOE and lead to the conclusion
+that this is indeed the case.
+
+
+421 In cases where SFRs very closely resemble security objectives for the TOE,
+the demonstration can be very simple.
+
+
+**A.9.2** **Security assurance requirements (SARs)**
+
+
+422 The SARs are a description of how the TOE is to be evaluated. This
+description uses a standardised language for two reasons:
+
+
+๏ญ to provide an exact description of how the TOE is to be evaluated.
+Using a standardised language assists in creating an exact description
+and avoids ambiguity.
+
+
+๏ญ to allow comparison between two STs. As different ST authors may
+use different terminology in describing the evaluation, the
+standardised language enforces using the same terminology and
+concepts. This allows easy comparison.
+
+
+423 This standardised language is defined as a set of components defined in CC
+Part 3. The use of this language is mandatory, though some exceptions exist.
+The CC enhances this language in two ways:
+
+
+a) by providing operations: mechanisms that allow the ST writer to
+modify the SARs. The CC has four operations: assignment, selection,
+iteration, and refinement. These are described further in Section 8.1.
+
+
+b) by providing dependencies: a mechanism that supports a more
+complete translation to SARs. In CC Part 3 language, an SAR can
+have a dependency on other SARs. This signifies that if an ST uses
+that SAR, it generally needs to use those other SARs as well. This
+makes it much harder for the ST writer to overlook including
+necessary SARs and thereby improves the completeness of STs.
+Dependencies are described further in Section 8.2.
+
+
+**A.9.3** **SARs and the security requirement rationale**
+
+
+424 The ST also contains a security requirements rationale that explains why this
+particular set of SARs was deemed appropriate. There are no specific
+requirements for this explanation. The goal for this explanation is to allow
+the readers of the ST to understand the reasons why this particular set was
+chosen.
+
+
+425 An example of an inconsistency is if the security problem description
+mentions threats where the threat agent is very capable, and a low (or no)
+Vulnerability analysis (AVA_VAN) is included in the SARs.
+
+
+April 2017 Version 3.1 Page 79 of 106
+
+
+**Specification of Security Targets**
+
+
+**A.9.4** **Security requirements: conclusion**
+
+
+426 In the security problem definition of the ST, the security problem is defined
+as consisting of threats, OSPs and assumptions. In the security objectives
+section of the ST, the solution is provided in the form of two sub-solutions:
+
+
+๏ญ security objectives for the TOE;
+
+
+๏ญ security objectives for the operational environment.
+
+
+427 Additionally, a security objectives rationale is provided showing that if all
+security objectives are achieved, the security problem is solved: all threats
+are countered, all OSPs are enforced, and all assumptions are upheld.
+
+
+**Figure 7 - Relations between the security problem definition, the security**
+
+**objectives and the security requirements**
+
+
+428 In the security requirements section of the ST, the security objectives for the
+TOE are translated to SFRs and a security requirements rationale is provided
+showing that if all SFRs are satisfied, all security objectives for the TOE are
+achieved.
+
+
+429 Additionally, a set of SARs is provided to show how the TOE is evaluated,
+together with an explanation for selecting these SARs.
+
+
+430 All of the above can be combined into the statement: If all SFRs and SARs
+are satisfied and all security objectives for the operational environment are
+achieved, then there exists assurance that the security problem as defined in
+ASE_SPD is solved: all threats are countered, all OSPs are enforced, and all
+assumptions are upheld. This is illustrated in Figure 7.
+
+
+431 The amount of assurance obtained is defined by the SARs, and whether this
+amount of assurance is sufficient is defined by the explanation for choosing
+these SARs.
+
+## **A.10 TOE summary specification (ASE_TSS)**
+
+
+432 The objective for the TOE summary specification is to provide potential
+consumers of the TOE with a description of how the TOE satisfies all the
+
+
+Page 80 of 106 Version 3.1 April 2017
+
+
+**Specification of Security Targets**
+
+
+SFRs. The TOE summary specification should provide the general technical
+mechanisms that the TOE uses for this purpose. The level of detail of this
+description should be enough to enable potential consumers to understand
+the general form and implementation of the TOE.
+
+
+433 For instance if the TOE is an Internet PC and the SFRs contain FIA_UAU.1
+to specify authentication, the TOE summary specification should indicate
+how this authentication is done: password, token, iris scanning etc. More
+information, like applicable standards that the TOE uses to meet SFRs, or
+more detailed descriptions may also be provided.
+
+## **A.11 Questions that may be answered with an ST**
+
+
+434 After the evaluation, the ST specifies โwhat was evaluatedโ. In this role, the
+ST serves as a basis for agreement between the developer or re-seller of the
+TOE and the potential consumer of the TOE. The ST can therefore answer
+the following questions (and more):
+
+
+a) _How can I find the ST/TOE that I need given the multitude of existing_
+_STs/TOEs?_ This question is addressed by the TOE overview, which
+gives a brief (several paragraphs) summary of the TOE;
+
+
+b) _Does this TOE fit in with my existing IT-infrastructure?_ This question
+is addressed by the TOE overview, which identifies the major
+hardware/firmware/software elements needed to run the TOE;
+
+
+c) _Does this TOE fit in with my existing operational environment?_ This
+question is addressed by the security objectives for the operational
+environment, which identifies all constraints the TOE places on the
+operational environment in order to function;
+
+
+d) _What does the TOE do (interested reader)?_ This question is
+addressed by the TOE overview, which gives a brief (several
+paragraphs) summary of the TOE;
+
+
+e) _What does the TOE do (potential consumer)?_ This question is
+addressed by the TOE description, which gives a less brief (several
+pages) summary of the TOE;
+
+
+f) _What does the TOE do (technical)?_ This question is addressed by the
+TOE summary specification which provides a high-level description
+of the mechanisms the TOE uses;
+
+
+g) _What does the TOE do (expert)?_ This question is addressed by the
+SFRs which provide an abstract highly technical description, and the
+TOE summary specification which provide additional detail;
+
+
+h) _Does the TOE address the problem as defined by my_
+_government/organisation?_ If your government/organisation has
+defined packages and/or PPs to define this solution, then the answer
+
+
+April 2017 Version 3.1 Page 81 of 106
+
+
+**Specification of Security Targets**
+
+
+can be found in the Conformance Claims section of the ST, which
+lists all packages and PPs that the ST conforms to
+
+
+i) _Does the TOE address my security problem (expert)?_ What are the
+threats countered by the TOE? What organisational security policies
+does it enforce? What assumptions does it make about the operational
+environment? These questions are addressed by the security problem
+definition;
+
+
+j) _How much trust can I place in the TOE?_ This can be found in the
+SARs in the security requirements section, which provide the
+assurance level that was used to evaluate the TOE, and hence the trust
+that the evaluation provides in the correctness of the TOE.
+
+## **A.12 Low assurance Security Targets**
+
+
+435 Writing an ST is not a trivial task, and may, especially in low assurance
+evaluations, be a major part of the total effort expended by the developer and
+the evaluator in the whole of the evaluation. For this reason, it is also
+possible to write a low assurance ST.
+
+
+436 The CC allows the use of a low assurance ST for an EAL 1 evaluation, but
+not for EAL 2 and up. A low-assurance ST may only claim conformance to a
+low-assurance PP (see Annex B). A regular ST (i.e., one with full contents)
+may claim conformance with a low assurance PP.
+
+
+437 A low assurance ST has a significantly reduced content compared to a
+regular ST:
+
+
+๏ญ there is no need to describe the security problem definition;
+
+
+๏ญ there is no need to describe the security objectives for the TOE. The
+security objectives for the operational environment must still be
+described;
+
+
+๏ญ there is no need to describe the security objectives rationale as there
+is no security problem definition in the ST;
+
+
+๏ญ the security requirements rationale only needs to justify (any)
+dependencies not being satisfied as there are no security objectives
+for the TOE in the ST.
+
+
+438 All that remains are:
+
+
+a) the references to TOE and ST;
+
+
+b) a conformance claim;
+
+
+c) the various narrative descriptions;
+
+
+1. the TOE overview;
+
+
+Page 82 of 106 Version 3.1 April 2017
+
+
+**Specification of Security Targets**
+
+
+2. the TOE description;
+
+
+3. the TOE summary specification.
+
+
+d) security objectives for the operational environment;
+
+
+e) the SFRs and the SARs (including the extended components
+definition) and the security requirements rationale (only if the
+dependencies are not satisfied).
+
+
+439 The reduced content of a low assurance ST is shown in Figure 8.
+
+
+**Figure 8 - Contents of a Low Assurance Security Target**
+
+## **A.13 Referring to other standards in an ST**
+
+
+440 In some cases, an ST writer may wish to refer to an external standard, such
+as a particular cryptographic standard or protocol. The CC allows three ways
+of doing this:
+
+
+a) As an organisational security policy (or part of it).
+
+
+If, for example, there exists a government standard defining how
+passwords have to be chosen, this may be stated as an organisational
+security policy in an ST. This may lead to an objective for the
+environment (e. g. if users of the TOE need to choose passwords
+accordingly), or it may lead to security objectives for the TOE and
+then to appropriate SFRs (likely of the FIA class), if the TOE
+
+
+April 2017 Version 3.1 Page 83 of 106
+
+
+**Specification of Security Targets**
+
+
+generates passwords. In both cases the rationale of the developer
+needs to make plausible that the security objectives for the TOE and
+the SFRs are suitable to fulfil the OSP. The evaluator will examine if
+this is in fact plausible (and may decide to look into the standard for
+this), if the OSP is implemented by SFRs, as explained below.
+
+
+b) As a technical standard (for example a cryptographic standard) used
+in a refinement of an SFR.
+
+
+In this case conformance to the standard is part of the fulfilment of
+the SFR by the TOE and is treated as if the full text of the standard is
+part of the SFR. Conformance is subsequently determined like any
+other conformance to SFRs: during ADV: Development and ATE:
+Tests it is analysed, by design analysis and tests, that the SFR is
+completely and fully implemented in the TOE. If reference to only a
+certain part of a standard is desired, that part should be
+unambiguously stated in the SFR refinement.
+
+
+c) As a technical standard (for example a cryptographic standard)
+mentioned in the TOE summary specification.
+
+
+The TOE summary specification is only considered as an explanation
+of how the SFRs are realised, and is not strictly used as a strict
+implementation requirement like the SFRs or the documents
+delivered for ADV: Development. So the evaluator may detect an
+inconsistency if the TSS references a technical standard and this is
+not reflected in ADV: Development documentation, but there is no
+routine activity to test fulfilment of the standard.
+
+
+Page 84 of 106 Version 3.1 April 2017
+
+
+**Specification of Protection Profiles**
+
+# **B Specification of Protection Profiles** **(informative)**
+
+## **B.1 Goal and structure of this Annex**
+
+
+441 The goal of this Annex is to explain the Protection Profile (PP) concept. This
+Annex does not define the APE criteria; this definition can be found in CC
+Part 3 and is supported by the documents given in the bibliography.
+
+
+442 As PPs and STs have a significant overlap, this Annex focuses on the
+differences between PPs and STs. The material that is identical between STs
+and PPs is described in Annex A.
+
+
+443 This annex consists of four major parts:
+
+
+a) _What a PP must contain_ . This is summarised in Section B.2, and
+described in more detail in Sections B.4-B.9. These chapters describe
+the mandatory contents of the PP, the interrelationships between
+these contents, and provide examples.
+
+
+b) _How a PP should be used_ . This is summarised in Section B.3.
+
+
+c) _Low Assurance PPs_ . Low Assurance PPs are PPs with reduced
+content. They are described in detail in Section B.11.
+
+
+d) _Claiming compliance with standards_ . Section B.12 describes how a
+PP writer can claim that the TOE is to meet a particular standard.
+
+## **B.2 Mandatory contents of a PP**
+
+
+444 Figure 9 portrays the mandatory content for a PP that is given in CC Part 3.
+Figure 9 may also be used as a structural outline of the PP, though alternative
+structures are allowed. For instance, if the security requirements rationale is
+particularly bulky, it could be included in an appendix of the PP instead of in
+the security requirements section. The separate sections of a PP and the
+contents of those sections are briefly summarised below and explained in
+much more detail in Sections B.4 - B.9. A PP contains:
+
+
+a) a PP _introduction_ containing a narrative description of the TOE type;
+
+
+b) a _conformance claim_, showing whether the PP claims conformance to
+any PPs and/or packages, and if so, to which PPs and/or packages;
+
+
+c) a _security problem definition_, showing threats, OSPs and
+assumptions;
+
+
+d) _security objectives_, showing how the solution to the security problem
+is divided between security objectives for the TOE and security
+objectives for the operational environment of the TOE;
+
+
+April 2017 Version 3.1 Page 85 of 106
+
+
+**Specification of Protection Profiles**
+
+
+e) _extended components definition_, where new components (i.e. those
+not included in CC Part 2 or CC Part 3) may be defined. These new
+components are needed to define extended functional and extended
+assurance requirements;
+
+
+f) _security requirements_, where a translation of the security objectives
+for the TOE into a standardised language is provided. This
+standardised language is in the form of SFRs. Additionally this
+section defines the SARs;
+
+
+445 There also exist low assurance PPs, which have reduced contents; these are
+described in detail in Section B.11. With this exception, all other parts of this
+Annex assume a PP with full contents.
+
+
+**Figure 9 - Protection Profile contents**
+
+## **B.3 Using the PP**
+
+
+**B.3.1** **How a PP should be used**
+
+
+446 A PP is typically a statement of need where a user community, a regulatory
+entity, or a group of developers define a common set of security needs. A PP
+gives consumers a means of referring to this set, and facilitates future
+evaluation against these needs.
+
+
+447 A PP is therefore typically used as:
+
+
+๏ญ part of a requirement specification for a specific consumer or group
+of consumers, who will only consider buying a specific type of IT if
+it meets the PP;
+
+
+Page 86 of 106 Version 3.1 April 2017
+
+
+**Specification of Protection Profiles**
+
+
+๏ญ part of a regulation from a specific regulatory entity, who will only
+allow a specific type of IT to be used if it meets the PP;
+
+
+๏ญ a baseline defined by a group of IT developers, who then agree that
+all IT that they produce of this type will meet this baseline.
+
+
+though this does not preclude other uses.
+
+
+**B.3.2** **How a PP should not be used**
+
+
+448 Three roles (among many) that a PP should not fulfil are:
+
+
+๏ญ _a detailed specification_ : A PP is designed to be a security
+specification on a relatively high level of abstraction. A PP should, in
+general, not contain detailed protocol specifications, detailed
+descriptions of algorithms and/or mechanisms, long description of
+detailed operations etc.
+
+
+๏ญ _a complete specification_ : A PP is designed to be a security
+specification and not a general specification. Unless security-relevant,
+properties such as interoperability, physical size and weight, required
+voltage etc. should not be part of a PP. This means that in general a
+PP is a part of a complete specification, but not a complete
+specification itself.
+
+
+๏ญ _a specification of a single product_ : Unlike an ST, a PP is designed to
+describe a certain type of IT, and not a single product. When only a
+single product is described, it is better to use an ST for this purpose.
+
+## **B.4 PP introduction (APE_INT)**
+
+
+449 The PP introduction describes the TOE in a narrative way on two levels of
+abstraction:
+
+
+a) the PP reference, which provides identification material for the PP;
+
+
+b) the TOE overview, which briefly describes the TOE.
+
+
+**B.4.1** **PP reference**
+
+
+450 A PP contains a clear PP reference that identifies that particular PP. A typical
+PP reference consists of title, version, authors and publication date. An
+example of a PP reference is โAtlantean Navy CablePhone Encryptor PP,
+version 2b, Atlantean Navy Procurement Office, April 7, 2003โ. The
+reference must be unique so that it is possible to tell different PPs and
+different versions of the same PP apart.
+
+
+451 The PP reference facilitates indexing and referencing the PP and its inclusion
+in lists of PPs.
+
+
+April 2017 Version 3.1 Page 87 of 106
+
+
+**Specification of Protection Profiles**
+
+
+**B.4.2** **TOE overview**
+
+
+452 The TOE overview is aimed at potential consumers of a TOE who are
+looking through lists of evaluated products to find TOEs that may meet their
+security needs, and are supported by their hardware, software and firmware.
+
+
+453 The TOE overview is also aimed at developers who may use the PP in
+designing TOEs or in adapting existing products.
+
+
+454 The typical length of a TOE overview is several paragraphs.
+
+
+455 To this end, the TOE overview briefly describes the usage of the TOE and its
+major security features, identifies the TOE type and identifies any major
+non-TOE hardware/software/firmware available to the TOE.
+
+
+**B.4.2.1** Usage and major security features of a TOE
+
+
+456 The description of the usage and major security features of the TOE is
+intended to give a very general idea of what the TOE should be capable of,
+and what it can be used for. This section should be written for (potential)
+TOE consumers, describing TOE usage and major security features in terms
+of business operations, using language that TOE consumers understand.
+
+
+457 An example of this is โThe Atlantean Navy CablePhone Encryptor is an
+encryption device that should allow confidential communication between
+ships across the Atlantean Navy CablePhone system. To this end it should
+allow at least 32 different users and support at least 100 Mbps encryption
+speed. It should allow both bilateral communication between ships and
+broadcast across the entire network.โ
+
+
+**B.4.2.2** TOE Type
+
+
+458 The TOE overview identifies the general type of TOE, such as: firewall,
+VPN-firewall, smart card, crypto-modem, intranet, web server, database,
+web server and database, LAN, LAN with web server and database, etc.
+
+
+**B.4.2.3** Available non-TOE hardware/software/firmware
+
+
+459 While some TOEs do not rely upon other IT, many TOEs (notably software
+TOEs) rely on additional, non-TOE, hardware, software and/or firmware. In
+the latter case, the TOE overview is required to identify the non-TOE
+hardware/software/firmware.
+
+
+460 As a Protection Profile is not written for a specific product, in many cases
+only a general idea can be given of the available hardware/software/firmware.
+In some other cases, e.g. a requirements specification for a specific consumer
+where the platform is already known, (much) more specific information may
+be provided.
+
+
+461 Examples of hardware/software/firmware identifications are:
+
+
+๏ญ None. (for a completely stand-alone TOE);
+
+
+Page 88 of 106 Version 3.1 April 2017
+
+
+**Specification of Protection Profiles**
+
+
+๏ญ The Yaiza 3.0 Operating System running on a general PC;
+
+
+๏ญ a CleverCard SB2067 integrated circuit;
+
+
+๏ญ a CleverCard SB2067 IC running v2.0 of the QuickOS smart card
+operating system;
+
+
+๏ญ the December 2002 installation of the LAN of the Director-General's
+Office of the Department of Traffic.
+
+## **B.5 Conformance claims (APE_CCL)**
+
+
+462 This section of a PP describes how the PP conforms with other PPs and with
+packages. It is identical to the conformance claims section for an ST (see
+Section A.5), with one exception: the conformance statement.
+
+
+463 The conformance statement in the PP states how STs and/or other PPs must
+conform to that PP. The PP author selects whether โstrictโ or โdemonstrableโ
+conformance is required. See Annex D for more details on this.
+
+## **B.6 Security problem definition (APE_SPD)**
+
+
+464 This section is identical to the security problem definition section of an ST as
+explained in Section A.6.
+
+## **B.7 Security objectives (APE_OBJ)**
+
+
+465 This section is identical to the security objectives section of an ST as
+explained in Section A.7.
+
+## **B.8 Extended components definition (APE_ECD)**
+
+
+466 This section is identical to the extended components section of an ST as
+explained in Section A.8.
+
+## **B.9 Security requirements (APE_REQ)**
+
+
+467 This section is identical to the security requirements section of an ST as
+explained in Section A.9. Note however that the rules for completing
+operations in a PP are slightly different from the rules for completing
+operations in an ST. This is explained in more detail in Section 8.1.
+
+## **B.10 TOE summary specification**
+
+
+468 A PP has no TOE summary specification.
+
+## **B.11 Low assurance Protection Profiles**
+
+
+469 A low assurance PP has the same relationship to a regular PP (i.e., one with
+full contents), as a low assurance ST has to a regular ST. This means that a
+low-assurance PP consists of
+
+
+April 2017 Version 3.1 Page 89 of 106
+
+
+**Specification of Protection Profiles**
+
+
+a) a PP introduction, consisting of a PP reference and a TOE overview;
+
+
+b) a conformance claim;
+
+
+c) security objectives for the operational environment;
+
+
+d) the SFRs and the SARs (including the extended components
+definition) and the security requirements rationale (only if the
+dependencies are not satisfied).
+
+
+470 A low-assurance PP may only claim conformance to a low-assurance PP (see
+B.5). A regular PP may claim conformance with a low assurance PP.
+
+
+471 The reduced content of a low assurance PP is shown in Figure 10.
+
+
+**Figure 10 - Contents of a Low Assurance Protection Profile**
+
+## **B.12 Referring to other standards in a PP**
+
+
+472 This section is identical to the section on standards for STs as described in
+Section A.13, with one exception: as a PP has no TOE summary
+specification, the third option is not valid for PPs.
+
+
+473 The PP author is reminded that referring to a standard in SFRs may impose a
+significant burden on a developer developing a TOE to meet that PP
+(depending on the size and complexity of the standard and the assurance
+level required), and that it may be more suitable to require alternative (nonCC related) ways to assess conformance to that standard.
+
+
+Page 90 of 106 Version 3.1 April 2017
+
+
+**Specification of Protection Profiles**
+
+## **B.13 Interpretation of PP-Configuration as a standard PP**
+
+
+474 Once evaluated, a PP-Configuration can be refined and used in the same way
+as a standard Protection Profile. This chapter explains how to combine the
+content of the Base-PP(s) and PP-Module(s) of a PP-Configuration so as to
+interpret it as a standard PP.
+
+
+**B.13.1** **TOE type**
+
+
+475 The TOE type of a PP to interpret in the same way as the PP-Configuration
+would be constituted of the TOE type of the Base-PP(s) with the additions
+introduced in the PP-Module(s) TOE types. The evaluation of the PPConfiguration ensures that it forms a consistent TOE type.
+
+
+**B.13.2** **Conformance claims**
+
+
+476 The Conformance claims of a PP to interpret in the same way as the PPConfiguration would contain:
+
+
+๏ญ The conformance to the PP(s) whose conformance is claimed in the
+Base-PP(s).
+
+
+๏ญ The conformance to SAR packages (including predefined EAL) from
+the Base-PPs. The issue of ANDed Base-PPs with different EALs has
+to be dealt with like in an ST conformant to all those PPs (meaning
+that the ST has to claim the level of the minimum EAL of all the
+Base-PPs).
+
+
+๏ญ The conformance statement (strict or demonstrable) from the BasePPs. The issue of ANDed Base-PPs with different conformance
+statements has to be dealt with like in an ST conformant to all those
+PPs.
+
+
+**B.13.3** **Security problem definition**
+
+
+477 The SPD of a PP to interpret in the same way as the PP-Configuration would
+contain the union of the elements from the Base-PP(s) and PP-Module(s) of
+the PP-Configuration.
+
+
+**B.13.4** **Security objectives**
+
+
+478 The security objectives of a PP to interpret in the same way as the PPConfiguration would contain the union of the security objectives from the
+Base-PP(s) and PP-Module(s) of the PP-Configuration.
+
+
+**B.13.5** **Extended functional components definition**
+
+
+479 The extended functional components of a PP to interpret in the same way as
+the PP-Configuration would contain all extended functional components
+from the Base-PP(s) and PP-Module(s) of the PP-Configuration.
+
+
+April 2017 Version 3.1 Page 91 of 106
+
+
+**Specification of Protection Profiles**
+
+
+**B.13.6** **Security functional requirements**
+
+
+480 The set of SFRs of a PP to interpret in the same way as the PP-Configuration
+would contain:
+
+
+๏ญ all the SFRs from the PP-Module(s) of the PP-Configuration.
+
+
+๏ญ all the SFRs from the Base-PP(s) except those which are refined in
+the PP-Module(s).
+
+
+481 The consistency analysis performed on PP-Configuration during evaluation
+shall ensure this set is valid.
+
+## **B.14 Specification of PP-Modules**
+
+
+**B.14.1** **Mandatory content of a PP-Module**
+
+
+482 Figure 11 shows the mandatory content of a PP-Module.
+
+
+**Figure 11 - PP-Module content**
+
+
+483 The content of the PP-Module is summarized below and explained in detail
+in sections from B.14.3 to B.14.10. A PP-Module contains:
+
+
+๏ญ an _Introduction_ that identifies the PP-Module, identifies the BasePP(s) and states the correspondence rationale, and provides a
+description of the TOE within its environment that meets the
+descriptions underlying the Base-PPs,
+
+
+Page 92 of 106 Version 3.1 April 2017
+
+
+**Specification of Protection Profiles**
+
+
+๏ญ a _Consistency rationale_ that states the correspondence between the
+Module and its Base-PP(s),
+
+
+๏ญ a _Conformance claim_ regarding the CC, with inherited EAL and
+conformance statement,
+
+
+๏ญ a _Security problem definition_ with threats, assumptions and
+organisational security policies,
+
+
+๏ญ a _Security objectives_ section presenting the solution to the security
+problem in terms of objectives for the TOE and its operational
+environment,
+
+
+๏ญ an optional _Extended functional components definition_ where new
+functional components not included in CC Part 2 are introduced,
+
+
+๏ญ a _Security functional requirements_ section with a standardized
+statement of the TOE security objectives.
+
+
+**B.14.2** **Using the PP-Module**
+
+
+484 A PP-Module is a security statement of a group of users or developers,
+regulators, administration, or any other entity that meets specific consumer
+needs. A PP-Module complements one or more Base-PPs and allows
+consumers to refer to this statement, facilitates the evaluation against it and
+the comparison of conformant evaluated TOEs.
+
+
+**B.14.3** **PP-Module introduction**
+
+
+**B.14.3.1** PP-Module reference
+
+
+485 The PP-Module introduction provides a clear and unambiguous reference
+that allows identifying the PP-Module. A typical reference is made of the
+title of the PP-Module, its version, their authors and the publication date.
+
+
+486 The PP-Module reference will be used to index the document in Protection
+Profiles databases.
+
+
+**B.14.3.2** Base-PP identification
+
+
+487 The PP-Module introduction identifies the Base Protection Profile(s) the
+Module relies on. The identification consists of a list of PP references.
+
+
+488 The PP-Module may require to be used with a set of Base-PPs
+simultaneously, say {PP1,..., PPn}; the identification list states:
+
+
+489 The PP-Module may allow the use with alternative sets of Base-PPs, say
+{S1,..., Sk}; the identification list states:
+
+
+April 2017 Version 3.1 Page 93 of 106
+
+
+**Specification of Protection Profiles**
+
+
+490 The general form of the Base-PP identification is then
+
+
+491 Note that a PP-Module that states a list with an "OR" can be replaced by as
+many PP-Modules as elements in the list. That is, the list with an "OR" is a
+means to avoid managing similar PP-Modules for different usages, which
+does not introduce any complexity to the security specification itself.
+
+
+**B.14.3.3** TOE overview
+
+
+492 The _TOE overview_ of the PP-Module may complete the TOE overviews of
+the Base-PPs, provided the supplements do not contradict the Base-PPs:
+
+
+๏ญ The _TOE type_ of the PP-Module can be the same of the Base-PPs or
+introduce specificities that meet the purpose of the PP-Module.
+
+
+๏ญ The PP-Module can introduce additional _usage and major security_
+_features_ to those stated in the Base-PPs.
+
+
+๏ญ The PP-Module can specify particular _non-TOE hardware, software_
+_and/or firmware_ compliant with the statement in the Base-PPs.
+
+
+493 The possibility of supplementing the _TOE overview_ of one or more Base-PPs
+in a PP-Module has the same meaning as the supplements of a ST regarding
+the _TOE overview_ of a PP or the supplements of a PP that is conformant to
+another PP.
+
+
+494 The statement of the _TOE overview_ in a PP-Module is necessary whenever
+the TOE overview of the Base-PPs present different characteristics that need
+to be consolidated.
+
+
+495 The PP-Module may provide as many specific TOE overviews as alternative
+sets of Base-PPs.
+
+
+**B.14.4** **Consistency rationale**
+
+
+496 The PP-Module has to provide a consistency rationale with respect to its
+Base-PPs.
+
+
+497 If the PP-Module specifies alternative sets of Base-PPs, the PP-Module must
+provide as many conformance claims as the number of alternative set of
+Base-PPs.
+
+
+498 If the PP-Module specifies alternative sets of Base-PPs, the PP-Module must
+provide as many consistency rationales as the number of alternative set of
+Base-PPs.
+
+
+499 The consistency analysis must be performed on the TOE type, the SPD, the
+objectives and the security functional requirements. At the end, the goal is to
+
+
+Page 94 of 106 Version 3.1 April 2017
+
+
+**Specification of Protection Profiles**
+
+
+demonstrate that a TOE can meet the TOE type descriptions provided in the
+Base-PP(s) and in the PP-Module and that can satisfy all the Base-PPs and
+the PP-Module security functional requirements.
+
+
+500 The consistency rationale must demonstrate that the unions of the SPD, the
+objectives and the security functional requirements from the Base-PPs and
+from the PP-Module do not lead to a contradiction.
+
+
+501 The consistency rationale may use correspondence tables between
+SPD/objectives/SFRs in the PP-Module and SPD/objectives/SFRs in the
+Base-PPs together with textual justifications whenever needed.
+
+
+502 Note that the consistency at the SFR level implies the consistency of the
+union of objectives and the union of SPDs provided that the PP-Module does
+not change the assumptions and objectives for the environment of the BasePP(s).
+
+
+**B.14.5** **Conformance claims**
+
+
+503 This section describes how the PP-Module conforms to:
+
+
+๏ญ Part 2 of the Common Criteria: CC version and extended security
+requirements,
+
+
+๏ญ SFR packages.
+
+
+504 A PP-Module cannot claim conformance to any PP, PP-Module or PPConfiguration.
+
+
+505 A PP-Module inherits the conformity to SAR packages (including predefined
+EAL) from the Base-PPs. The issue of ANDed Base-PPs with different
+EALs has to be dealt with like in an ST conformant to all those PPs.
+
+
+506 A PP-Module inherits the conformance statement ( _strict_ or _demonstrable_ )
+from the Base-PPs. The issue of ANDed Base-PPs with different
+conformance statements has to be dealt with like in an ST conformant to all
+those PPs.
+
+
+**B.14.6** **Security problem definition**
+
+
+507 This section defines the security problem addressed by the PP-Module. It can
+contain assumptions, threats and organisational security policies.
+
+
+508 A PP-Module defines the security problem in relationship with the security
+problem of the Base-PPs and the definition of the TOE and its environment
+provided in the PP-Module's _Introduction_ .
+
+
+509 Each element of the SPD may either come from a Base-PP or be entirely new.
+Let E be an element of the SPD of a PP-Module, one of the following cases
+holds:
+
+
+April 2017 Version 3.1 Page 95 of 106
+
+
+**Specification of Protection Profiles**
+
+
+๏ญ E belongs to an identified Base-PP; the PP-Module may only contain
+a reference to the element in the Base-PP,
+
+
+๏ญ E results from the refinement of an element of a Base-PP,
+
+
+๏ญ E is a new element introduced by the PP-Module, related to
+additional features of the TOE or its environment.
+
+
+510 Note that the interpreted / refined elements can be dealt with as new elements
+without any impact on the meaning of the SPD.
+
+
+511 Note that as for STs, a PP-Module can introduce assumptions provided they
+cover aspects that are outside the scope of the Base-PPs.
+
+
+**B.14.7** **Security objectives**
+
+
+512 This section defines the security objectives for the TOE and for the TOE's
+operational environment
+
+
+513 A PP-Module defines the security objectives in relationship with its security
+problem and with the security objectives of the Base-PPs.
+
+
+514 Each security objective may either come from a Base-PP or be entirely new.
+Let O be an objective of a PP-Module, one of the following cases holds:
+
+
+๏ญ O belongs to an identified Base-PP; the PP-Module may only contain
+a reference to the objective in the Base-PP
+
+
+๏ญ O results from the refinement of an objective of the same kind (for
+the TOE or for the TOE operational environment) of a Base-PP,
+
+
+๏ญ O is a new objective introduced by the PP-Module.
+
+
+515 Note that the refined objectives can be dealt with as new objectives without
+any impact on the meaning of the whole set of objectives.
+
+
+516 As for STs, a PP-Module can introduce new objectives for the TOE
+operational environment only provided they address aspects that are outside
+the scope of the Base-PPs.
+
+
+517 In the opposite, if this is the purpose of the PP-Module, some security
+objectives for the environment of the Base-PPs could become security
+objectives for the TOE in the PP-Module.
+
+
+518 This section also defines the rationale between the SPD and the security
+objectives of the PP-Module, which consists of a mapping that traces the
+SPD of the PP-Module to their security objectives as well as a justification
+demonstrating that the tracing is effective, as specified in section B.7.
+Moreover, the mapping has to show not only that all the assumptions, threats
+and organisational security policies are covered but also that there is no
+useless security objective.
+
+
+Page 96 of 106 Version 3.1 April 2017
+
+
+**Specification of Protection Profiles**
+
+
+519 It may happen that some security objectives of the PP-Module cover also
+elements of the SPD of the Base-PPs that do not belong to the SPD of the
+PP-Module itself. This information is not required, but can be provided in
+application notes.
+
+
+**B.14.8** **Extended functional components definition**
+
+
+520 This section is identical to the standard PP and ST extended components
+section specified in section A.8, applied to functional components only.
+
+
+**B.14.9** **Security functional requirements**
+
+
+521 This section defines the security functional requirements for the TOE in
+relationship with the set of TOE security objectives in the PP-Module and
+with the security functional requirements of the Base-PPs.
+
+
+522 Each security functional requirement may either come from a Base-PP or be
+entirely new. Let R be a security functional requirement of a PP-Module, one
+of the following cases holds:
+
+
+๏ญ R belongs to an identified Base-PP; the PP-Module may only contain
+a reference to the requirement in the Base-PP,
+
+
+๏ญ R results from the refinement of a SFR of a Base-PPs,
+
+
+๏ญ R is a new requirement introduced by the PP-Module.
+
+
+523 Note that the refined requirements can be dealt with as new ones without any
+impact on the meaning of the whole set of requirements.
+
+
+524 This section also defines the rationale between the SFRs and the TOE
+security objectives of the PP-Module, which consists of a mapping that
+traces the TOE objectives of the PP-Module to one or more SFRs and a
+justification demonstrating that the tracing is effective, as specified in section
+B.9. Moreover, the mapping must fulfill the conditions specified in section
+B.14.10 and has to show not only that all the objectives for the TOE are
+covered but also that there is no useless security functional requirement.
+
+
+525 It may happen that some SFRs of the PP-Module cover also TOE security
+objectives of the Base-PPs that do not belong to the PP-Module itself. This
+information is not required, but can be provided in application notes.
+
+
+**B.14.10** **Guidance for inclusion of elements from Base-PP**
+
+
+526 In order to limit the amount of information contained in the PP-Module, the
+editor may apply the following rules.
+
+
+527 Let E, O and R belong to the SPD, the security objectives and the security
+functional requirements of a Protection Profile Q, respectively, with E
+mapped to O and O mapped to R.
+
+
+April 2017 Version 3.1 Page 97 of 106
+
+
+**Specification of Protection Profiles**
+
+
+528 Let P be a PP-Module with Q amongst its Base-PPs. P has to satisfy the
+following condition:
+
+
+529 E, O, R and the mappings between them may belong to P only if at least one
+of these elements is linked to a new element in P, that is
+
+
+๏ญ Either there is a new element E' in the SPD of P such that E' is
+mapped to O, or
+
+
+๏ญ There is a new objective O' in P such that E is mapped to O' or O' is
+mapped to R, or
+
+
+๏ญ There is a new requirement R' in P such that O is mapped to R'.
+
+
+530 That is, a PP-Module would not contain portions of Base-PPs unless they are
+required to fulfill new needs. Here, refined elements are considered new.
+
+## **B.15 Specification of PP-Configurations**
+
+
+**B.15.1** **Mandatory content of a PP-Configuration**
+
+
+531 The content of the PP-Configuration is summarized below and explained in
+detail in Annexes B.15.3, B.15.4, B.15.5 and B.15.6. A PP-Configuration
+contains:
+
+
+๏ญ a _Reference_ that identifies the PP-Configuration,
+
+
+๏ญ a _Components statement_ that identifies the Base-PPs and the PPModules composing the PP-Configuration,
+
+
+๏ญ a _Conformance statement_, that specifies whether the conformance to
+this PP-Configuration has to be strict or demonstrable,
+
+
+๏ญ a _SAR statement_, specifying the EAL, SAR package or list of the
+selected assurance components applicable to the PP-Configuration.
+
+
+**B.15.2** **Using the PP-Configuration**
+
+
+532 PP-Configurations are security statements that cover specific needs of groups
+of users, consumers, organisations, etc. Any PP-Configuration can be used
+exactly as a standard Protection Profile, as explained in Section B.13.
+
+
+**B.15.3** **PP-Configuration reference**
+
+
+533 The PP-Configuration reference provides a clear and unambiguous
+identification, usually made of a title, version number, sponsor and the
+publication date.
+
+
+534 The PP-Configuration reference will be used to index the document in
+Protection Profiles databases.
+
+
+Page 98 of 106 Version 3.1 April 2017
+
+
+**Specification of Protection Profiles**
+
+
+**B.15.4** **PP-Configuration components statement**
+
+
+535 The _Components statement_ identifies the Base-PPs and the PP-Modules that
+compose the PP-Configuration.
+
+
+536 The _Components statement_ must include at least all Base-PPs referenced in
+the PP-Modules. If the PP-Module specifies alternative sets of Base-PPs,
+only one of these sets must be referred to in the PP-Configuration.
+
+
+**B.15.5** **PP-Configuration conformance statement**
+
+
+537 The _Conformance statement_ specifies whether the conformance to this PPConfiguration has to be strict or demonstrable.
+
+
+538 Any ST that claims conformance to the PP-Configuration shall conform to
+the kind of conformance claimed in the PP-Configuration.
+
+
+**B.15.6** **PP-Configuration SAR statement**
+
+
+539 The _SAR statement_ specifies the set of SAR (potentially predefined EAL)
+applicable to any product evaluation with a ST that claims conformance to
+this PP-Configuration.
+
+
+**B.15.7** **Evaluation of a PP-Configuration**
+
+
+540 The assurance components for PP-Configuration evaluation, defined in
+Chapter 11: Class ACE of CC Part 3, are the following: ACE_INT.1,
+ACE_CCL.1, ACE_SPD.1, ACE_ECD.1, ACE_OBJ.1, ACE_REQ.1,
+ACE_MCO.1 and ACE_CCO.1.
+
+
+April 2017 Version 3.1 Page 99 of 106
+
+
+**Guidance for Operations**
+
+# **C Guidance for Operations** **(informative)**
+
+## **C.1 Introduction**
+
+
+541 As described in this CC part 1, Protection Profiles and Security Targets
+contain pre-defined security requirements, as well as providing PP and ST
+authors the ability to extend the component lists in some circumstances.
+
+## **C.2 Examples of operations**
+
+
+542 The four types of operations are given in section 8.1. Examples of the
+various operations are described below:
+
+
+**C.2.1** **The iteration operation**
+
+
+543 As described in section 8.1.1 the iteration operation may be performed on
+every component. The PP/ST author performs an iteration operation by
+including multiple requirements based on the same component. Each
+iteration of a component is different from all other iterations of that
+component, which is realised by completing assignments and selections in a
+different way, or by applying refinements to it in a different way. Different
+iterations should be uniquely identified to allow clear rationales and tracings
+to and from these requirements.
+
+
+544 A typical example of an iteration is FCS_COP.1 Cryptographic operation
+being iterated twice in order to require the implementation of two different
+cryptographic algorithms. An example of each iteration being uniquely
+identified is:
+
+
+๏ญ Cryptographic operation (RSA and DSA signatures) (FCS_COP.1(1))
+
+
+๏ญ Cryptographic operation (TLS/SSL: symmetric operations)
+(FCS_COP.1(2))
+
+
+**C.2.2** **The assignment operation**
+
+
+545 As described in section 8.1.2 an assignment operation occurs where a given
+component contains an element with a parameter that may be set by the
+PP/ST author. The parameter may be an unrestricted variable, or a rule that
+narrows the variable to a specific range of values.
+
+
+546 An example of an element with an assignment is: FIA_AFL.1.2 โWhen the
+defined number of unsuccessful authentication attempts has been met or
+surpassed, the TSF shall **[assignment: list of actions]** .โ
+
+
+Page 100 of 106 Version 3.1 April 2017
+
+
+**Guidance for Operations**
+
+
+**C.2.3** **The selection operation**
+
+
+547 As described in section 8.1.3 the selection operation occurs where a given
+component contains an element where a choice from several items has to be
+made by the PP/ST author.
+
+
+548 An example of an element with a selection is: FPT_TST.1.1 โThe TSF shall
+run a suite of self tests [selection: during initial start-up, periodically during
+normal operation, at the request of the authorised user, at the conditions
+
+[assignment: conditions under which self test should occur]] to demonstrate
+the correct operation of ...โ
+
+
+**C.2.4** **The refinement operation**
+
+
+549 As described in section 8.1.4 the refinement operation can be performed on
+every requirement. The PP/ST author performs a refinement by altering that
+requirement.
+
+
+550 An example of a valid refinement is FIA_UAU.2.1 โThe TSF shall require
+each user to be successfully authenticated before allowing any other TSFmediated actions on behalf of that user.โ being refined to โThe TSF shall
+require each user to be successfully authenticated **by username/password**
+before allowing any other TSF-mediated actions on behalf of that user.โ
+
+
+551 The first rule for a refinement is that a TOE meeting the refined requirement
+also meets the unrefined requirement in the context of the PP/ST (i.e. a
+refined requirement must be โstricterโ than the original requirement)
+
+
+552 The only exception to this rule is that a PP/ST author is allowed to refine a
+SFR to apply to some but not all subjects, objects, operations, security
+attributes and/or external entities.
+
+
+553 An example of a such an exception is FIA_UAU.2.1 โThe TSF shall require
+each user to be successfully authenticated before allowing any other TSFmediated actions on behalf of that user.โ being refined to โThe TSF shall
+require each user **originating from the internet** to be successfully
+authenticated before allowing any other TSF-mediated actions on behalf of
+that user.โ
+
+
+554 The second rule for a refinement given is that the refinement shall be related
+to the original component. For example, refining an audit component with an
+extra element on prevention of electromagnetic radiation is not allowed.
+
+
+555 A special case of refinement is an editorial refinement, where a small change
+is made in a requirement, i.e. rephrasing a sentence due to adherence to
+proper English grammar, or to make it more understandable to the reader.
+This change is not allowed to modify the meaning of the requirement in any
+way. Examples of editorial refinements include:
+
+
+๏ญ the SFR FPT_FLS.1 โThe TSF shall continue to preserve a secure
+state when the following failures occur: **breakdown of one CPU** โ
+
+
+April 2017 Version 3.1 Page 101 of 106
+
+
+**Guidance for Operations**
+
+
+could be refined to FPT_FLS.1 โThe TSF shall continue to preserve a
+secure state when the following failure occurs: **breakdown of one**
+**CPU** โ or even FPT_FLS.1 โThe TSF shall continue to preserve a
+secure state when **one CPU breaks down** โ.
+
+## **C.3 Organisation of components**
+
+
+556 The CC has organised the components in CC Part 2 and CC Part 3 into
+hierarchical structures:
+
+
+๏ญ Classes, consisting of
+
+
+๏ญ Families, consisting of
+
+
+๏ญ Components, consisting of
+
+
+๏ญ Elements.
+
+
+557 This organisation into a hierarchy of class - family - component - element is
+provided to assist consumers, developers and evaluators in locating specific
+components.
+
+
+558 The CC presents functional and assurance components in the same general
+hierarchical style and use the same organisation and terminology for each.
+
+
+**C.3.1** **Class**
+
+
+559 An example of a class is the FIA: Identification and authentication class that
+is focused at identification of users, authentication of users and binding of
+users and subjects.
+
+
+**C.3.2** **Family**
+
+
+560 An example of a family is the User authentication (FIA_UAU) family which
+is part of the FIA: Identification and authentication class. This family
+concentrates on the authentication of users.
+
+
+**C.3.3** **Component**
+
+
+561 An example of a component is FIA_UAU.3 Unforgeable authentication
+which concentrates on unforgeable authentication.
+
+
+**C.3.4** **Element**
+
+
+562 An example of an element is FIA_UAU.3.2 which concentrates on the
+prevention of use of copied authentication data.
+
+
+Page 102 of 106 Version 3.1 April 2017
+
+
+**Guidance for Operations**
+
+## **C.4 Extended components**
+
+
+**C.4.1** **How to define extended components**
+
+
+563 Whenever a PP/ST author defines an extended component, this has to be
+done in a similar manner to the existing CC components: clear, unambiguous
+and evaluatable (it is possible to systematically demonstrate whether a
+requirement based on that component holds for a TOE). Extended
+components must use similar labelling, manner of expression, and level of
+detail as the existing CC components.
+
+
+564 The PP/ST author also has to make to sure that all applicable dependencies
+of an extended component are included in the definition of that extended
+component. Examples of possible dependencies are:
+
+
+a) if an extended component refers to auditing, dependencies to
+components of the FAU: Security audit class may have to be
+included;
+
+
+b) if an extended component modifies or accesses data, dependencies to
+components of the Access control policy (FDP_ACC) family may
+have to be included;
+
+
+c) if an extended component uses a particular design description a
+dependency to the appropriate ADV: Development family (e.g.
+Functional Specification) may have to be included.
+
+
+565 In the case of an extended functional component, the PP/ST author also has
+to include any applicable audit and associated operations information in the
+definition of that component, similar to existing CC Part 2 components. In
+the case of an extended assurance component, the PP/ST author also has to
+provide suitable evaluation methodology for the component, similar to the
+methodology provided in the CEM.
+
+
+566 Extended components may be placed in existing families, in which case the
+PP/ST writer has to show how these families change. If they do not fit into
+an existing family, they shall be placed in a new family. New families have
+to be defined similarly to the CC.
+
+
+567 New families may be placed in existing classes in which case the PP/ST
+writer has to show how these classes change. If they do not fit into an
+existing class, they shall be placed in a new class. New classes have to be
+defined similarly to the CC.
+
+
+April 2017 Version 3.1 Page 103 of 106
+
+
+**PP conformance**
+
+# **D PP conformance** **(informative)**
+
+## **D.1 Introduction**
+
+
+568 A PP is intended to be used as a โtemplateโ for an ST. That is: the PP
+describes a set of user needs, while an ST that conforms to that PP describes
+a TOE that satisfies those needs.
+
+
+569 Note that it is also possible for a PP to be used as a template for another PP.
+That is PPs can claim conformance to other PPs. This case is completely
+similar to that of an ST vs. a PP. For clarity this Annex describes only the
+ST/PP case, but it holds also for the PP/PP case.
+
+
+570 The CC does not allow any form of partial conformance, so if a PP is
+claimed, the PP or ST must fully conform to the referenced PP or PPs. There
+are however two types of conformance (โstrictโ and demonstrableโ) and the
+type of conformance allowed is determined by the PP. That is, the PP states
+(in the PP conformance statement, see section B.5) what the allowed types of
+conformance for the ST are. This distinction between strict and demonstrable
+conformance is applicable to each PP to which an ST may claim
+conformance on an individual basis. This may mean that the ST conforms
+strictly to some PPs and demonstrably to other PPs. An ST is only allowed to
+conform to a PP in a demonstrable manner, if the PP explicitly allows this,
+whereas an ST can always conform with strict conformance to any PP.
+
+
+571 Restating this in other words, an ST is only allowed to conform to a PP in a
+demonstrable manner, if the PP explicitly allows this.
+
+
+572 Conformance to a PP means that the PP or ST (and if an ST is of an
+evaluated product, the product as well) meets all requirements of that PP.
+
+
+573 Published PPs will normally require demonstrable conformance. This means
+that STs claiming conformance with the PP must offer a solution to the
+generic security problem described in the PP, but can do so in any way that is
+equivalent or more restrictive to that described in the PP. โEquivalent but
+more restrictiveโ is defined at length within the CC, but in principle it means
+that the PP and ST may contain entirely different statements that discuss
+different entities, use different concepts etc., provided that overall the ST
+levies the same or more restrictions on the TOE, and the same or less
+restrictions on the operational environment of the TOE.
+
+## **D.2 Strict conformance**
+
+
+574 Strict conformance is oriented to the PP-author who requires evidence that
+the requirements in the PP are met, that the ST is an instantiation of the PP,
+though the ST could be broader than the PP. In essence, the ST specifies that
+
+
+Page 104 of 106 Version 3.1 April 2017
+
+
+**PP conformance**
+
+
+the TOE does at least the same as in the PP, while the operational
+environment does at most the same as in the PP.
+
+
+575 A typical example of the use of strict conformance is in selection based
+purchasing where a product's security requirements are expected to exactly
+match those specified in the PP.
+
+
+576 An ST instantiating strict conformance to a PP can still introduce additional
+restrictions to those given in the PP.
+
+## **D.3 Demonstrable conformance**
+
+
+577 Demonstrable conformance is orientated to the PP-author who requires
+evidence that the ST is a suitable solution to the generic security problem
+described in the PP.
+
+
+578 Where there is a clear subset-superset type relation between PP and ST in the
+case of strict conformance, the relation is less clear-cut in the case of
+demonstrable conformance. STs claiming conformance with the PP must
+offer a solution to the generic security problem described in the PP. but can
+do so in any way that is equivalent or more restrictive to that described in the
+PP.
+
+
+April 2017 Version 3.1 Page 105 of 106
+
+
+**Bibliography**
+
+# **E Bibliography** **(informative)**
+
+
+579 This bibliography contains references to further material and standards that
+the reader of the CC may find useful. For undated references the reader is
+recommended to refer to the latest edition of the referenced document.
+
+## **E.1 ISO/IEC standards and guidance**
+
+
+[ISO/IEC 15292] Information technology -- Security techniques -Protection Profile registration procedures
+
+
+[ISO/IEC 15443] Information technology -- Security techniques -- A
+framework for IT security assurance - all parts
+
+
+[ISO/IEC 15446] Information technology -- Security techniques -Guide for the production of Protection Profiles and
+Security Targets
+
+
+[ISO/IEC 19790] Information technology -- Security techniques -Security requirements for cryptographic modules
+
+
+[ISO/IEC 19791] Information technology -- Security techniques -Security assessment of operational systems
+
+
+[ISO/IEC 27001] Information technology -- Security techniques -Information security management systems -Requirements
+
+
+[ISO/IEC 27002] Information technology -- Security techniques -- Code
+of practice for information security management
+
+## **E.2 Other standards and guidance**
+
+
+[IEEE Std 610.12-1990] Institute of Electrical and Electronics
+Engineers, Standard Glossary of Software Engineering
+Terminology
+
+
+[CC portal] Common Criteria portal, February 2009. CCRA,
+www.commoncriteriaportal.org
+
+
+Page 106 of 106 Version 3.1 April 2017
+
+
+
diff --git a/niap-cc/sdp-file-encrypt/doc/knowledge_base/CCPART2V3.1R5.md b/niap-cc/sdp-file-encrypt/doc/knowledge_base/CCPART2V3.1R5.md
new file mode 100644
index 0000000..880bcba
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/doc/knowledge_base/CCPART2V3.1R5.md
@@ -0,0 +1,18510 @@
+Consider using the pymupdf_layout package for a greatly improved page layout analysis.
+# **Foreword**
+
+This version of the Common Criteria for Information Technology Security Evaluation (CC
+v3.1) is the first major revision since being published as CC v2.3 in 2005.
+
+CC v3.1 aims to: eliminate redundant evaluation activities; reduce/eliminate activities that
+contribute little to the final assurance of a product; clarify CC terminology to reduce
+misunderstanding; restructure and refocus the evaluation activities to those areas where
+security assurance is gained; and add new CC requirements if needed.
+
+CC version 3.1 consists of the following parts:
+
+
+๏ญ Part 1: Introduction and general model
+
+
+๏ญ Part 2: Security functional components
+
+
+๏ญ Part 3: Security assurance components
+
+
+_**Trademarks:**_
+
+
+๏ญ UNIX is a registered trademark of The Open Group in the United States and other
+countries
+
+
+๏ญ Windows is a registered trademark of Microsoft Corporation in the United States
+and other countries
+
+
+Page 2 of 323 Version 3.1 April 2017
+
+
+_**Legal Notice:**_
+
+_The governmental organisations listed below contributed to the development of this version_
+_of the Common Criteria for Information Technology Security Evaluation. As the joint_
+_holders of the copyright in the Common Criteria for Information Technology Security_
+_Evaluation, version_ 3.1 _Parts 1 through 3 (called โCC_ 3.1 _โ), they hereby grant non-_
+_exclusive license to ISO/IEC to use CC_ 3.1 _in the continued development/maintenance of the_
+_ISO/IEC 15408 international standard. However, these governmental organisations retain_
+_the right to use, copy, distribute, translate or modify CC_ 3.1 _as they see fit._
+
+_Australia:_ _The Australian Signals Directorate;_
+_Canada:_ _Communications Security Establishment;_
+_France:_ _Agence Nationale de la Sรฉcuritรฉ des Systรจmes d'Information;_
+_Germany:_ _Bundesamt fรผr Sicherheit in der Informationstechnik;_
+_Japan:_ _Information Technology Promotion Agency;_
+_Netherlands:_ _Netherlands National Communications Security Agency;_
+_New Zealand:_ _Government Communications Security Bureau;_
+_Republic of Korea:_ _National Security Research Institute;_
+_Spain:_ _Ministerio de Administraciones Pรบblicas and_
+_Centro Criptolรณgico Nacional;_
+_Sweden:_ _Swedish Defence Materiel Administration;_
+_United Kingdom:_ _National Cyber Security Centre;_
+_United States:_ _The National Security Agency and the_
+_National Institute of Standards and Technology._
+
+
+April 2017 Version 3.1 Page 3 of 323
+
+
+**Table of contents**
+
+# **Table of Contents**
+
+
+**1** **INTRODUCTION ............................................................................................. 13**
+
+
+**2** **SCOPE ........................................................................................................... 14**
+
+
+**3** **NORMATIVE REFERENCES ......................................................................... 15**
+
+
+**4** **TERMS AND DEFINITIONS, SYMBOLS AND ABBREVIATED TERMS ...... 16**
+
+
+**5** **OVERVIEW ..................................................................................................... 17**
+
+
+**5.1** **Organisation of CC Part 2 ..................................................................................................................... 17**
+
+
+**6** **FUNCTIONAL REQUIREMENTS PARADIGM ............................................... 18**
+
+
+**7** **SECURITY FUNCTIONAL COMPONENTS ................................................... 23**
+
+
+**7.1** **Overview ................................................................................................................................................. 23**
+7.1.1 Class structure ................................................................................................................................ 23
+7.1.2 Family structure .............................................................................................................................. 24
+7.1.3 Component structure....................................................................................................................... 25
+
+
+**7.2** **Component catalogue............................................................................................................................. 27**
+7.2.1 Component changes highlighting ................................................................................................... 28
+
+
+**8** **CLASS FAU: SECURITY AUDIT ................................................................... 29**
+
+
+**8.1** **Security audit automatic response (FAU_ARP) .................................................................................. 30**
+
+
+**8.2** **Security audit data generation (FAU_GEN) ........................................................................................ 31**
+
+
+**8.3** **Security audit analysis (FAU_SAA) ..................................................................................................... 33**
+
+
+**8.4** **Security audit review (FAU_SAR) ........................................................................................................ 37**
+
+
+**8.5** **Security audit event selection (FAU_SEL) ........................................................................................... 39**
+
+
+**8.6** **Security audit event storage (FAU_STG) ............................................................................................ 40**
+
+
+**9** **CLASS FCO: COMMUNICATION .................................................................. 43**
+
+
+**9.1** **Non-repudiation of origin (FCO_NRO) ............................................................................................... 44**
+
+
+**9.2** **Non-repudiation of receipt (FCO_NRR) .............................................................................................. 46**
+
+
+**10** **CLASS FCS: CRYPTOGRAPHIC SUPPORT ................................................ 48**
+
+
+**10.1** **Cryptographic key management (FCS_CKM) ............................................................................... 49**
+
+
+**10.2** **Cryptographic operation (FCS_COP) ............................................................................................. 52**
+
+
+Page 4 of 323 Version 3.1 April 2017
+
+
+**Table of contents**
+
+
+**11** **CLASS FDP: USER DATA PROTECTION .................................................... 54**
+
+
+**11.1** **Access control policy (FDP_ACC) ................................................................................................... 57**
+
+
+**11.2** **Access control functions (FDP_ACF) .............................................................................................. 59**
+
+
+**11.3** **Data authentication (FDP_DAU) ..................................................................................................... 61**
+
+
+**11.4** **Export from the TOE (FDP_ETC) .................................................................................................. 63**
+
+
+**11.5** **Information flow control policy (FDP_IFC) ................................................................................... 65**
+
+
+**11.6** **Information flow control functions (FDP_IFF) .............................................................................. 67**
+
+
+**11.7** **Import from outside of the TOE (FDP_ITC) .................................................................................. 72**
+
+
+**11.8** **Internal TOE transfer (FDP_ITT) ................................................................................................... 74**
+
+
+**11.9** **Residual information protection (FDP_RIP) .................................................................................. 77**
+
+
+**11.10** **Rollback (FDP_ROL) ........................................................................................................................ 79**
+
+
+**11.11** **Stored data integrity (FDP_SDI) ...................................................................................................... 81**
+
+
+**11.12** **Inter-TSF user data confidentiality transfer protection (FDP_UCT) ........................................... 83**
+
+
+**11.13** **Inter-TSF user data integrity transfer protection (FDP_UIT) ...................................................... 84**
+
+
+**12** **CLASS FIA: IDENTIFICATION AND AUTHENTICATION ............................. 87**
+
+
+**12.1** **Authentication failures (FIA_AFL) ................................................................................................. 89**
+
+
+**12.2** **User attribute definition (FIA_ATD) ............................................................................................... 91**
+
+
+**12.3** **Specification of secrets (FIA_SOS) .................................................................................................. 92**
+
+
+**12.4** **User authentication (FIA_UAU) ...................................................................................................... 94**
+
+
+**12.5** **User identification (FIA_UID) .......................................................................................................... 99**
+
+
+**12.6** **User-subject binding (FIA_USB) ................................................................................................... 101**
+
+
+**13** **CLASS FMT: SECURITY MANAGEMENT .................................................. 103**
+
+
+**13.1** **Management of functions in TSF (FMT_MOF) ........................................................................... 105**
+
+
+**13.2** **Management of security attributes (FMT_MSA) ......................................................................... 106**
+
+
+**13.3** **Management of TSF data (FMT_MTD) ........................................................................................ 110**
+
+
+**13.4** **Revocation (FMT_REV) ................................................................................................................. 113**
+
+
+**13.5** **Security attribute expiration (FMT_SAE) .................................................................................... 114**
+
+
+**13.6** **Specification of Management Functions (FMT_SMF) ................................................................. 115**
+
+
+**13.7** **Security management roles (FMT_SMR) ..................................................................................... 116**
+
+
+April 2017 Version 3.1 Page 5 of 323
+
+
+**Table of contents**
+
+
+**14** **CLASS FPR: PRIVACY ................................................................................ 118**
+
+
+**14.1** **Anonymity (FPR_ANO) .................................................................................................................. 119**
+
+
+**14.2** **Pseudonymity (FPR_PSE) .............................................................................................................. 121**
+
+
+**14.3** **Unlinkability (FPR_UNL) .............................................................................................................. 123**
+
+
+**14.4** **Unobservability (FPR_UNO) ......................................................................................................... 124**
+
+
+**15** **CLASS FPT: PROTECTION OF THE TSF ................................................... 127**
+
+
+**15.1** **Fail secure (FPT_FLS) .................................................................................................................... 129**
+
+
+**15.2** **Availability of exported TSF data (FPT_ITA) .............................................................................. 130**
+
+
+**15.3** **Confidentiality of exported TSF data (FPT_ITC) ........................................................................ 131**
+
+
+**15.4** **Integrity of exported TSF data (FPT_ITI) .................................................................................... 132**
+
+
+**15.5** **Internal TOE TSF data transfer (FPT_ITT) ................................................................................ 134**
+
+
+**15.6** **TSF physical protection (FPT_PHP) ............................................................................................. 137**
+
+
+**15.7** **Trusted recovery (FPT_RCV) ........................................................................................................ 140**
+
+
+**15.8** **Replay detection (FPT_RPL) ......................................................................................................... 143**
+
+
+**15.9** **State synchrony protocol (FPT_SSP) ............................................................................................ 144**
+
+
+**15.10** **Time stamps (FPT_STM) ............................................................................................................... 146**
+
+
+**15.11** **Inter-TSF TSF data consistency (FPT_TDC) ............................................................................... 147**
+
+
+**15.12** **Testing of external entities (FPT_TEE) ......................................................................................... 148**
+
+
+**15.13** **Internal TOE TSF data replication consistency (FPT_TRC) ...................................................... 150**
+
+
+**15.14** **TSF self test (FPT_TST) ................................................................................................................. 151**
+
+
+**16** **CLASS FRU: RESOURCE UTILISATION .................................................... 153**
+
+
+**16.1** **Fault tolerance (FRU_FLT) ........................................................................................................... 154**
+
+
+**16.2** **Priority of service (FRU_PRS) ....................................................................................................... 156**
+
+
+**16.3** **Resource allocation (FRU_RSA) .................................................................................................... 158**
+
+
+**17** **CLASS FTA: TOE ACCESS......................................................................... 160**
+
+
+**17.1** **Limitation on scope of selectable attributes (FTA_LSA) ............................................................. 161**
+
+
+**17.2** **Limitation on multiple concurrent sessions (FTA_MCS) ............................................................ 162**
+
+
+**17.3** **Session locking and termination (FTA_SSL) ................................................................................ 164**
+
+
+**17.4** **TOE access banners (FTA_TAB) ................................................................................................... 167**
+
+
+Page 6 of 323 Version 3.1 April 2017
+
+
+**Table of contents**
+
+
+**17.5** **TOE access history (FTA_TAH) .................................................................................................... 168**
+
+
+**17.6** **TOE session establishment (FTA_TSE) ........................................................................................ 169**
+
+
+**18** **CLASS FTP: TRUSTED PATH/CHANNELS ............................................... 170**
+
+
+**18.1** **Inter-TSF trusted channel (FTP_ITC) .......................................................................................... 171**
+
+
+**18.2** **Trusted path (FTP_TRP) ................................................................................................................ 173**
+
+
+**A** **SECURITY FUNCTIONAL REQUIREMENTS APPLICATION NOTES ....... 175**
+
+
+**A.1** **Structure of the notes ...................................................................................................................... 175**
+A.1.1 Class structure ............................................................................................................................... 175
+A.1.2 Family structure ............................................................................................................................ 176
+A.1.3 Component structure ..................................................................................................................... 176
+
+
+**A.2** **Dependency tables ........................................................................................................................... 177**
+
+
+**B** **FUNCTIONAL CLASSES, FAMILIES, AND COMPONENTS ...................... 184**
+
+
+**C** **CLASS FAU: SECURITY AUDIT ................................................................. 185**
+
+
+**C.1** **Audit requirements in a distributed environment ........................................................................ 185**
+
+
+**C.2** **Security audit automatic response (FAU_ARP) ........................................................................... 186**
+
+
+**C.3** **Security audit data generation (FAU_GEN) ................................................................................. 187**
+
+
+**C.4** **Security audit analysis (FAU_SAA) ............................................................................................... 190**
+
+
+**C.5** **Security audit review (FAU_SAR) ................................................................................................. 195**
+
+
+**C.6** **Security audit event selection (FAU_SEL) .................................................................................... 197**
+
+
+**C.7** **Security audit event storage (FAU_STG) ...................................................................................... 198**
+
+
+**D** **CLASS FCO: COMMUNICATION ................................................................ 201**
+
+
+**D.1** **Non-repudiation of origin (FCO_NRO) ........................................................................................ 201**
+
+
+**D.2** **Non-repudiation of receipt (FCO_NRR) ....................................................................................... 204**
+
+
+**E** **CLASS FCS: CRYPTOGRAPHIC SUPPORT .............................................. 207**
+
+
+**E.1** **Cryptographic key management (FCS_CKM) ............................................................................. 208**
+
+
+**E.2** **Cryptographic operation (FCS_COP) ........................................................................................... 211**
+
+
+**F** **CLASS FDP: USER DATA PROTECTION .................................................. 213**
+
+
+**F.1** **Access control policy (FDP_ACC) ...................................................................................................... 216**
+
+
+**F.2** **Access control functions (FDP_ACF) ................................................................................................. 219**
+
+
+April 2017 Version 3.1 Page 7 of 323
+
+
+**Table of contents**
+
+
+**F.3** **Data authentication (FDP_DAU) ........................................................................................................ 221**
+
+
+**F.4** **Export from the TOE (FDP_ETC) ..................................................................................................... 222**
+
+
+**F.5** **Information flow control policy (FDP_IFC) ...................................................................................... 224**
+
+
+**F.6** **Information flow control functions (FDP_IFF) ................................................................................. 226**
+
+
+**F.7** **Import from outside of the TOE (FDP_ITC) .................................................................................... 232**
+
+
+**F.8** **Internal TOE transfer (FDP_ITT) ..................................................................................................... 235**
+
+
+**F.9** **Residual information protection (FDP_RIP) ..................................................................................... 238**
+
+
+**F.10** **Rollback (FDP_ROL)...................................................................................................................... 240**
+
+
+**F.11** **Stored data integrity (FDP_SDI) ................................................................................................... 242**
+
+
+**F.12** **Inter-TSF user data confidentiality transfer protection (FDP_UCT) ........................................ 243**
+
+
+**F.13** **Inter-TSF user data integrity transfer protection (FDP_UIT) .................................................... 244**
+
+
+**G** **CLASS FIA: IDENTIFICATION AND AUTHENTICATION ........................... 247**
+
+
+**G.1** **Authentication failures (FIA_AFL) ............................................................................................... 248**
+
+
+**G.2** **User attribute definition (FIA_ATD) ............................................................................................. 250**
+
+
+**G.3** **Specification of secrets (FIA_SOS) ................................................................................................ 251**
+
+
+**G.4** **User authentication (FIA_UAU) .................................................................................................... 252**
+
+
+**G.5** **User identification (FIA_UID)........................................................................................................ 256**
+
+
+**G.6** **User-subject binding (FIA_USB) ................................................................................................... 257**
+
+
+**H** **CLASS FMT: SECURITY MANAGEMENT .................................................. 259**
+
+
+**H.1** **Management of functions in TSF (FMT_MOF) ........................................................................... 260**
+
+
+**H.2** **Management of security attributes (FMT_MSA) ......................................................................... 262**
+
+
+**H.3** **Management of TSF data (FMT_MTD) ........................................................................................ 265**
+
+
+**H.4** **Revocation (FMT_REV) ................................................................................................................. 266**
+
+
+**H.5** **Security attribute expiration (FMT_SAE) .................................................................................... 267**
+
+
+**H.6** **Specification of Management Functions (FMT_SMF) ................................................................. 268**
+
+
+**H.7** **Security management roles (FMT_SMR) ..................................................................................... 269**
+
+
+**I** **CLASS FPR: PRIVACY ................................................................................ 271**
+
+
+**I.1** **Anonymity (FPR_ANO) ...................................................................................................................... 272**
+
+
+**I.2** **Pseudonymity (FPR_PSE) ................................................................................................................... 274**
+
+
+Page 8 of 323 Version 3.1 April 2017
+
+
+**Table of contents**
+
+
+**I.3** **Unlinkability (FPR_UNL) ................................................................................................................... 279**
+
+
+**I.4** **Unobservability (FPR_UNO) .............................................................................................................. 281**
+
+
+**J** **CLASS FPT: PROTECTION OF THE TSF ................................................... 285**
+
+
+**J.1** **Fail secure (FPT_FLS) ......................................................................................................................... 287**
+
+
+**J.2** **Availability of exported TSF data (FPT_ITA)................................................................................... 288**
+
+
+**J.3** **Confidentiality of exported TSF data (FPT_ITC) ............................................................................. 289**
+
+
+**J.4** **Integrity of exported TSF data (FPT_ITI) ......................................................................................... 289**
+
+
+**J.5** **Internal TOE TSF data transfer (FPT_ITT) ..................................................................................... 291**
+
+
+**J.6** **TSF physical protection (FPT_PHP) .................................................................................................. 292**
+
+
+**J.7** **Trusted recovery (FPT_RCV) ............................................................................................................. 294**
+
+
+**J.8** **Replay detection (FPT_RPL) .............................................................................................................. 299**
+
+
+**J.9** **State synchrony protocol (FPT_SSP) ................................................................................................. 299**
+
+
+**J.10** **Time stamps (FPT_STM) ............................................................................................................... 300**
+
+
+**J.11** **Inter-TSF TSF data consistency (FPT_TDC) ............................................................................... 301**
+
+
+**J.12** **Testing of external entities (FPT_TEE) ......................................................................................... 302**
+
+
+**J.13** **Internal TOE TSF data replication consistency (FPT_TRC) ...................................................... 303**
+
+
+**J.14** **TSF self test (FPT_TST) ................................................................................................................. 304**
+
+
+**K** **CLASS FRU: RESOURCE UTILISATION.................................................... 307**
+
+
+**K.1** **Fault tolerance (FRU_FLT) ............................................................................................................ 307**
+
+
+**K.2** **Priority of service (FRU_PRS) ....................................................................................................... 309**
+
+
+**K.3** **Resource allocation (FRU_RSA) .................................................................................................... 310**
+
+
+**L** **CLASS FTA: TOE ACCESS ........................................................................ 313**
+
+
+**L.1** **Limitation on scope of selectable attributes (FTA_LSA) ............................................................. 314**
+
+
+**L.2** **Limitation on multiple concurrent sessions (FTA_MCS) ............................................................ 315**
+
+
+**L.3** **Session locking and termination (FTA_SSL) ................................................................................ 316**
+
+
+**L.4** **TOE access banners (FTA_TAB) ................................................................................................... 318**
+
+
+**L.5** **TOE access history (FTA_TAH) .................................................................................................... 318**
+
+
+**L.6** **TOE session establishment (FTA_TSE) ........................................................................................ 319**
+
+
+April 2017 Version 3.1 Page 9 of 323
+
+
+**Table of contents**
+
+
+**M** **CLASS FTP: TRUSTED PATH/CHANNELS ............................................... 321**
+
+
+**M.1** **Inter-TSF trusted channel (FTP_ITC) .......................................................................................... 321**
+
+
+**M.2** **Trusted path (FTP_TRP) ............................................................................................................... 322**
+
+
+Page 10 of 323 Version 3.1 April 2017
+
+
+**List of figures**
+
+# **List of figures**
+
+
+Figure 1 - Relationship between user data and TSF data ...................................................... 21
+Figure 2 - Relationship between โauthentication dataโ and โsecretsโ ................................... 22
+Figure 3 - Functional class structure ..................................................................................... 23
+Figure 4 - Functional family structure ................................................................................... 24
+Figure 5 - Functional component structure ........................................................................... 26
+Figure 6 - Sample class decomposition diagram ................................................................... 28
+Figure 7 - FAU: Security audit class decomposition ............................................................. 29
+Figure 8 - FCO: Communication class decomposition ......................................................... 43
+Figure 9 - FCS: Cryptographic support class decomposition ................................................ 48
+Figure 10 - FDP: User data protection class decomposition ................................................. 56
+Figure 11 - FIA: Identification and authentication class decomposition .............................. 88
+Figure 12 - FMT: Security management class decomposition ............................................ 104
+Figure 13 - FPR: Privacy class decomposition .................................................................... 118
+Figure 14 - FPT: Protection of the TSF class decomposition ............................................. 128
+Figure 15 - FRU: Resource utilisation class decomposition ............................................... 153
+Figure 16 - FTA: TOE access class decomposition ............................................................ 160
+Figure 17 - FTP: Trusted path/channels class decomposition ............................................. 170
+Figure 18 - Functional class structure ................................................................................. 175
+Figure 19 - Functional family structure for application notes ............................................. 176
+Figure 20 - Functional component structure ....................................................................... 177
+Figure 21 - FAU: Security audit class decomposition ......................................................... 186
+Figure 22 - FCO: Communication class decomposition ..................................................... 201
+Figure 23 - FCS: Cryptographic support class decomposition ............................................ 208
+Figure 24 - FDP: User data protection class decomposition ............................................... 216
+Figure 25 - FIA: Identification and authentication class decomposition ............................ 248
+Figure 26 - FMT: Security management class decomposition ............................................ 260
+Figure 27 - FPR: Privacy class decomposition .................................................................... 272
+Figure 28 - FPT: Protection of the TSF class decomposition ............................................. 287
+Figure 29 - FRU: Resource utilisation class decomposition ............................................... 307
+Figure 30 - FTA: TOE access class decomposition ............................................................ 313
+Figure 31 - FTP: Trusted path/channels class decomposition ............................................. 321
+
+
+April 2017 Version 3.1 Page 11 of 323
+
+
+**List of tables**
+
+# **List of tables**
+
+
+Table 1 Dependency table for Class FAU: Security audit .................................................. 178
+Table 2 Dependency table for Class FCO: Communication ............................................... 178
+Table 3 Dependency table for Class FCS: Cryptographic support ..................................... 179
+Table 4 Dependency table for Class FDP: User data protection ........................................ 180
+Table 5 Dependency table for Class FIA: Identification and authentication ...................... 181
+Table 6 Dependency table for Class FMT: Security management ..................................... 181
+Table 7 Dependency table for Class FPR: Privacy ............................................................. 182
+Table 8 Dependency table for Class FPT: Protection of the TSF ....................................... 182
+Table 9 Dependency table for Class FRU: Resource utilisation ......................................... 183
+Table 10 Dependency table for Class FTA: TOE access .................................................... 183
+
+
+Page 12 of 323 Version 3.1 April 2017
+
+
+**Introduction**
+
+# **1 Introduction**
+
+
+1 Security functional components, as defined in this CC Part 2, are the basis
+for the security functional requirements expressed in a Protection Profile
+(PP) or a Security Target (ST). These requirements describe the desired
+security behaviour expected of a Target of Evaluation (TOE) and are
+intended to meet the security objectives as stated in a PP or an ST. These
+requirements describe security properties that users can detect by direct
+interaction (i.e. inputs, outputs) with the IT or by the IT response to stimulus.
+
+
+2 Security functional components express security requirements intended to
+counter threats in the assumed operating environment of the TOE and/or
+cover any identified organisational security policies and assumptions.
+
+
+3 The audience for this CC Part 2 includes consumers, developers, and
+evaluators of secure IT products. CC Part 1 Chapter 6 provides additional
+information on the target audience of the CC, and on the use of the CC by the
+groups that comprise the target audience. These groups may use this part of
+the CC as follows:
+
+
+a) Consumers, who use this CC Part 2 when selecting components to
+express functional requirements to satisfy the security objectives
+expressed in a PP or ST. CC Part 1 Section 7 provides more detailed
+information on the relationship between security objectives and
+security requirements.
+
+
+b) Developers, who respond to actual or perceived consumer security
+requirements in constructing a TOE, may find a standardised method
+to understand those requirements in this part of the CC. They can also
+use the contents of this part of the CC as a basis for further defining
+the TOE security functionality and mechanisms that comply with
+those requirements.
+
+
+c) Evaluators, who use the functional requirements defined in this part
+of the CC in verifying that the TOE functional requirements
+expressed in the PP or ST satisfy the IT security objectives and that
+all dependencies are accounted for and shown to be satisfied.
+Evaluators also should use this part of the CC to assist in determining
+whether a given TOE satisfies stated requirements.
+
+
+April 2017 Version 3.1 Page 13 of 323
+
+
+**Scope**
+
+# **2 Scope**
+
+
+4 This part of the CC defines the required structure and content of security
+functional components for the purpose of security evaluation. It includes a
+catalogue of functional components that will meet the common security
+functionality requirements of many IT products.
+
+
+Page 14 of 323 Version 3.1 April 2017
+
+
+**Normative references**
+
+# **3 Normative references**
+
+
+5 The following referenced documents are indispensable for the application of
+this document. For dated references, only the edition cited applies. For
+undated references, the latest edition of the referenced document (including
+any amendments) applies.
+
+
+[CC] Common Criteria for Information Technology
+Security Evaluation, Version 3.1, revision 5, April
+2017. Part 1: Introduction and general model.
+
+
+April 2017 Version 3.1 Page 15 of 323
+
+
+**Terms and definitions, symbols and abbreviated terms**
+
+# **4 Terms and definitions, symbols and** **abbreviated terms**
+
+
+6 For the purposes of this document, the terms, definitions, symbols and
+abbreviated terms given in CC Part 1 apply.
+
+
+Page 16 of 323 Version 3.1 April 2017
+
+
+**Overview**
+
+# **5 Overview**
+
+
+7 The CC and the associated security functional requirements described herein
+are not meant to be a definitive answer to all the problems of IT security.
+Rather, the CC offers a set of well understood security functional
+requirements that can be used to create trusted products reflecting the needs
+of the market. These security functional requirements are presented as the
+current state of the art in requirements specification and evaluation.
+
+
+8 This part of the CC does not presume to include all possible security
+functional requirements but rather contains those that are known and agreed
+to be of value by the CC Part 2 authors at the time of release.
+
+
+9 Since the understanding and needs of consumers may change, the functional
+requirements in this part of the CC will need to be maintained. It is
+envisioned that some PP/ST authors may have security needs not (yet)
+covered by the functional requirement components in CC Part 2. In those
+cases the PP/ST author may choose to consider using functional
+requirements not taken from the CC (referred to as extensibility), as
+explained in annexes A and B of CC Part 1.
+
+## **5.1 Organisation of CC Part 2**
+
+
+10 Chapter 6 describes the paradigm used in the security functional
+requirements of CC Part 2.
+
+
+11 Chapter 7 introduces the catalogue of CC Part 2 functional components while
+chapters 8 through 18 describe the functional classes.
+
+
+12 Annex A provides explanatory information for potential users of the
+functional components including a complete cross reference table of the
+functional component dependencies.
+
+
+13 Annex B through M provide the explanatory information for the functional
+classes. This material must be seen as normative instructions on how to
+apply relevant operations and select appropriate audit or documentation
+information; the use of the auxiliary verb should means that the instruction is
+strongly preferred, but others may be justifiable. Where different options are
+given, the choice is left to the PP/ST author.
+
+
+14 Those who author PPs or STs should refer to chapter 2 of CC Part 1 for
+relevant structures, rules, and guidance:
+
+
+a) CC Part 1, chapter 4 defines the terms used in the CC.
+
+
+b) CC Part 1, annex A defines the structure for STs.
+
+
+c) CC Part 1, annex B defines the structure for PPs.
+
+
+April 2017 Version 3.1 Page 17 of 323
+
+
+**Functional requirements paradigm**
+
+# **6 Functional requirements paradigm**
+
+
+15 This chapter describes the paradigm used in the security functional
+requirements of this part of the CC. Key concepts discussed are highlighted
+in bold/italics. This section is not intended to replace or supersede any of the
+terms found in CC Part 1, chapter 4.
+
+
+16 This part of the CC is a catalogue of security functional components that can
+be specified for a **Target of Evaluation (TOE)** . A TOE is a set of software,
+firmware and/or hardware possibly accompanied by user and administrator
+guidance documentation. A TOE may contain resources such as electronic
+storage media (e.g. main memory, disk space), peripheral devices (e.g.
+printers), and computing capacity (e.g. CPU time) that can be used for
+processing and storing information and is the subject of an evaluation.
+
+
+17 TOE evaluation is concerned primarily with ensuring that a defined set of
+**security functional requirements (SFRs)** is enforced over the TOE
+resources. The SFRs define the rules by which the TOE governs access to
+and use of its resources, and thus information and services controlled by the
+TOE.
+
+
+18 The SFRs may define multiple **Security Function Policies** (SFPs) to
+represent the rules that the TOE must enforce. Each such SFP must specify
+its **scope of control**, by defining the subjects, objects, resources or
+information, and operations to which it applies. All SFPs are implemented by
+the TSF (see below), whose mechanisms enforce the rules defined in the
+SFRs and provide necessary capabilities.
+
+
+19 Those portions of a TOE that must be relied on for the correct enforcement
+of the SFRs are collectively referred to as the **TOE Security Functionality**
+**(TSF)** . The TSF consists of all hardware, software, and firmware of a TOE
+that is either directly or indirectly relied upon for security enforcement.
+
+
+20 The TOE may be a monolithic product containing hardware, firmware, and
+software.
+
+
+21 Alternatively a TOE may be a distributed product that consists internally of
+multiple separated parts. Each of these parts of the TOE provides a particular
+service for the TOE, and is connected to the other parts of the TOE through
+an **internal communication channel** . This channel can be as small as a
+processor bus, or may encompass a network internal to the TOE.
+
+
+22 When the TOE consists of multiple parts, each part of the TOE may have its
+own part of the TSF which exchanges user and TSF data over internal
+communication channels with other parts of the TSF. This interaction is
+called **internal TOE transfer** . In this case the separate parts of the TSF
+abstractly form the composite TSF, which enforces the SFRs.
+
+
+Page 18 of 323 Version 3.1 April 2017
+
+
+**Functional requirements paradigm**
+
+
+23 TOE interfaces may be localised to the particular TOE, or they may allow
+interaction with other IT products over **external communication channels** .
+These external interactions with other IT products may take two forms:
+
+
+a) The SFRs of the other โtrusted IT productโ and the SFRs of the TOE
+have been administratively coordinated and the other trusted IT
+product is assumed to enforce its SFRs correctly (e. g. by being
+separately evaluated). Exchanges of information in this situation are
+called **inter-TSF transfers**, as they are between the TSFs of distinct
+trusted products.
+
+
+b) The other IT product may not be trusted, it may be called an
+โuntrusted IT productโ. Therefore its SFRs are either unknown or
+their implementation is not viewed as trustworthy. TSF mediated
+exchanges of information in this situation are called **transfers**
+**outside of the TOE**, as there is no TSF (or its policy characteristics
+are unknown) on the other IT product.
+
+
+24 The set of interfaces, whether interactive (man-machine interface) or
+programmatic (application programming interface), through which resources
+are accessed that are mediated by the TSF, or information is obtained from
+the TSF, is referred to as the **TSF Interface (TSFI)** . The TSFI defines the
+boundaries of the TOE functionality that provide for the enforcement of the
+SFRs.
+
+
+25 Users are outside of the TOE. However, in order to request that services be
+performed by the TOE that are subject to rules defined in the SFRs, users
+interact with the TOE through the TSFIs. There are two types of users of
+interest to CC Part 2: **human users** and **external IT entities** . Human users
+may further be differentiated as **local human users**, meaning they interact
+directly with the TOE via TOE devices (e.g. workstations), or **remote**
+**human users**, meaning they interact indirectly with the TOE through
+another IT product.
+
+
+26 A period of interaction between users and the TSF is referred to as a user
+**session** . Establishment of user sessions can be controlled based on a variety
+of considerations, for example: user authentication, time of day, method of
+accessing the TOE, and number of allowed concurrent sessions (per user or
+in total).
+
+
+27 This part of the CC uses the term **authorised** to signify a user who possesses
+the rights and/or privileges necessary to perform an operation. The term
+**authorised user**, therefore, indicates that it is allowable for a user to perform
+a specific operation or a set of operations as defined by the SFRs.
+
+
+28 To express requirements that call for the separation of administrator duties,
+the relevant security functional components (from family FMT_SMR)
+explicitly state that administrative **roles** are required. A role is a pre-defined
+set of rules establishing the allowed interactions between a user operating in
+that role and the TOE. A TOE may support the definition of any number of
+
+
+April 2017 Version 3.1 Page 19 of 323
+
+
+**Functional requirements paradigm**
+
+
+roles. For example, roles related to the secure operation of a TOE may
+include โAudit Administratorโ and โUser Accounts Administratorโ.
+
+
+29 TOEs contain **resources** that may be used for the processing and storing of
+information. The primary goal of the TSF is the complete and correct
+enforcement of the SFRs over the resources and information that the TOE
+controls.
+
+
+30 TOE resources can be structured and utilised in many different ways.
+However, CC Part 2 makes a specific distinction that allows for the
+specification of desired security properties. All entities that can be created
+from resources can be characterised in one of two ways. The entities may be
+active, meaning that they are the cause of actions that occur internal to the
+TOE and cause operations to be performed on information. Alternatively, the
+entities may be passive, meaning that they are either the container from
+which information originates or to which information is stored.
+
+
+31 Active entities in the TOE that perform operations on objects are referred to
+as **subjects** . Several types of subjects may exist within a TOE:
+
+
+a) those acting on behalf of an authorised user (e.g. UNIX processes);
+
+
+b) those acting as a specific functional process that may in turn act on
+behalf of multiple users (e.g. functions as might be found in
+client/server architectures); or
+
+
+c) those acting as part of the TOE itself (e.g. processes not acting on
+behalf of a user).
+
+
+32 CC Part 2 addresses the enforcement of the SFRs over types of subjects as
+those listed above.
+
+
+33 Passive entities in the TOE that contain or receive information and upon
+which subjects perform operations are called **objects** . In the case where a
+subject (an active entity) is the target of an operation (e.g. interprocess
+communication), a subject may also be acted on as an object.
+
+
+34 Objects can contain **information** . This concept is required to specify
+information flow control policies as addressed in the FDP class.
+
+
+35 Users, subjects, information, objects, sessions and resources controlled by
+rules in the SFRs may possess certain **attributes** that contain information
+that is used by the TOE for its correct operation. Some attributes, such as file
+names, may be intended to be informational or may be used to identify
+individual resources while others, such as access control information, may
+exist specifically for the enforcement of the SFRs. These latter attributes are
+generally referred to as โ **security attributes** โ. The word attribute will be
+used as a shorthand in some places of this part of the CC for the word
+โsecurity attributeโ. However, no matter what the intended purpose of the
+attribute information, it may be necessary to have controls on attributes as
+dictated by the SFRs.
+
+
+Page 20 of 323 Version 3.1 April 2017
+
+
+**Functional requirements paradigm**
+
+
+36 Data in a TOE is categorised as either user data or TSF data. Figure 1 depicts
+this relationship. **User Data** is information stored in TOE resources that can
+be operated upon by users in accordance with the SFRs and upon which the
+TSF places no special meaning. For example, the content of an electronic
+mail message is user data. TSF Data is information used by the TSF in
+making decisions as required by the SFRs. **TSF Data** may be influenced by
+users if allowed by the SFRs. Security attributes, authentication data, TSF
+internal status variables used by the rules defined in the SFRs or used for the
+protection of the TSF and access control list entries are examples of TSF data.
+
+
+37 There are several SFPs that apply to data protection such as **access control**
+**SFPs** and **information flow control SFPs** . The mechanisms that implement
+access control SFPs base their policy decisions on attributes of the users,
+resources, subjects, objects, sessions, TSF status data and operations within
+the scope of control. These attributes are used in the set of rules that govern
+operations that subjects may perform on objects.
+
+
+38 The mechanisms that implement information flow control SFPs base their
+policy decisions on the attributes of the subjects and information within the
+scope of control and the set of rules that govern the operations by subjects on
+information. The attributes of the information, which may be associated with
+the attributes of the container or may be derived from the data in the
+container, stay with the information as it is processed by the TSF.
+
+
+**Figure 1 - Relationship between user data and TSF data**
+
+
+39 Two specific types of TSF data addressed by CC Part 2 can be, but are not
+necessarily, the same. These are **authentication data** and **secrets** .
+
+
+40 Authentication data is used to verify the claimed identity of a user requesting
+services from a TOE. The most common form of authentication data is the
+password, which depends on being kept secret in order to be an effective
+security mechanism. However, not all forms of authentication data need to be
+kept secret. Biometric authentication devices (e.g. fingerprint readers, retinal
+scanners) do not rely on the fact that the data is kept secret, but rather that the
+data is something that only one user possesses and that cannot be forged.
+
+
+41 The term secrets, as used in CC Part 2, while applicable to authentication
+data, is intended to also be applicable to other types of data that must be kept
+secret in order to enforce a specific SFP. For example, a trusted channel
+mechanism that relies on cryptography to preserve the confidentiality of
+
+
+April 2017 Version 3.1 Page 21 of 323
+
+
+**Functional requirements paradigm**
+
+
+information being transmitted via the channel can only be as strong as the
+method used to keep the cryptographic keys secret from unauthorised
+disclosure.
+
+
+42 Therefore, some, but not all, authentication data needs to be kept secret and
+some, but not all, secrets are used as authentication data. Figure 2 shows this
+relationship between secrets and authentication data. In the Figure the types
+of data typically encountered in the authentication data and the secrets
+sections are indicated.
+
+
+**Figure 2 - Relationship between โauthentication dataโ and โsecretsโ**
+
+
+Page 22 of 323 Version 3.1 April 2017
+
+
+**Security functional components**
+
+# **7 Security functional components**
+
+## **7.1 Overview**
+
+
+43 This chapter defines the content and presentation of the functional
+requirements of the CC, and provides guidance on the organisation of the
+requirements for new components to be included in an ST. The functional
+requirements are expressed in classes, families, and components.
+
+
+**7.1.1** **Class structure**
+
+
+44 Figure 3 illustrates the functional class structure in diagrammatic form. Each
+functional class includes a class name, class introduction, and one or more
+functional families.
+
+
+**Figure 3 - Functional class structure**
+
+
+7.1.1.1 Class name
+
+
+45 The class name section provides information necessary to identify and
+categorise a functional class. Every functional class has a unique name. The
+categorical information consists of a short name of three characters. The
+short name of the class is used in the specification of the short names of the
+families of that class.
+
+
+7.1.1.2 Class introduction
+
+
+46 The class introduction expresses the common intent or approach of those
+families to satisfy security objectives. The definition of functional classes
+does not reflect any formal taxonomy in the specification of the requirements.
+
+
+47 The class introduction provides a figure describing the families in this class
+and the hierarchy of the components in each family, as explained in section
+7.2.
+
+
+April 2017 Version 3.1 Page 23 of 323
+
+
+**Security functional components**
+
+
+**7.1.2** **Family structure**
+
+
+48 Figure 4 illustrates the functional family structure in diagrammatic form.
+
+
+**Figure 4 - Functional family structure**
+
+
+7.1.2.1 Family name
+
+
+49 The family name section provides categorical and descriptive information
+necessary to identify and categorise a functional family. Every functional
+family has a unique name. The categorical information consists of a short
+name of seven characters, with the first three identical to the short name of
+the class followed by an underscore and the short name of the family as
+follows XXX_YYY. The unique short form of the family name provides the
+principal reference name for the components.
+
+
+7.1.2.2 Family behaviour
+
+
+50 The family behaviour is the narrative description of the functional family
+stating its security objective and a general description of the functional
+requirements. These are described in greater detail below:
+
+
+a) The _security objectives_ of the family address a security problem that
+may be solved with the help of a TOE that incorporates a component
+of this family;
+
+
+b) The description of the _functional requirements_ summarises all the
+requirements that are included in the component(s). The description
+is aimed at authors of PPs, STs and functional packages who wish to
+assess whether the family is relevant to their specific requirements.
+
+
+7.1.2.3 Component levelling
+
+
+51 Functional families contain one or more components, any one of which can
+be selected for inclusion in PPs, STs and functional packages. The goal of
+this section is to provide information to users in selecting an appropriate
+functional component once the family has been identified as being a
+necessary or useful part of their security requirements.
+
+
+Page 24 of 323 Version 3.1 April 2017
+
+
+**Security functional components**
+
+
+52 This section of the functional family description describes the components
+available, and their rationale. The exact details of the components are
+contained within each component.
+
+
+53 The relationships between components within a functional family may or
+may not be hierarchical. A component is hierarchical to another if it offers
+more security.
+
+
+54 As explained in 7.2 the descriptions of the families provide a graphical
+overview of the hierarchy of the components in a family.
+
+
+7.1.2.4 Management
+
+
+55 The _management_ chapters contain information for the PP/ST authors to
+consider as management activities for a given component. The chapters
+reference components of the management class (FMT), and provide guidance
+regarding potential management activities that may be applied via operations
+to those components.
+
+
+56 A PP/ST author may select the indicated management components or may
+include other management requirements not listed to detail management
+activities. As such the information should be considered informative.
+
+
+7.1.2.5 Audit
+
+
+57 The _audit_ requirements contain auditable events for the PP/ST authors to
+select, if requirements from the class FAU: Security audit, are included in the
+PP/ST. These requirements include security relevant events in terms of the
+various levels of detail supported by the components of the Security audit
+data generation (FAU_GEN) family. For example, an audit note might
+include actions that are in terms of: Minimal - successful use of the security
+mechanism; Basic - any use of the security mechanism as well as relevant
+information regarding the security attributes involved; Detailed - any
+configuration changes made to the mechanism, including the actual
+configuration values before and after the change.
+
+
+58 It should be observed that the categorisation of auditable events is
+hierarchical. For example, when Basic Audit Generation is desired, all
+auditable events identified as being both Minimal and Basic should be
+included in the PP/ST through the use of the appropriate assignment
+operation, except when the higher level event simply provides more detail
+than the lower level event. When Detailed Audit Generation is desired, all
+identified auditable events (Minimal, Basic and Detailed) should be included
+in the PP/ST.
+
+
+59 In the class FAU: Security audit the rules governing the audit are explained
+in more detail.
+
+
+**7.1.3** **Component structure**
+
+
+60 Figure 5 illustrates the functional component structure.
+
+
+April 2017 Version 3.1 Page 25 of 323
+
+
+**Security functional components**
+
+
+**Figure 5 - Functional component structure**
+
+
+7.1.3.1 Component identification
+
+
+61 The component identification section provides descriptive information
+necessary to identify, categorise, register and cross-reference a component.
+The following is provided as part of every functional component:
+
+
+62 A _unique name_ . The name reflects the purpose of the component.
+
+
+63 A _short name_ . A unique short form of the functional component name. This
+short name serves as the principal reference name for the categorisation,
+registration and cross-referencing of the component. This short name reflects
+the class and family to which the component belongs and the component
+number within the family.
+
+
+64 A _hierarchical-to list_ . A list of other components that this component is
+hierarchical to and for which this component can be used to satisfy
+dependencies to the listed components.
+
+
+7.1.3.2 Functional elements
+
+
+65 A set of elements is provided for each component. Each element is
+individually defined and is self-contained.
+
+
+66 A functional element is a security functional requirement that if further
+divided would not yield a meaningful evaluation result. It is the smallest
+security functional requirement identified and recognised in the CC.
+
+
+67 When building packages, PPs and/or STs, it is not permitted to select only
+one or more elements from a component. The complete set of elements of a
+component must be selected for inclusion in a PP, ST or package.
+
+
+68 A unique short form of the functional element name is provided. For
+example the requirement name FDP_IFF.4.2 reads as follows: F - functional
+requirement, DP - class โUser data protectionโ, _IFF - family โInformation
+
+
+Page 26 of 323 Version 3.1 April 2017
+
+
+**Security functional components**
+
+
+flow control functionsโ, .4 - 4th component named โPartial elimination of
+illicit information flowsโ, .2 - 2nd element of the component.
+
+
+7.1.3.3 Dependencies
+
+
+69 Dependencies among functional components arise when a component is not
+self sufficient and relies upon the functionality of, or interaction with,
+another component for its own proper functioning.
+
+
+70 Each functional component provides a complete list of dependencies to other
+functional and assurance components. Some components may list โNo
+dependenciesโ. The components depended upon may in turn have
+dependencies on other components. The list provided in the components will
+be the direct dependencies. That is only references to the functional
+requirements that are required for this requirement to perform its job
+properly. The indirect dependencies, that is the dependencies that result from
+the depended upon components can be found in Annex A of this part of the
+CC. It is noted that in some cases the dependency is optional in that a
+number of functional requirements are provided, where each one of them
+would be sufficient to satisfy the dependency (see for example FDP_UIT.1
+Data exchange integrity).
+
+
+71 The dependency list identifies the minimum functional or assurance
+components needed to satisfy the security requirements associated with an
+identified component. Components that are hierarchical to the identified
+component may also be used to satisfy the dependency.
+
+
+72 The dependencies indicated in CC Part 2 are normative. They must be
+satisfied within a PP/ST. In specific situations the indicated dependencies
+might not be applicable. The PP/ST author, by providing the rationale why it
+is not applicable, may leave the depended upon component out of the
+package, PP or ST.
+
+## **7.2 Component catalogue**
+
+
+73 The grouping of the components in this part of the CC does not reflect any
+formal taxonomy.
+
+
+74 This part of the CC contains classes of families and components, which are
+rough groupings on the basis of related function or purpose, presented in
+alphabetic order. At the start of each class is an informative diagram that
+indicates the taxonomy of each class, indicating the families in each class
+and the components in each family. The diagram is a useful indicator of the
+hierarchical relationship that may exist between components.
+
+
+75 In the description of the functional components, a section identifies the
+dependencies between the component and any other components.
+
+
+76 In each class a figure describing the family hierarchy similar to Figure 6, is
+provided. In Figure 6 the first family, Family 1, contains three hierarchical
+components, where component 2 and component 3 can both be used to
+
+
+April 2017 Version 3.1 Page 27 of 323
+
+
+**Security functional components**
+
+
+satisfy dependencies on component 1. Component 3 is hierarchical to
+component 2 and can also be used to satisfy dependencies on component 2.
+
+
+**Figure 6 - Sample class decomposition diagram**
+
+
+77 In Family 2 there are three components not all of which are hierarchical.
+Components 1 and 2 are hierarchical to no other components. Component 3
+is hierarchical to component 2, and can be used to satisfy dependencies on
+component 2, but not to satisfy dependencies on component 1.
+
+
+78 In Family 3, components 2, 3, and 4 are hierarchical to component 1.
+Components 2 and 3 are both hierarchical to component 1, but noncomparable. Component 4 is hierarchical to both component 2 and
+component 3.
+
+
+79 These diagrams are meant to complement the text of the families and make
+identification of the relationships easier. They do not replace the
+โHierarchical to:โ note in each component that is the mandatory claim of
+hierarchy for each component.
+
+
+**7.2.1** **Component changes highlighting**
+
+
+80 The relationship between components within a family is highlighted using a
+**bolding** convention. This bolding convention calls for the bolding of all new
+requirements. For hierarchical components, requirements are bolded when
+they are enhanced or modified beyond the requirements of the previous
+component. In addition, any new or enhanced permitted operations beyond
+the previous component are also highlighted using **bold** type.
+
+
+Page 28 of 323 Version 3.1 April 2017
+
+
+**Class FAU: Security audit**
+
+# **8 Class FAU: Security audit**
+
+
+81 Security auditing involves recognising, recording, storing, and analysing
+information related to security relevant activities (i.e. activities controlled by
+the TSF). The resulting audit records can be examined to determine which
+security relevant activities took place and whom (which user) is responsible
+for them.
+
+
+**Figure 7 - FAU: Security audit class decomposition**
+
+
+April 2017 Version 3.1 Page 29 of 323
+
+
+**Class FAU: Security audit**
+
+## **8.1 Security audit automatic response (FAU_ARP)**
+
+
+Family Behaviour
+
+
+82 This family defines the response to be taken in case of detected events
+indicative of a potential security violation.
+
+
+Component levelling
+
+
+83 At FAU_ARP.1 Security alarms, the TSF shall take actions in case a
+potential security violation is detected.
+
+
+Management: FAU_ARP.1
+
+
+84 The following actions could be considered for the management functions in
+FMT:
+
+
+a) the management (addition, removal, or modification) of actions.
+
+
+Audit: FAU_ARP.1
+
+
+85 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Actions taken due to potential security violations.
+
+
+**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 [assignment:** _**list of actions**_ **] upon detection of a**
+**potential security violation.**
+
+
+Page 30 of 323 Version 3.1 April 2017
+
+
+**Class FAU: Security audit**
+
+## **8.2 Security audit data generation (FAU_GEN)**
+
+
+Family Behaviour
+
+
+86 This family defines requirements for recording the occurrence of security
+relevant events that take place under TSF control. This family identifies the
+level of auditing, enumerates the types of events that shall be auditable by
+the TSF, and identifies the minimum set of audit-related information that
+should be provided within various audit record types.
+
+
+Component levelling
+
+
+87 FAU_GEN.1 Audit data generation defines the level of auditable events, and
+specifies the list of data that shall be recorded in each record.
+
+
+88 At FAU_GEN.2 User identity association, the TSF shall associate auditable
+events to individual user identities.
+
+
+Management: FAU_GEN.1, FAU_GEN.2
+
+
+89 There are no management activities foreseen.
+
+
+Audit: FAU_GEN.1, FAU_GEN.2
+
+
+90 There are no auditable events foreseen.
+
+
+**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 [selection, choose one of:** _**minimum,**_
+_**basic, detailed, not specified**_ **] level of audit; and**
+
+
+**c)** **[assignment:** _**other specifically defined auditable events**_ **].**
+
+
+**FAU_GEN.1.2** **The TSF shall record within each audit record at least the following**
+**information:**
+
+
+April 2017 Version 3.1 Page 31 of 323
+
+
+**Class FAU: Security audit**
+
+
+**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,**
+
+**[assignment:** _**other audit relevant information**_ **].**
+
+
+**FAU_GEN.2** **User identity association**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FAU_GEN.1 Audit data generation
+FIA_UID.1 Timing of identification
+
+
+**FAU_GEN.2.1** **For audit events resulting from actions of identified users, the TSF shall**
+**be able to associate each auditable event with the identity of the user**
+**that caused the event.**
+
+
+Page 32 of 323 Version 3.1 April 2017
+
+
+**Class FAU: Security audit**
+
+## **8.3 Security audit analysis (FAU_SAA)**
+
+
+Family Behaviour
+
+
+91 This family defines requirements for automated means that analyse system
+activity and audit data looking for possible or real security violations. This
+analysis may work in support of intrusion detection, or automatic response to
+a potential security violation.
+
+
+92 The actions to be taken based on the detection can be specified using the
+Security audit automatic response (FAU_ARP) family as desired.
+
+
+Component levelling
+
+
+93 In FAU_SAA.1 Potential violation analysis, basic threshold detection on the
+basis of a fixed rule set is required.
+
+
+94 In FAU_SAA.2 Profile based anomaly detection, the TSF maintains
+individual profiles of system usage, where a profile represents the historical
+patterns of usage performed by members of the profile target group. A
+profile target group refers to a group of one or more individuals (e.g. a single
+user, users who share a group ID or group account, users who operate under
+an assigned role, users of an entire system or network node) who interact
+with the TSF. Each member of a profile target group is assigned an
+individual suspicion rating that represents how well that member's current
+activity corresponds to the established patterns of usage represented in the
+profile. This analysis can be performed at runtime or during a post-collection
+batch-mode analysis.
+
+
+95 In FAU_SAA.3 Simple attack heuristics, the TSF shall be able to detect the
+occurrence of signature events that represent a significant threat to
+enforcement of the SFRs. This search for signature events may occur in realtime or during a post-collection batch-mode analysis.
+
+
+96 In FAU_SAA.4 Complex attack heuristics, the TSF shall be able to represent
+and detect multi-step intrusion scenarios. The TSF is able to compare system
+events (possibly performed by multiple individuals) against event sequences
+known to represent entire intrusion scenarios. The TSF shall be able to
+indicate when a signature event or event sequence is found that indicates a
+potential violation of the enforcement of the SFRs.
+
+
+April 2017 Version 3.1 Page 33 of 323
+
+
+**Class FAU: Security audit**
+
+
+Management: FAU_SAA.1
+
+
+97 The following actions could be considered for the management functions in
+FMT:
+
+
+a) maintenance of the rules by (adding, modifying, deletion) of rules
+from the set of rules.
+
+
+Management: FAU_SAA.2
+
+
+98 The following actions could be considered for the management functions in
+FMT:
+
+
+a) maintenance (deletion, modification, addition) of the group of users
+in the profile target group.
+
+
+Management: FAU_SAA.3
+
+
+99 The following actions could be considered for the management functions in
+FMT:
+
+
+a) maintenance (deletion, modification, addition) of the subset of system
+events.
+
+
+Management: FAU_SAA.4
+
+
+100 The following actions could be considered for the management functions in
+FMT:
+
+
+a) maintenance (deletion, modification, addition) of the subset of system
+events;
+
+
+b) maintenance (deletion, modification, addition) of the set of sequence
+of system events.
+
+
+Audit: FAU_SAA.1, FAU_SAA.2, FAU_SAA.3, FAU_SAA.4
+
+
+101 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Enabling and disabling of any of the analysis mechanisms;
+
+
+b) Minimal: Automated responses performed by the tool.
+
+
+**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.**
+
+
+Page 34 of 323 Version 3.1 April 2017
+
+
+**Class FAU: Security audit**
+
+
+**FAU_SAA.1.2** **The TSF shall enforce the following rules for monitoring audited events:**
+
+
+**a)** **Accumulation or combination of [assignment:** _**subset of defined**_
+_**auditable events**_ **] known to indicate a potential security violation;**
+
+
+**b)** **[assignment:** _**any other rules**_ **].**
+
+
+**FAU_SAA.2** **Profile based anomaly detection**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FIA_UID.1 Timing of identification
+
+
+**FAU_SAA.2.1** **The TSF shall be able to maintain profiles of system usage, where an**
+**individual profile represents the historical patterns of usage performed**
+**by the member(s) of [assignment:** _**the profile target group**_ **].**
+
+
+**FAU_SAA.2.2** **The TSF shall be able to maintain a suspicion rating associated with**
+**each user whose activity is recorded in a profile, where the suspicion**
+**rating represents the degree to which the user's current activity is found**
+**inconsistent with the established patterns of usage represented in the**
+**profile.**
+
+
+**FAU_SAA.2.3** **The TSF shall be able to indicate a possible violation of the enforcement**
+**of the SFRs when a user's suspicion rating exceeds the following**
+**threshold conditions [assignment:** _**conditions under which anomalous**_
+_**activity is reported by the TSF**_ **].**
+
+
+**FAU_SAA.3** **Simple attack heuristics**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FAU_SAA.3.1** **The TSF shall be able to maintain an internal representation of the**
+**following signature events [assignment:** _**a subset of system events**_ **] that**
+**may indicate a violation of the enforcement of the SFRs.**
+
+
+**FAU_SAA.3.2** **The TSF shall be able to compare the signature events against the**
+**record of system activity discernible from an examination of**
+
+**[assignment:** _**the information to be used to determine system activity**_ **].**
+
+
+**FAU_SAA.3.3** **The TSF shall be able to indicate a potential violation of the enforcement**
+**of the SFRs when a system event is found to match a signature event**
+**that indicates a potential violation of the enforcement of the SFRs.**
+
+
+April 2017 Version 3.1 Page 35 of 323
+
+
+**Class FAU: Security audit**
+
+
+**FAU_SAA.4** **Complex attack heuristics**
+
+
+Hierarchical to: FAU_SAA.3 Simple attack heuristics
+
+
+Dependencies: No dependencies.
+
+
+**FAU_SAA.4.1** The TSF shall be able to maintain an internal representation of the following
+**event** **sequences** **of** **known** **intrusion** **scenarios** **[assignment:** _**list**_ _**of**_
+_**sequences**_ _**of**_ _**system**_ _**events**_ _**whose**_ _**occurrence**_ _**are**_ _**representative**_ _**of**_ _**known**_
+_**penetration**_ _**scenarios**_ **]** **and** **the** **following** signature events [assignment: _a_
+_subset of system events_ ] that may indicate a **potential** violation of the
+enforcement of the SFRs.
+
+
+**FAU_SAA.4.2** The TSF shall be able to compare the signature events **and** **event** **sequences**
+against the record of system activity discernible from an examination of
+
+[assignment: _the information to be used to determine system activity_ ].
+
+
+**FAU_SAA.4.3** The TSF shall be able to indicate a potential violation of the enforcement of
+the SFRs when system **activity** is found to match a signature event **or** **event**
+**sequence** that indicates a potential violation of the enforcement of the SFRs.
+
+
+Page 36 of 323 Version 3.1 April 2017
+
+
+**Class FAU: Security audit**
+
+## **8.4 Security audit review (FAU_SAR)**
+
+
+Family Behaviour
+
+
+102 This family defines the requirements for audit tools that should be available
+to authorised users to assist in the review of audit data.
+
+
+Component levelling
+
+
+103 FAU_SAR.1 Audit review, provides the capability to read information from
+the audit records.
+
+
+104 FAU_SAR.2 Restricted audit review, requires that there are no other users
+except those that have been identified in FAU_SAR.1 Audit review that can
+read the information.
+
+
+105 FAU_SAR.3 Selectable audit review, requires audit review tools to select the
+audit data to be reviewed based on criteria.
+
+
+Management: FAU_SAR.1
+
+
+106 The following actions could be considered for the management functions in
+FMT:
+
+
+a) maintenance (deletion, modification, addition) of the group of users
+with read access right to the audit records.
+
+
+Management: FAU_SAR.2, FAU_SAR.3
+
+
+107 There are no management activities foreseen.
+
+
+Audit: FAU_SAR.1
+
+
+108 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Basic: Reading of information from the audit records.
+
+
+April 2017 Version 3.1 Page 37 of 323
+
+
+**Class FAU: Security audit**
+
+
+Audit: FAU_SAR.2
+
+
+109 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Basic: Unsuccessful attempts to read information from the audit
+records.
+
+
+Audit: FAU_SAR.3
+
+
+110 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Detailed: the parameters used for the viewing.
+
+
+**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 [assignment:** _**authorised users**_ **] with the capability**
+**to read [assignment:** _**list of audit information**_ **] from the audit records.**
+
+
+**FAU_SAR.1.2** **The TSF shall provide the audit records in a manner suitable for the**
+**user to interpret the information.**
+
+
+**FAU_SAR.2** **Restricted audit review**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FAU_SAR.1 Audit review
+
+
+**FAU_SAR.2.1** **The TSF shall prohibit all users read access to the audit records, except**
+**those users that have been granted explicit read-access.**
+
+
+**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 [assignment:** _**methods of**_
+_**selection and/or ordering**_ **] of audit data based on [assignment:** _**criteria**_
+_**with logical relations**_ **].**
+
+
+Page 38 of 323 Version 3.1 April 2017
+
+
+**Class FAU: Security audit**
+
+## **8.5 Security audit event selection (FAU_SEL)**
+
+
+Family Behaviour
+
+
+111 This family defines requirements to select the set of events to be audited
+during TOE operation from the set of all auditable events.
+
+
+Component levelling
+
+
+112 FAU_SEL.1 Selective audit, requires the ability to select the set of events to
+be audited from the set of all auditable events, identified in FAU_GEN.1
+Audit data generation, based upon attributes to be specified by the PP/ST
+author.
+
+
+Management: FAU_SEL.1
+
+
+113 The following actions could be considered for the management functions in
+FMT:
+
+
+a) maintenance of the rights to view/modify the audit events.
+
+
+Audit: FAU_SEL.1
+
+
+114 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: All modifications to the audit configuration that occur
+while the audit collection functions are operating.
+
+
+**FAU_SEL.1** **Selective audit**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FAU_GEN.1 Audit data generation
+FMT_MTD.1 Management of TSF data
+
+
+**FAU_SEL.1.1** **The TSF shall be able to select the set of events to be audited from the**
+**set of all auditable events based on the following attributes:**
+
+
+**a)** **[selection:** _**object identity, user identity, subject identity, host**_
+_**identity, event type**_ **]**
+
+
+**b)** **[assignment:** _**list of additional attributes that audit selectivity is**_
+_**based upon**_ **]**
+
+
+April 2017 Version 3.1 Page 39 of 323
+
+
+**Class FAU: Security audit**
+
+## **8.6 Security audit event storage (FAU_STG)**
+
+
+Family Behaviour
+
+
+115 This family defines the requirements for the TSF to be able to create and
+maintain a secure audit trail. Stored audit records refers to those records
+within the audit trail, and not the audit records that have been retrieved (to
+temporary storage) through selection.
+
+
+Component levelling
+
+
+116 At FAU_STG.1 Protected audit trail storage, requirements are placed on the
+audit trail. It will be protected from unauthorised deletion and/or
+modification.
+
+
+117 FAU_STG.2 Guarantees of audit data availability, specifies the guarantees
+that the TSF maintains over the audit data given the occurrence of an
+undesired condition.
+
+
+118 FAU_STG.3 Action in case of possible audit data loss, specifies actions to be
+taken if a threshold on the audit trail is exceeded.
+
+
+119 FAU_STG.4 Prevention of audit data loss, specifies actions in case the audit
+trail is full.
+
+
+Management: FAU_STG.1
+
+
+120 There are no management activities foreseen.
+
+
+Management: FAU_STG.2
+
+
+121 The following actions could be considered for the management functions in
+FMT:
+
+
+a) maintenance of the parameters that control the audit storage
+capability.
+
+
+Management: FAU_STG.3
+
+
+122 The following actions could be considered for the management functions in
+FMT:
+
+
+a) maintenance of the threshold;
+
+
+b) maintenance (deletion, modification, addition) of actions to be taken
+in case of imminent audit storage failure.
+
+
+Page 40 of 323 Version 3.1 April 2017
+
+
+**Class FAU: Security audit**
+
+
+Management: FAU_STG.4
+
+
+123 The following actions could be considered for the management functions in
+FMT:
+
+
+a) maintenance (deletion, modification, addition) of actions to be taken
+in case of audit storage failure.
+
+
+Audit: FAU_STG.1, FAU_STG.2
+
+
+124 There are no auditable events foreseen.
+
+
+Audit: FAU_STG.3
+
+
+125 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Basic: Actions taken due to exceeding of a threshold.
+
+
+Audit: FAU_STG.4
+
+
+126 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Basic: Actions taken due to the audit storage failure.
+
+
+**FAU_STG.1** **Protected audit trail storage**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FAU_GEN.1 Audit data generation
+
+
+**FAU_STG.1.1** **The TSF shall protect the stored audit records in the audit trail from**
+**unauthorised deletion.**
+
+
+**FAU_STG.1.2** **The TSF shall be able to [selection, choose one of:** _**prevent, detect**_ **]**
+**unauthorised modifications to the stored audit records in the audit trail.**
+
+
+**FAU_STG.2** **Guarantees of audit data availability**
+
+
+Hierarchical to: FAU_STG.1 Protected audit trail storage
+
+
+Dependencies: FAU_GEN.1 Audit data generation
+
+
+**FAU_STG.2.1** The TSF shall protect the stored audit records in the audit trail from
+unauthorised deletion.
+
+
+**FAU_STG.2.2** The TSF shall be able to [selection, choose one of: _prevent, detect_ ]
+unauthorised modifications to the stored audit records in the audit trail.
+
+
+**FAU_STG.2.3** **The TSF shall ensure that [assignment:** _**metric for saving audit records**_ **]**
+**stored audit records will be maintained when the following conditions**
+**occur: [selection:** _**audit storage exhaustion, failure, attack**_ **]**
+
+
+April 2017 Version 3.1 Page 41 of 323
+
+
+**Class FAU: Security audit**
+
+
+**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 [assignment:** _**actions to be taken in case of possible audit**_
+_**storage failure**_ **] if the audit trail exceeds [assignment:** _**pre-defined limit**_ **].**
+
+
+**FAU_STG.4** **Prevention of audit data loss**
+
+
+Hierarchical to: FAU_STG.3 Action in case of possible audit data loss
+
+
+Dependencies: FAU_STG.1 Protected audit trail storage
+
+
+**FAU_STG.4.1** The TSF shall **[selection,** **choose** **one** **of:** _**โignore**_ _**audited**_ _**eventsโ,**_ _**โprevent**_
+_**audited**_ _**events,**_ _**except**_ _**those**_ _**taken**_ _**by**_ _**the**_ _**authorised**_ _**user**_ _**with**_ _**special**_
+_**rightsโ,**_ _**โoverwrite**_ _**the**_ _**oldest**_ _**stored**_ _**audit**_ _**recordsโ**_ **]** **and** [assignment: _**other**_
+_**actions**_ _to be taken in case of audit storage failure_ ] if the audit trail **is** **full.**
+
+
+Page 42 of 323 Version 3.1 April 2017
+
+
+**Class FCO: Communication**
+
+# **9 Class FCO: Communication**
+
+
+127 This class provides two families specifically concerned with assuring the
+identity of a party participating in a data exchange. These families are related
+to assuring the identity of the originator of transmitted information (proof of
+origin) and assuring the identity of the recipient of transmitted information
+(proof of receipt). These families ensure that an originator cannot deny
+having sent the message, nor can the recipient deny having received it.
+
+
+**Figure 8 - FCO: Communication class decomposition**
+
+
+April 2017 Version 3.1 Page 43 of 323
+
+
+**Class FCO: Communication**
+
+## **9.1 Non-repudiation of origin (FCO_NRO)**
+
+
+Family Behaviour
+
+
+128 Non-repudiation of origin ensures that the originator of information cannot
+successfully deny having sent the information. This family requires that the
+TSF provide a method to ensure that a subject that receives information
+during a data exchange is provided with evidence of the origin of the
+information. This evidence can then be verified by either this subject or other
+subjects.
+
+
+Component levelling
+
+
+129 FCO_NRO.1 Selective proof of origin, requires the TSF to provide subjects
+with the capability to request evidence of the origin of information.
+
+
+130 FCO_NRO.2 Enforced proof of origin, requires that the TSF always generate
+evidence of origin for transmitted information.
+
+
+Management: FCO_NRO.1, FCO_NRO.2
+
+
+131 The following actions could be considered for the management functions in
+FMT:
+
+
+a) The management of changes to information types, fields, originator
+attributes and recipients of evidence.
+
+
+Audit: FCO_NRO.1
+
+
+132 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: The identity of the user who requested that evidence of
+origin would be generated.
+
+
+b) Minimal: The invocation of the non-repudiation service.
+
+
+c) Basic: Identification of the information, the destination, and a copy of
+the evidence provided.
+
+
+d) Detailed: The identity of the user who requested a verification of the
+evidence.
+
+
+Audit: FCO_NRO.2
+
+
+133 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: The invocation of the non-repudiation service.
+
+
+Page 44 of 323 Version 3.1 April 2017
+
+
+**Class FCO: Communication**
+
+
+b) Basic: Identification of the information, the destination, and a copy of
+the evidence provided.
+
+
+c) Detailed: The identity of the user who requested a verification of the
+evidence.
+
+
+**FCO_NRO.1** **Selective proof of origin**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FIA_UID.1 Timing of identification
+
+
+**FCO_NRO.1.1** **The TSF shall be able to generate evidence of origin for transmitted**
+
+**[assignment:** _**list of information types**_ **] at the request of the [selection:**
+_**originator, recipient, [assignment: list of third parties]**_ **].**
+
+
+**FCO_NRO.1.2** **The TSF shall be able to relate the [assignment:** _**list of attributes**_ **] of the**
+**originator of the information, and the [assignment:** _**list of information**_
+_**fields**_ **] of the information to which the evidence applies.**
+
+
+**FCO_NRO.1.3** **The TSF shall provide a capability to verify the evidence of origin of**
+**information to [selection:** _**originator, recipient, [assignment: list of third**_
+_**parties]**_ **] given [assignment:** _**limitations on the evidence of origin**_ **].**
+
+
+**FCO_NRO.2** **Enforced proof of origin**
+
+
+Hierarchical to: FCO_NRO.1 Selective proof of origin
+
+
+Dependencies: FIA_UID.1 Timing of identification
+
+
+**FCO_NRO.2.1** The TSF shall **enforce** **the** **generation** **of** evidence of origin for transmitted
+
+[assignment: _list of information types_ ] at **all** **times.**
+
+
+**FCO_NRO.2.2** The TSF shall be able to relate the [assignment: _list of attributes_ ] of the
+originator of the information, and the [assignment: _list of information fields_ ]
+of the information to which the evidence applies.
+
+
+**FCO_NRO.2.3** The TSF shall provide a capability to verify the evidence of origin of
+information to [selection: _originator, recipient, [assignment: list of third_
+_parties]_ ] given [assignment: _limitations on the evidence of origin_ ].
+
+
+April 2017 Version 3.1 Page 45 of 323
+
+
+**Class FCO: Communication**
+
+## **9.2 Non-repudiation of receipt (FCO_NRR)**
+
+
+Family Behaviour
+
+
+134 Non-repudiation of receipt ensures that the recipient of information cannot
+successfully deny receiving the information. This family requires that the
+TSF provide a method to ensure that a subject that transmits information
+during a data exchange is provided with evidence of receipt of the
+information. This evidence can then be verified by either this subject or other
+subjects.
+
+
+Component levelling
+
+
+135 FCO_NRR.1 Selective proof of receipt, requires the TSF to provide subjects
+with a capability to request evidence of the receipt of information.
+
+
+136 FCO_NRR.2 Enforced proof of receipt, requires that the TSF always
+generate evidence of receipt for received information.
+
+
+Management: FCO_NRR.1, FCO_NRR.2
+
+
+137 The following actions could be considered for the management functions in
+FMT:
+
+
+a) The management of changes to information types, fields, originator
+attributes and third parties recipients of evidence.
+
+
+Audit: FCO_NRR.1
+
+
+138 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: The identity of the user who requested that evidence of
+receipt would be generated.
+
+
+b) Minimal: The invocation of the non-repudiation service.
+
+
+c) Basic: Identification of the information, the destination, and a copy of
+the evidence provided.
+
+
+d) Detailed: The identity of the user who requested a verification of the
+evidence.
+
+
+Audit: FCO_NRR.2
+
+
+139 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: The invocation of the non-repudiation service.
+
+
+Page 46 of 323 Version 3.1 April 2017
+
+
+**Class FCO: Communication**
+
+
+b) Basic: Identification of the information, the destination, and a copy of
+the evidence provided.
+
+
+c) Detailed: The identity of the user who requested a verification of the
+evidence.
+
+
+**FCO_NRR.1** **Selective proof of receipt**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FIA_UID.1 Timing of identification
+
+
+**FCO_NRR.1.1** **The TSF shall be able to generate evidence of receipt for received**
+
+**[assignment:** _**list of information types**_ **] at the request of the [selection:**
+_**originator, recipient, [assignment: list of third parties]**_ **].**
+
+
+**FCO_NRR.1.2** **The TSF shall be able to relate the [assignment:** _**list of attributes**_ **] of the**
+**recipient of the information, and the [assignment:** _**list of information**_
+_**fields**_ **] of the information to which the evidence applies.**
+
+
+**FCO_NRR.1.3** **The TSF shall provide a capability to verify the evidence of receipt of**
+**information to [selection:** _**originator, recipient, [assignment: list of third**_
+_**parties]**_ **] given [assignment:** _**limitations on the evidence of receipt**_ **].**
+
+
+**FCO_NRR.2** **Enforced proof of receipt**
+
+
+Hierarchical to: FCO_NRR.1 Selective proof of receipt
+
+
+Dependencies: FIA_UID.1 Timing of identification
+
+
+**FCO_NRR.2.1** The TSF shall **enforce** **the** **generation** **of** evidence of receipt for received
+
+[assignment: _list of information types_ ] at **all** **times.**
+
+
+**FCO_NRR.2.2** The TSF shall be able to relate the [assignment: _list of attributes_ ] of the
+recipient of the information, and the [assignment: _list of information fields_ ]
+of the information to which the evidence applies.
+
+
+**FCO_NRR.2.3** The TSF shall provide a capability to verify the evidence of receipt of
+information to [selection: _originator, recipient, [assignment: list of third_
+_parties]_ ] given [assignment: _limitations on the evidence of receipt_ ].
+
+
+April 2017 Version 3.1 Page 47 of 323
+
+
+**Class FCS: Cryptographic support**
+
+# **10 Class FCS: Cryptographic support**
+
+
+140 The TSF may employ cryptographic functionality to help satisfy several
+high-level security objectives. These include (but are not limited to):
+identification and authentication, non-repudiation, trusted path, trusted
+channel and data separation. This class is used when the TOE implements
+cryptographic functions, the implementation of which could be in hardware,
+firmware and/or software.
+
+
+141 The FCS: Cryptographic support class is composed of two families:
+Cryptographic key management (FCS_CKM) and Cryptographic operation
+(FCS_COP). The Cryptographic key management (FCS_CKM) family
+addresses the management aspects of cryptographic keys, while the
+Cryptographic operation (FCS_COP) family is concerned with the
+operational use of those cryptographic keys.
+
+
+**Figure 9 - FCS: Cryptographic support class decomposition**
+
+
+Page 48 of 323 Version 3.1 April 2017
+
+
+**Class FCS: Cryptographic support**
+
+## **10.1 Cryptographic key management (FCS_CKM)**
+
+
+Family Behaviour
+
+
+142 Cryptographic keys must be managed throughout their life cycle. This family
+is intended to support that lifecycle and consequently defines requirements
+for the following activities: cryptographic key generation, cryptographic key
+distribution, cryptographic key access and cryptographic key destruction.
+This family should be included whenever there are functional requirements
+for the management of cryptographic keys.
+
+
+Component levelling
+
+
+143 FCS_CKM.1 Cryptographic key generation, requires cryptographic keys to
+be generated in accordance with a specified algorithm and key sizes which
+can be based on an assigned standard.
+
+
+144 FCS_CKM.2 Cryptographic key distribution, requires cryptographic keys to
+be distributed in accordance with a specified distribution method which can
+be based on an assigned standard.
+
+
+145 FCS_CKM.3 Cryptographic key access, requires access to cryptographic
+keys to be performed in accordance with a specified access method which
+can be based on an assigned standard.
+
+
+146 FCS_CKM.4 Cryptographic key destruction, requires cryptographic keys to
+be destroyed in accordance with a specified destruction method which can be
+based on an assigned standard.
+
+
+Management: FCS_CKM.1, FCS_CKM.2, FCS_CKM.3, FCS_CKM.4
+
+
+147 There are no management activities foreseen.
+
+
+Audit: FCS_CKM.1, FCS_CKM.2, FCS_CKM.3, FCS_CKM.4
+
+
+148 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+April 2017 Version 3.1 Page 49 of 323
+
+
+**Class FCS: Cryptographic support**
+
+
+a) Minimal: Success and failure of the activity.
+
+
+b) Basic: The object attribute(s), and object value(s) excluding any
+sensitive information (e.g. secret or private keys).
+
+
+**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** **[assignment:**
+_**cryptographic key generation algorithm**_ **] and specified cryptographic key**
+**sizes [assignment:** _**cryptographic key sizes**_ **] that meet the following:**
+
+**[assignment:** _**list of standards**_ **].**
+
+
+**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** **[assignment:**
+_**cryptographic key distribution method**_ **] that meets the following:**
+
+**[assignment:** _**list of standards**_ **].**
+
+
+**FCS_CKM.3** **Cryptographic key access**
+
+
+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.3.1** **The TSF shall perform [assignment:** _**type of cryptographic key access**_ **] in**
+**accordance with a specified cryptographic key access method**
+
+**[assignment:** _**cryptographic key access method**_ **] that meets the following:**
+
+**[assignment:** _**list of standards**_ **].**
+
+
+Page 50 of 323 Version 3.1 April 2017
+
+
+**Class FCS: Cryptographic support**
+
+
+**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 [assignment:** _**cryptographic key**_
+_**destruction method**_ **] that meets the following: [assignment:** _**list of**_
+_**standards**_ **].**
+
+
+April 2017 Version 3.1 Page 51 of 323
+
+
+**Class FCS: Cryptographic support**
+
+## **10.2 Cryptographic operation (FCS_COP)**
+
+
+Family Behaviour
+
+
+149 In order for a cryptographic operation to function correctly, the operation
+must be performed in accordance with a specified algorithm and with a
+cryptographic key of a specified size. This family should be included
+whenever there are requirements for cryptographic operations to be
+performed.
+
+
+150 Typical cryptographic operations include data encryption and/or decryption,
+digital signature generation and/or verification, cryptographic checksum
+generation for integrity and/or verification of checksum, secure hash
+(message digest), cryptographic key encryption and/or decryption, and
+cryptographic key agreement.
+
+
+Component levelling
+
+
+151 FCS_COP.1 Cryptographic operation, requires a cryptographic operation to
+be performed in accordance with a specified algorithm and with a
+cryptographic key of specified sizes. The specified algorithm and
+cryptographic key sizes can be based on an assigned standard.
+
+
+Management: FCS_COP.1
+
+
+152 There are no management activities foreseen.
+
+
+Audit: FCS_COP.1
+
+
+153 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Success and failure, and the type of cryptographic operation.
+
+
+b) Basic: Any applicable cryptographic mode(s) of operation, subject
+attributes and object attributes.
+
+
+**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
+
+
+Page 52 of 323 Version 3.1 April 2017
+
+
+**Class FCS: Cryptographic support**
+
+
+**FCS_COP.1.1** **The TSF shall perform [assignment:** _**list of cryptographic operations**_ **] in**
+**accordance with a specified cryptographic algorithm [assignment:**
+_**cryptographic algorithm**_ **] and cryptographic key sizes [assignment:**
+_**cryptographic key sizes**_ **] that meet the following: [assignment:** _**list of**_
+_**standards**_ **].**
+
+
+April 2017 Version 3.1 Page 53 of 323
+
+
+**Class FDP: User data protection**
+
+# **11 Class FDP: User data protection**
+
+
+154 This class contains families specifying requirements related to protecting
+user data. FDP: User data protection is split into four groups of families
+(listed below) that address user data within a TOE, during import, export,
+and storage as well as security attributes directly related to user data.
+
+
+155 The families in this class are organised into four groups:
+
+
+a) User data protection security function policies:
+
+
+๏ญ Access control policy (FDP_ACC); and
+
+
+๏ญ Information flow control policy (FDP_IFC).
+
+
+Components in these families permit the PP/ST author to name the
+user data protection security function policies and define the scope of
+control of the policy, necessary to address the security objectives.
+The names of these policies are meant to be used throughout the
+remainder of the functional components that have an operation that
+calls for an assignment or selection of an "access control SFP" or an
+"information flow control SFP". The rules that define the
+functionality of the named access control and information flow
+control SFPs will be defined in the Access control functions
+(FDP_ACF) and Information flow control functions (FDP_IFF)
+families (respectively).
+
+
+b) Forms of user data protection:
+
+
+๏ญ Access control functions (FDP_ACF);
+
+
+๏ญ Information flow control functions (FDP_IFF);
+
+
+๏ญ Internal TOE transfer (FDP_ITT);
+
+
+๏ญ Residual information protection (FDP_RIP);
+
+
+๏ญ Rollback (FDP_ROL); and
+
+
+๏ญ Stored data integrity (FDP_SDI).
+
+
+c) Off-line storage, import and export:
+
+
+๏ญ Data authentication (FDP_DAU);
+
+
+๏ญ Export from the TOE (FDP_ETC);
+
+
+๏ญ Import from outside of the TOE (FDP_ITC).
+
+
+Page 54 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+
+Components in these families address the trustworthy transfer into or
+out of the TOE.
+
+
+d) Inter-TSF communication:
+
+
+๏ญ Inter-TSF user data confidentiality transfer protection
+(FDP_UCT); and
+
+
+๏ญ Inter-TSF user data integrity transfer protection (FDP_UIT).
+
+
+Components in these families address communication between the
+TSF of the TOE and another trusted IT product.
+
+
+April 2017 Version 3.1 Page 55 of 323
+
+
+**Class FDP: User data protection**
+
+
+**Figure 10 - FDP: User data protection class decomposition**
+
+
+Page 56 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+## **11.1 Access control policy (FDP_ACC)**
+
+
+Family Behaviour
+
+
+156 This family identifies the access control SFPs (by name) and defines the
+scope of control of the policies that form the identified access control portion
+of the SFRs related to the SFP. This scope of control is characterised by
+three sets: the subjects under control of the policy, the objects under control
+of the policy, and the operations among controlled subjects and controlled
+objects that are covered by the policy. The criteria allows multiple policies to
+exist, each having a unique name. This is accomplished by iterating
+components from this family once for each named access control policy. The
+rules that define the functionality of an access control SFP will be defined by
+other families such as Access control functions (FDP_ACF) and Export from
+the TOE (FDP_ETC). The names of the access control SFPs identified here
+in Access control policy (FDP_ACC) are meant to be used throughout the
+remainder of the functional components that have an operation that calls for
+an assignment or selection of an โaccess control SFP.โ
+
+
+Component levelling
+
+
+157 FDP_ACC.1 Subset access control, requires that each identified access
+control SFP be in place for a subset of the possible operations on a subset of
+the objects in the TOE.
+
+
+158 FDP_ACC.2 Complete access control, requires that each identified access
+control SFP cover all operations on subjects and objects covered by that SFP.
+It further requires that all objects and operations protected by the TSF are
+covered by at least one identified access control SFP.
+
+
+Management: FDP_ACC.1, FDP_ACC.2
+
+
+159 There are no management activities foreseen.
+
+
+Audit: FDP_ACC.1, FDP_ACC.2
+
+
+160 There are no auditable events foreseen.
+
+
+**FDP_ACC.1** **Subset access control**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FDP_ACF.1 Security attribute based access control
+
+
+**FDP_ACC.1.1** **The TSF shall enforce the [assignment:** _**access control SFP**_ **] on**
+
+**[assignment:** _**list of subjects, objects, and operations among subjects and**_
+_**objects covered by the SFP**_ **].**
+
+
+April 2017 Version 3.1 Page 57 of 323
+
+
+**Class FDP: User data protection**
+
+
+**FDP_ACC.2** **Complete access control**
+
+
+Hierarchical to: FDP_ACC.1 Subset access control
+
+
+Dependencies: FDP_ACF.1 Security attribute based access control
+
+
+**FDP_ACC.2.1** The TSF shall enforce the [assignment: _access control SFP_ ] on [assignment:
+_list of subjects and_ _**objects**_ **]** **and** **all** operations among subjects and objects
+covered by the **SFP.**
+
+
+**FDP_ACC.2.2** **The TSF shall ensure that all operations between any subject controlled**
+**by the TSF and any object controlled by the TSF are covered by an**
+**access control SFP.**
+
+
+Page 58 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+## **11.2 Access control functions (FDP_ACF)**
+
+
+Family Behaviour
+
+
+161 This family describes the rules for the specific functions that can implement
+an access control policy named in Access control policy (FDP_ACC).
+Access control policy (FDP_ACC) specifies the scope of control of the
+policy.
+
+
+Component levelling
+
+
+162 This family addresses security attribute usage and characteristics of policies.
+The component within this family is meant to be used to describe the rules
+for the function that implements the SFP as identified in Access control
+policy (FDP_ACC). The PP/ST author may also iterate this component to
+address multiple policies in the TOE.
+
+
+163 FDP_ACF.1 Security attribute based access control Security attribute based
+access control allows the TSF to enforce access based upon security
+attributes and named groups of attributes. Furthermore, the TSF may have
+the ability to explicitly authorise or deny access to an object based upon
+security attributes.
+
+
+Management: FDP_ACF.1
+
+
+164 The following actions could be considered for the management functions in
+FMT:
+
+
+a) Managing the attributes used to make explicit access or denial based
+decisions.
+
+
+Audit: FDP_ACF.1
+
+
+165 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Successful requests to perform an operation on an object
+covered by the SFP.
+
+
+b) Basic: All requests to perform an operation on an object covered by
+the SFP.
+
+
+c) Detailed: The specific security attributes used in making an access
+check.
+
+
+April 2017 Version 3.1 Page 59 of 323
+
+
+**Class FDP: User data protection**
+
+
+**FDP_ACF.1** **Security attribute based access control**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FDP_ACC.1 Subset access control
+FMT_MSA.3 Static attribute initialisation
+
+
+**FDP_ACF.1.1** **The TSF shall enforce the [assignment:** _**access control SFP**_ **] to objects**
+**based on the following: [assignment:** _**list of subjects and objects controlled**_
+_**under the indicated SFP, and for each, the SFP-relevant security attributes,**_
+_**or named groups of SFP-relevant security attributes**_ **].**
+
+
+**FDP_ACF.1.2** **The TSF shall enforce the following rules to determine if an operation**
+**among controlled subjects and controlled objects is allowed:**
+
+**[assignment:** _**rules governing access among controlled subjects and**_
+_**controlled objects using controlled operations on controlled objects**_ **].**
+
+
+**FDP_ACF.1.3** **The TSF shall explicitly authorise access of subjects to objects based on**
+**the following additional rules: [assignment:** _**rules, based on security**_
+_**attributes, that explicitly authorise access of subjects to objects**_ **].**
+
+
+**FDP_ACF.1.4** **The TSF shall explicitly deny access of subjects to objects based on the**
+**following additional rules: [assignment:** _**rules, based on security attributes,**_
+_**that explicitly deny access of subjects to objects**_ **].**
+
+
+Page 60 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+## **11.3 Data authentication (FDP_DAU)**
+
+
+Family Behaviour
+
+
+166 Data authentication permits an entity to accept responsibility for the
+authenticity of information (e.g., by digitally signing it). This family
+provides a method of providing a guarantee of the validity of a specific unit
+of data that can be subsequently used to verify that the information content
+has not been forged or fraudulently modified. In contrast to FAU: Security
+audit, this family is intended to be applied to "static" data rather than data
+that is being transferred.
+
+
+Component levelling
+
+
+167 FDP_DAU.1 Basic Data Authentication, requires that the TSF is capable of
+generating a guarantee of authenticity of the information content of objects
+(e.g. documents).
+
+
+168 FDP_DAU.2 Data Authentication with Identity of Guarantor additionally
+requires that the TSF is capable of establishing the identity of the subject
+who provided the guarantee of authenticity.
+
+
+Management: FDP_DAU.1, FDP_DAU.2
+
+
+169 The following actions could be considered for the management functions in
+FMT:
+
+
+a) The assignment or modification of the objects for which data
+authentication may apply could be configurable.
+
+
+Audit: FDP_DAU.1
+
+
+170 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Successful generation of validity evidence.
+
+
+b) Basic: Unsuccessful generation of validity evidence.
+
+
+c) Detailed: The identity of the subject that requested the evidence.
+
+
+Audit: FDP_DAU.2
+
+
+171 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Successful generation of validity evidence.
+
+
+b) Basic: Unsuccessful generation of validity evidence.
+
+
+April 2017 Version 3.1 Page 61 of 323
+
+
+**Class FDP: User data protection**
+
+
+c) Detailed: The identity of the subject that requested the evidence.
+
+
+d) Detailed: The identity of the subject that generated the evidence.
+
+
+**FDP_DAU.1** **Basic Data Authentication**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FDP_DAU.1.1** **The TSF shall provide a capability to generate evidence that can be used**
+**as a guarantee of the validity of [assignment:** _**list of objects or**_
+_**information types**_ **].**
+
+
+**FDP_DAU.1.2** **The TSF shall provide [assignment:** _**list of subjects**_ **] with the ability to**
+**verify evidence of the validity of the indicated information.**
+
+
+**FDP_DAU.2** **Data Authentication with Identity of Guarantor**
+
+
+Hierarchical to: FDP_DAU.1 Basic Data Authentication
+
+
+Dependencies: FIA_UID.1 Timing of identification
+
+
+**FDP_DAU.2.1** The TSF shall provide a capability to generate evidence that can be used as a
+guarantee of the validity of [assignment: _list of objects or information types_ ].
+
+
+**FDP_DAU.2.2** The TSF shall provide [assignment: _list of subjects_ ] with the ability to verify
+evidence of the validity of the indicated information **and** **the** **identity** **of** **the**
+**user** **that** **generated** **the** **evidence.**
+
+
+Page 62 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+## **11.4 Export from the TOE (FDP_ETC)**
+
+
+Family Behaviour
+
+
+172 This family defines functions for TSF-mediated exporting of user data from
+the TOE such that its security attributes and protection either can be
+explicitly preserved or can be ignored once it has been exported. It is
+concerned with limitations on export and with the association of security
+attributes with the exported user data.
+
+
+Component levelling
+
+
+173 FDP_ETC.1 Export of user data without security attributes, requires that the
+TSF enforce the appropriate SFPs when exporting user data outside the TSF.
+User data that is exported by this function is exported without its associated
+security attributes.
+
+
+174 FDP_ETC.2 Export of user data with security attributes, requires that the
+TSF enforce the appropriate SFPs using a function that accurately and
+unambiguously associates security attributes with the user data that is
+exported.
+
+
+Management: FDP_ETC.1
+
+
+175 There are no management activities foreseen.
+
+
+Management: FDP_ETC.2
+
+
+176 The following actions could be considered for the management functions in
+FMT:
+
+
+a) The additional exportation control rules could be configurable by a
+user in a defined role.
+
+
+Audit: FDP_ETC.1, FDP_ETC.2
+
+
+177 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Successful export of information.
+
+
+b) Basic: All attempts to export information.
+
+
+April 2017 Version 3.1 Page 63 of 323
+
+
+**Class FDP: User data protection**
+
+
+**FDP_ETC.1** **Export of user data without security attributes**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: [FDP_ACC.1 Subset access control, or
+FDP_IFC.1 Subset information flow control]
+
+
+**FDP_ETC.1.1** **The TSF shall enforce the [assignment:** _**access control SFP(s) and/or**_
+_**information flow control SFP(s)**_ **] when exporting user data, controlled**
+**under the SFP(s), outside of the TOE.**
+
+
+**FDP_ETC.1.2** **The TSF shall export the user data without the user data's associated**
+**security attributes**
+
+
+**FDP_ETC.2** **Export of user data with security attributes**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: [FDP_ACC.1 Subset access control, or
+FDP_IFC.1 Subset information flow control]
+
+
+**FDP_ETC.2.1** **The TSF shall enforce the [assignment:** _**access control SFP(s) and/or**_
+_**information flow control SFP(s)**_ **] when exporting user data, controlled**
+**under the SFP(s), outside of the TOE.**
+
+
+**FDP_ETC.2.2** **The TSF shall export the user data with the user data's associated**
+**security attributes.**
+
+
+**FDP_ETC.2.3** **The TSF shall ensure that the security attributes, when exported outside**
+**the TOE, are unambiguously associated with the exported user data.**
+
+
+**FDP_ETC.2.4** **The TSF shall enforce the following rules when user data is exported**
+**from the TOE: [assignment:** _**additional exportation control rules**_ **].**
+
+
+Page 64 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+## **11.5 Information flow control policy (FDP_IFC)**
+
+
+Family Behaviour
+
+
+178 This family identifies the information flow control SFPs (by name) and
+defines the scope of control for each named information flow control SFP.
+This scope of control is characterised by three sets: the subjects under control
+of the policy, the information under control of the policy, and operations
+which cause controlled information to flow to and from controlled subjects
+covered by the policy. The criteria allows multiple policies to exist, each
+having a unique name. This is accomplished by iterating components from
+this family once for each named information flow control policy. The rules
+that define the functionality of an information flow control SFP will be
+defined by other families such as Information flow control functions
+(FDP_IFF) and Export from the TOE (FDP_ETC). The names of the
+information flow control SFPs identified here in Information flow control
+policy (FDP_IFC) are meant to be used throughout the remainder of the
+functional components that have an operation that calls for an assignment or
+selection of an โinformation flow control SFP.โ
+
+
+179 The TSF mechanism controls the flow of information in accordance with the
+information flow control SFP. Operations that would change the security
+attributes of information are not generally permitted as this would be in
+violation of an information flow control SFP. However, such operations may
+be permitted as exceptions to the information flow control SFP if explicitly
+specified.
+
+
+Component levelling
+
+
+180 FDP_IFC.1 Subset information flow control, requires that each identified
+information flow control SFPs be in place for a subset of the possible
+operations on a subset of information flows in the TOE.
+
+
+181 FDP_IFC.2 Complete information flow control, requires that each identified
+information flow control SFP cover all operations on subjects and
+information covered by that SFP. It further requires that all information
+flows and operations controlled by the TSF are covered by at least one
+identified information flow control SFP.
+
+
+Management: FDP_IFC.1, FDP_IFC.2
+
+
+182 There are no management activities foreseen.
+
+
+Audit: FDP_IFC.1, FDP_IFC.2
+
+
+183 There are no auditable events foreseen.
+
+
+April 2017 Version 3.1 Page 65 of 323
+
+
+**Class FDP: User data protection**
+
+
+**FDP_IFC.1** **Subset information flow control**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FDP_IFF.1 Simple security attributes
+
+
+**FDP_IFC.1.1** **The TSF shall enforce the [assignment:** _**information flow control SFP**_ **] on**
+
+**[assignment:** _**list of subjects, information, and operations that cause**_
+_**controlled information to flow to and from controlled subjects covered by**_
+_**the SFP**_ **].**
+
+
+**FDP_IFC.2** **Complete information flow control**
+
+
+Hierarchical to: FDP_IFC.1 Subset information flow control
+
+
+Dependencies: FDP_IFF.1 Simple security attributes
+
+
+**FDP_IFC.2.1** The TSF shall enforce the [assignment: _information flow control SFP_ ] on
+
+[assignment: _list of subjects and_ _**information**_ **]** **and** **all** operations that cause
+**that** information to flow to and from subjects covered by the **SFP.**
+
+
+**FDP_IFC.2.2** **The TSF shall ensure that all operations that cause any information in**
+**the TOE to flow to and from any subject in the TOE are covered by an**
+**information flow control SFP.**
+
+
+Page 66 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+## **11.6 Information flow control functions (FDP_IFF)**
+
+
+Family Behaviour
+
+
+184 This family describes the rules for the specific functions that can implement
+the information flow control SFPs named in Information flow control policy
+(FDP_IFC), which also specifies the scope of control of the policy. It
+consists of two kinds of requirements: one addressing the common
+information flow function issues, and a second addressing illicit information
+flows (i.e. covert channels). This division arises because the issues
+concerning illicit information flows are, in some sense, orthogonal to the rest
+of an information flow control SFP. By their nature they circumvent the
+information flow control SFP resulting in a violation of the policy. As such,
+they require special functions to either limit or prevent their occurrence.
+
+
+Component levelling
+
+
+185 FDP_IFF.1 Simple security attributes, requires security attributes on
+information, and on subjects that cause that information to flow and on
+subjects that act as recipients of that information. It specifies the rules that
+must be enforced by the function, and describes how security attributes are
+derived by the function.
+
+
+186 FDP_IFF.2 Hierarchical security attributes expands on the requirements of
+FDP_IFF.1 Simple security attributes by requiring that all information flow
+control SFPs in the set of SFRs use hierarchical security attributes that form
+a lattice (as defined in mathematics). **FDP_IFF.2.6** is derived from the
+mathematical properties of a lattice. A lattice consists of a set of elements
+with an ordering relationship with the property defined in the first bullet, a
+least upper bound which is the unique element in the set that is greater or
+equal (in the ordering relationship) than any other element of the lattice, and
+a greatest lower bound, which is the unique element in the set that is smaller
+or equal than any other element of the lattice.
+
+
+187 FDP_IFF.3 Limited illicit information flows, requires the SFP to cover illicit
+information flows, but not necessarily eliminate them.
+
+
+188 FDP_IFF.4 Partial elimination of illicit information flows, requires the SFP
+to cover the elimination of some (but not necessarily all) illicit information
+flows.
+
+
+189 FDP_IFF.5 No illicit information flows, requires SFP to cover the
+elimination of all illicit information flows.
+
+
+April 2017 Version 3.1 Page 67 of 323
+
+
+**Class FDP: User data protection**
+
+
+190 FDP_IFF.6 Illicit information flow monitoring, requires the SFP to monitor
+illicit information flows for specified and maximum capacities.
+
+
+Management: FDP_IFF.1, FDP_IFF.2
+
+
+191 The following actions could be considered for the management functions in
+FMT:
+
+
+a) Managing the attributes used to make explicit access based decisions.
+
+
+Management: FDP_IFF.3, FDP_IFF.4, FDP_IFF.5
+
+
+192 There are no management activities foreseen.
+
+
+Management: FDP_IFF.6
+
+
+193 The following actions could be considered for the management functions in
+FMT:
+
+
+a) The enabling or disabling of the monitoring function.
+
+
+b) Modification of the maximum capacity at which the monitoring
+occurs.
+
+
+Audit: FDP_IFF.1, FDP_IFF.2, FDP_IFF.5
+
+
+194 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Decisions to permit requested information flows.
+
+
+b) Basic: All decisions on requests for information flow.
+
+
+c) Detailed: The specific security attributes used in making an
+information flow enforcement decision.
+
+
+d) Detailed: Some specific subsets of the information that has flowed
+based upon policy goals (e.g. auditing of downgraded material).
+
+
+Audit: FDP_IFF.3, FDP_IFF.4, FDP_IFF.6
+
+
+195 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Decisions to permit requested information flows.
+
+
+b) Basic: All decisions on requests for information flow.
+
+
+c) Basic: The use of identified illicit information flow channels.
+
+
+d) Detailed: The specific security attributes used in making an
+information flow enforcement decision.
+
+
+Page 68 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+
+e) Detailed: Some specific subsets of the information that has flowed
+based upon policy goals (e.g. auditing of downgraded material).
+
+
+f) Detailed: The use of identified illicit information flow channels with
+estimated maximum capacity exceeding a specified value.
+
+
+**FDP_IFF.1** **Simple security attributes**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FDP_IFC.1 Subset information flow control
+FMT_MSA.3 Static attribute initialisation
+
+
+**FDP_IFF.1.1** **The TSF shall enforce the [assignment:** _**information flow control SFP**_ **]**
+**based on the following types of subject and information security**
+**attributes: [assignment:** _**list of subjects and information controlled under**_
+_**the indicated SFP, and for each, the security attributes**_ **].**
+
+
+**FDP_IFF.1.2** **The TSF shall permit an information flow between a controlled subject**
+**and controlled information via a controlled operation if the following**
+**rules hold: [assignment:** _**for each operation, the security attribute-based**_
+_**relationship that must hold between subject and information security**_
+_**attributes**_ **].**
+
+
+**FDP_IFF.1.3** **The TSF shall enforce the [assignment:** _**additional information flow**_
+_**control SFP rules**_ **].**
+
+
+**FDP_IFF.1.4** **The TSF shall explicitly authorise an information flow based on the**
+**following rules: [assignment:** _**rules, based on security attributes, that**_
+_**explicitly authorise information flows**_ **].**
+
+
+**FDP_IFF.1.5** **The TSF shall explicitly deny an information flow based on the following**
+**rules: [assignment:** _**rules, based on security attributes, that explicitly deny**_
+_**information flows**_ **].**
+
+
+**FDP_IFF.2** **Hierarchical security attributes**
+
+
+Hierarchical to: FDP_IFF.1 Simple security attributes
+
+
+Dependencies: FDP_IFC.1 Subset information flow control
+FMT_MSA.3 Static attribute initialisation
+
+
+**FDP_IFF.2.1** The TSF shall enforce the [assignment: _information flow control SFP_ ] based
+on the following types of subject and information security attributes:
+
+[assignment: _list of subjects and information controlled under the indicated_
+_SFP, and for each, the security attributes_ ].
+
+
+**FDP_IFF.2.2** The TSF shall permit an information flow between a controlled subject and
+controlled information via a controlled operation if the following rules,
+**based** **on** **the** **ordering** **relationships** **between** **security** **attributes** hold:
+
+[assignment: _for each operation, the security attribute-based relationship_
+_that must hold between subject and information security attributes_ ].
+
+
+April 2017 Version 3.1 Page 69 of 323
+
+
+**Class FDP: User data protection**
+
+
+**FDP_IFF.2.3** The TSF shall enforce the [assignment: _additional information flow control_
+_SFP rules_ ].
+
+
+**FDP_IFF.2.4** The TSF shall explicitly authorise an information flow based on the
+following rules: [assignment: _rules, based on security attributes, that_
+_explicitly authorise information flows_ ].
+
+
+**FDP_IFF.2.5** The TSF shall explicitly deny an information flow based on the following
+rules: [assignment: _rules, based on security attributes, that explicitly deny_
+_information flows_ ].
+
+
+**FDP_IFF.2.6** **The TSF shall enforce the following relationships for any two valid**
+**information flow control security attributes:**
+
+
+**a)** **There exists an ordering function that, given two valid security**
+**attributes, determines if the security attributes are equal, if one**
+**security attribute is greater than the other, or if the security**
+**attributes are incomparable; and**
+
+
+**b)** **There exists a โleast upper boundโ in the set of security**
+**attributes, such that, given any two valid security attributes,**
+**there is a valid security attribute that is greater than or equal to**
+**the two valid security attributes; and**
+
+
+**c)** **There exists a โgreatest lower boundโ in the set of security**
+**attributes, such that, given any two valid security attributes,**
+**there is a valid security attribute that is not greater than the two**
+**valid security attributes.**
+
+
+**FDP_IFF.3** **Limited illicit information flows**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FDP_IFC.1 Subset information flow control
+
+
+**FDP_IFF.3.1** **The TSF shall enforce the [assignment:** _**information flow control SFP**_ **] to**
+**limit the capacity of [assignment:** _**types of illicit information flows**_ **] to a**
+
+**[assignment:** _**maximum capacity**_ **].**
+
+
+**FDP_IFF.4** **Partial elimination of illicit information flows**
+
+
+Hierarchical to: FDP_IFF.3 Limited illicit information flows
+
+
+Dependencies: FDP_IFC.1 Subset information flow control
+
+
+**FDP_IFF.4.1** The TSF shall enforce the [assignment: _information flow control SFP_ ] to
+limit the capacity of [assignment: _types of illicit information flows_ ] to a
+
+[assignment: _maximum capacity_ ].
+
+
+**FDP_IFF.4.2** **The TSF shall prevent [assignment:** _**types of illicit information flows**_ **].**
+
+
+Page 70 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+
+**FDP_IFF.5** **No illicit information flows**
+
+
+Hierarchical to: FDP_IFF.4 Partial elimination of illicit information
+flows
+
+
+Dependencies: FDP_IFC.1 Subset information flow control
+
+
+**FDP_IFF.5.1** The TSF shall **ensure** **that** **no** **illicit** **information** **flows** **exist** **to** **circumvent**
+
+[assignment: _**name**_ _**of**_ _**information**_ _flow control SFP_ ].
+
+
+**FDP_IFF.6** **Illicit information flow monitoring**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FDP_IFC.1 Subset information flow control
+
+
+**FDP_IFF.6.1** **The TSF shall enforce the [assignment:** _**information flow control SFP**_ **] to**
+**monitor [assignment:** _**types of illicit information flows**_ **] when it exceeds**
+**the [assignment:** _**maximum capacity**_ **].**
+
+
+April 2017 Version 3.1 Page 71 of 323
+
+
+**Class FDP: User data protection**
+
+## **11.7 Import from outside of the TOE (FDP_ITC)**
+
+
+Family Behaviour
+
+
+196 This family defines the mechanisms for TSF-mediated importing of user data
+into the TOE such that it has appropriate security attributes and is
+appropriately protected. It is concerned with limitations on importation,
+determination of desired security attributes, and interpretation of security
+attributes associated with the user data.
+
+
+Component levelling
+
+
+197 FDP_ITC.1 Import of user data without security attributes, requires that the
+security attributes correctly represent the user data and are supplied
+separately from the object.
+
+
+198 FDP_ITC.2 Import of user data with security attributes, requires that security
+attributes correctly represent the user data and are accurately and
+unambiguously associated with the user data imported from outside the TOE.
+
+
+Management: FDP_ITC.1, FDP_ITC.2
+
+
+199 The following actions could be considered for the management functions in
+FMT:
+
+
+a) The modification of the additional control rules used for import.
+
+
+Audit: FDP_ITC.1, FDP_ITC.2
+
+
+200 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Successful import of user data, including any security
+attributes.
+
+
+b) Basic: All attempts to import user data, including any security
+attributes.
+
+
+c) Detailed: The specification of security attributes for imported user
+data supplied by an authorised user.
+
+
+Page 72 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+
+**FDP_ITC.1** **Import of user data without security attributes**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: [FDP_ACC.1 Subset access control, or
+FDP_IFC.1 Subset information flow control]
+FMT_MSA.3 Static attribute initialisation
+
+
+**FDP_ITC.1.1** **The TSF shall enforce the [assignment:** _**access control SFP(s) and/or**_
+_**information flow control SFP(s)**_ **] when importing user data, controlled**
+**under the SFP, from outside of the TOE.**
+
+
+**FDP_ITC.1.2** **The TSF shall ignore any security attributes associated with the user**
+**data when imported from outside the TOE.**
+
+
+**FDP_ITC.1.3** **The TSF shall enforce the following rules when importing user data**
+**controlled under the SFP from outside the TOE: [assignment:** _**additional**_
+_**importation control rules**_ **].**
+
+
+**FDP_ITC.2** **Import of user data with security attributes**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: [FDP_ACC.1 Subset access control, or
+FDP_IFC.1 Subset information flow control]
+
+[FTP_ITC.1 Inter-TSF trusted channel, or
+FTP_TRP.1 Trusted path]
+FPT_TDC.1 Inter-TSF basic TSF data consistency
+
+
+**FDP_ITC.2.1** **The TSF shall enforce the [assignment:** _**access control SFP(s) and/or**_
+_**information flow control SFP(s)**_ **] when importing user data, controlled**
+**under the SFP, from outside of the TOE.**
+
+
+**FDP_ITC.2.2** **The TSF shall use the security attributes associated with the imported**
+**user data.**
+
+
+**FDP_ITC.2.3** **The TSF shall ensure that the protocol used provides for the**
+**unambiguous association between the security attributes and the user**
+**data received.**
+
+
+**FDP_ITC.2.4** **The TSF shall ensure that interpretation of the security attributes of the**
+**imported user data is as intended by the source of the user data.**
+
+
+**FDP_ITC.2.5** **The TSF shall enforce the following rules when importing user data**
+**controlled under the SFP from outside the TOE: [assignment:** _**additional**_
+_**importation control rules**_ **].**
+
+
+April 2017 Version 3.1 Page 73 of 323
+
+
+**Class FDP: User data protection**
+
+## **11.8 Internal TOE transfer (FDP_ITT)**
+
+
+Family Behaviour
+
+
+201 This family provides requirements that address protection of user data when
+it is transferred between separated parts of a TOE across an internal channel.
+This may be contrasted with the Inter-TSF user data confidentiality transfer
+protection (FDP_UCT) and Inter-TSF user data integrity transfer protection
+(FDP_UIT) families, which provide protection for user data when it is
+transferred between distinct TSFs across an external channel, and Export
+from the TOE (FDP_ETC) and Import from outside of the TOE (FDP_ITC),
+which address TSF-mediated transfer of data to or from outside the TOE.
+
+
+Component levelling
+
+
+202 FDP_ITT.1 Basic internal transfer protection, requires that user data be
+protected when transmitted between parts of the TOE.
+
+
+203 FDP_ITT.2 Transmission separation by attribute, requires separation of data
+based on the value of SFP-relevant attributes in addition to the first
+component.
+
+
+204 FDP_ITT.3 Integrity monitoring, requires that the TSF monitor user data
+transmitted between parts of the TOE for identified integrity errors.
+
+
+205 FDP_ITT.4 Attribute-based integrity monitoring expands on the third
+component by allowing the form of integrity monitoring to differ by SFPrelevant attribute.
+
+
+Management: FDP_ITT.1, FDP_ITT.2
+
+
+206 The following actions could be considered for the management functions in
+FMT:
+
+
+a) If the TSF provides multiple methods to protect user data during
+transmission between physically separated parts of the TOE, the TSF
+could provide a pre-defined role with the ability to select the method
+that will be used.
+
+
+Management: FDP_ITT.3, FDP_ITT.4
+
+
+207 The following actions could be considered for the management functions in
+FMT:
+
+
+Page 74 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+
+a) The specification of the actions to be taken upon detection of an
+integrity error could be configurable.
+
+
+Audit: FDP_ITT.1, FDP_ITT.2
+
+
+208 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Successful transfers of user data, including identification of
+the protection method used.
+
+
+b) Basic: All attempts to transfer user data, including the protection
+method used and any errors that occurred.
+
+
+Audit: FDP_ITT.3, FDP_ITT.4
+
+
+209 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Successful transfers of user data, including identification of
+the integrity protection method used.
+
+
+b) Basic: All attempts to transfer user data, including the integrity
+protection method used and any errors that occurred.
+
+
+c) Basic: Unauthorised attempts to change the integrity protection
+method.
+
+
+d) Detailed: The action taken upon detection of an integrity error.
+
+
+**FDP_ITT.1** **Basic internal transfer protection**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: [FDP_ACC.1 Subset access control, or
+FDP_IFC.1 Subset information flow control]
+
+
+**FDP_ITT.1.1** **The TSF shall enforce the [assignment:** _**access control SFP(s) and/or**_
+_**information flow control SFP(s)**_ **] to prevent the [selection:** _**disclosure,**_
+_**modification, loss of use**_ **] of user data when it is transmitted between**
+**physically-separated parts of the TOE.**
+
+
+**FDP_ITT.2** **Transmission separation by attribute**
+
+
+Hierarchical to: FDP_ITT.1 Basic internal transfer protection
+
+
+Dependencies: [FDP_ACC.1 Subset access control, or
+FDP_IFC.1 Subset information flow control]
+
+
+**FDP_ITT.2.1** The TSF shall enforce the [assignment: _access control SFP(s) and/or_
+_information flow control SFP(s)_ ] to prevent the [selection: _disclosure,_
+
+
+April 2017 Version 3.1 Page 75 of 323
+
+
+**Class FDP: User data protection**
+
+
+_modification, loss of use_ ] of user data when it is transmitted between
+physically-separated parts of the TOE.
+
+
+**FDP_ITT.2.2** **The TSF shall separate data controlled by the SFP(s) when transmitted**
+**between physically-separated parts of the TOE, based on the values of**
+**the following: [assignment:** _**security attributes that require separation**_ **].**
+
+
+**FDP_ITT.3** **Integrity monitoring**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: [FDP_ACC.1 Subset access control, or
+FDP_IFC.1 Subset information flow control]
+FDP_ITT.1 Basic internal transfer protection
+
+
+**FDP_ITT.3.1** **The TSF shall enforce the [assignment:** _**access control SFP(s) and/or**_
+_**information flow control SFP(s)**_ **] to monitor user data transmitted**
+**between physically-separated parts of the TOE for the following errors:**
+
+**[assignment:** _**integrity errors**_ **].**
+
+
+**FDP_ITT.3.2** **Upon detection of a data integrity error, the TSF shall [assignment:**
+_**specify the action to be taken upon integrity error**_ **].**
+
+
+**FDP_ITT.4** **Attribute-based integrity monitoring**
+
+
+Hierarchical to: FDP_ITT.3 Integrity monitoring
+
+
+Dependencies: [FDP_ACC.1 Subset access control, or
+FDP_IFC.1 Subset information flow control]
+FDP_ITT.2 Transmission separation by attribute
+
+
+**FDP_ITT.4.1** The TSF shall enforce the [assignment: _access control SFP(s) and/or_
+_information flow control SFP(s)_ ] to monitor user data transmitted between
+physically-separated parts of the TOE for the following errors: [assignment:
+_integrity errors_ ], **based** **on** **the** **following** **attributes:** **[assignment:** _**security**_
+_**attributes**_ _**that**_ _**require**_ _**separate**_ _**transmission**_ _**channels**_ **].**
+
+
+**FDP_ITT.4.2** Upon detection of a data integrity error, the TSF shall [assignment: _specify_
+_the action to be taken upon integrity error_ ].
+
+
+Page 76 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+## **11.9 Residual information protection (FDP_RIP)**
+
+
+Family Behaviour
+
+
+210 This family addresses the need to ensure that any data contained in a
+resource is not available when the resource is de-allocated from one object
+and reallocated to a different object. This family requires protection for any
+data contained in a resource that has been logically deleted or released, but
+may still be present within the TSF-controlled resource which in turn may be
+re-allocated to another object.
+
+
+Component levelling
+
+
+211 FDP_RIP.1 Subset residual information protection, requires that the TSF
+ensure that any residual information content of any resources is unavailable
+to a defined subset of the objects controlled by the TSF upon the resource's
+allocation or deallocation.
+
+
+212 FDP_RIP.2 Full residual information protection, requires that the TSF ensure
+that any residual information content of any resources is unavailable to all
+objects upon the resource's allocation or deallocation.
+
+
+Management: FDP_RIP.1, FDP_RIP.2
+
+
+213 The following actions could be considered for the management functions in
+FMT:
+
+
+a) The choice of when to perform residual information protection (i.e.
+upon allocation or deallocation) could be made configurable within
+the TOE.
+
+
+Audit: FDP_RIP.1, FDP_RIP.2
+
+
+214 There are no auditable events foreseen.
+
+
+**FDP_RIP.1** **Subset residual information protection**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FDP_RIP.1.1** **The TSF shall ensure that any previous information content of a**
+**resource is made unavailable upon the [selection:** _**allocation of the**_
+_**resource to, deallocation of the resource from**_ **] the following objects:**
+
+**[assignment:** _**list of objects**_ **].**
+
+
+April 2017 Version 3.1 Page 77 of 323
+
+
+**Class FDP: User data protection**
+
+
+**FDP_RIP.2** **Full residual information protection**
+
+
+Hierarchical to: FDP_RIP.1 Subset residual information protection
+
+
+Dependencies: No dependencies.
+
+
+**FDP_RIP.2.1** The TSF shall ensure that any previous information content of a resource is
+made unavailable upon the [selection: _allocation of the resource to,_
+_deallocation of the resource from_ ] **all** objects.
+
+
+Page 78 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+## **11.10 Rollback (FDP_ROL)**
+
+
+Family Behaviour
+
+
+215 The rollback operation involves undoing the last operation or a series of
+operations, bounded by some limit, such as a period of time, and return to a
+previous known state. Rollback provides the ability to undo the effects of an
+operation or series of operations to preserve the integrity of the user data.
+
+
+Component levelling
+
+
+216 FDP_ROL.1 Basic rollback addresses a need to roll back or undo a limited
+number of operations within the defined bounds.
+
+
+217 FDP_ROL.2 Advanced rollback addresses the need to roll back or undo all
+operations within the defined bounds.
+
+
+Management: FDP_ROL.1, FDP_ROL.2
+
+
+218 The following actions could be considered for the management functions in
+FMT:
+
+
+a) The boundary limit to which rollback may be performed could be a
+configurable item within the TOE.
+
+
+b) Permission to perform a rollback operation could be restricted to a
+well defined role.
+
+
+Audit: FDP_ROL.1, FDP_ROL.2
+
+
+219 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: All successful rollback operations.
+
+
+b) Basic: All attempts to perform rollback operations.
+
+
+c) Detailed: All attempts to perform rollback operations, including
+identification of the types of operations rolled back.
+
+
+**FDP_ROL.1** **Basic rollback**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: [FDP_ACC.1 Subset access control, or
+FDP_IFC.1 Subset information flow control]
+
+
+**FDP_ROL.1.1** **The TSF shall enforce [assignment:** _**access control SFP(s) and/or**_
+_**information flow control SFP(s)**_ **] to permit the rollback of the**
+
+
+April 2017 Version 3.1 Page 79 of 323
+
+
+**Class FDP: User data protection**
+
+
+**[assignment:** _**list of operations**_ **] on the [assignment:** _**information and/or**_
+_**list of objects**_ **].**
+
+
+**FDP_ROL.1.2** **The TSF shall permit operations to be rolled back within the**
+
+**[assignment:** _**boundary limit to which rollback may be performed**_ **].**
+
+
+**FDP_ROL.2** **Advanced rollback**
+
+
+Hierarchical to: FDP_ROL.1 Basic rollback
+
+
+Dependencies: [FDP_ACC.1 Subset access control, or
+FDP_IFC.1 Subset information flow control]
+
+
+**FDP_ROL.2.1** The TSF shall enforce [assignment: _access control SFP(s) and/or_
+_information flow control SFP(s)_ ] to permit the rollback of **all** the **operations**
+on the [assignment: _**list**_ _of objects_ ].
+
+
+**FDP_ROL.2.2** The TSF shall permit operations to be rolled back within the [assignment:
+_boundary limit to which rollback may be performed_ ].
+
+
+Page 80 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+## **11.11 Stored data integrity (FDP_SDI)**
+
+
+Family Behaviour
+
+
+220 This family provides requirements that address protection of user data while
+it is stored within containers controlled by the TSF. Integrity errors may
+affect user data stored in memory, or in a storage device. This family differs
+from Internal TOE transfer (FDP_ITT) which protects the user data from
+integrity errors while being transferred within the TOE.
+
+
+Component levelling
+
+
+221 FDP_SDI.1 Stored data integrity monitoring, requires that the TSF monitor
+user data stored within containers controlled by the TSF for identified
+integrity errors.
+
+
+222 FDP_SDI.2 Stored data integrity monitoring and action adds the additional
+capability to the first component by allowing for actions to be taken as a
+result of an error detection.
+
+
+Management: FDP_SDI.1
+
+
+223 There are no management activities foreseen.
+
+
+Management: FDP_SDI.2
+
+
+224 The following actions could be considered for the management functions in
+FMT:
+
+
+a) The actions to be taken upon the detection of an integrity error could
+be configurable.
+
+
+Audit: FDP_SDI.1
+
+
+225 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Successful attempts to check the integrity of user data,
+including an indication of the results of the check.
+
+
+b) Basic: All attempts to check the integrity of user data, including an
+indication of the results of the check, if performed.
+
+
+c) Detailed: The type of integrity error that occurred.
+
+
+Audit: FDP_SDI.2
+
+
+226 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+April 2017 Version 3.1 Page 81 of 323
+
+
+**Class FDP: User data protection**
+
+
+a) Minimal: Successful attempts to check the integrity of user data,
+including an indication of the results of the check.
+
+
+b) Basic: All attempts to check the integrity of user data, including an
+indication of the results of the check, if performed.
+
+
+c) Detailed: The type of integrity error that occurred.
+
+
+d) Detailed: The action taken upon detection of an integrity error.
+
+
+**FDP_SDI.1** **Stored data integrity monitoring**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FDP_SDI.1.1** **The TSF shall monitor user data stored in containers controlled by the**
+**TSF for [assignment:** _**integrity errors**_ **] on all objects, based on the**
+**following attributes: [assignment:** _**user data attributes**_ **].**
+
+
+**FDP_SDI.2** **Stored data integrity monitoring and action**
+
+
+Hierarchical to: FDP_SDI.1 Stored data integrity monitoring
+
+
+Dependencies: No dependencies.
+
+
+**FDP_SDI.2.1** The TSF shall monitor user data stored in containers controlled by the TSF
+for [assignment: _integrity errors_ ] on all objects, based on the following
+attributes: [assignment: _user data attributes_ ].
+
+
+**FDP_SDI.2.2** **Upon detection of a data integrity error, the TSF shall [assignment:**
+_**action to be taken**_ **].**
+
+
+Page 82 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+## **11.12 Inter-TSF user data confidentiality transfer protection** **(FDP_UCT)**
+
+
+Family Behaviour
+
+
+227 This family defines the requirements for ensuring the confidentiality of user
+data when it is transferred using an external channel between the TOE and
+another trusted IT product.
+
+
+Component levelling
+
+
+228 In FDP_UCT.1 Basic data exchange confidentiality, the goal is to provide
+protection from disclosure of user data while in transit.
+
+
+Management: FDP_UCT.1
+
+
+229 There are no management activities foreseen.
+
+
+Audit: FDP_UCT.1
+
+
+230 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: The identity of any user or subject using the data exchange
+mechanisms.
+
+
+b) Basic: The identity of any unauthorised user or subject attempting to
+use the data exchange mechanisms.
+
+
+c) Basic: A reference to the names or other indexing information useful
+in identifying the user data that was transmitted or received. This
+could include security attributes associated with the information.
+
+
+**FDP_UCT.1** **Basic data exchange confidentiality**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: [FTP_ITC.1 Inter-TSF trusted channel, or
+FTP_TRP.1 Trusted path]
+
+[FDP_ACC.1 Subset access control, or
+FDP_IFC.1 Subset information flow control]
+
+
+**FDP_UCT.1.1** **The TSF shall enforce the [assignment:** _**access control SFP(s) and/or**_
+_**information flow control SFP(s)**_ **] to [selection:** _**transmit, receive**_ **] user data**
+**in a manner protected from unauthorised disclosure.**
+
+
+April 2017 Version 3.1 Page 83 of 323
+
+
+**Class FDP: User data protection**
+
+## **11.13 Inter-TSF user data integrity transfer protection** **(FDP_UIT)**
+
+
+Family Behaviour
+
+
+231 This family defines the requirements for providing integrity for user data in
+transit between the TOE and another trusted IT product and recovering from
+detectable errors. At a minimum, this family monitors the integrity of user
+data for modifications. Furthermore, this family supports different ways of
+correcting detected integrity errors.
+
+
+Component levelling
+
+
+232 FDP_UIT.1 Data exchange integrity addresses detection of modifications,
+deletions, insertions, and replay errors of the user data transmitted.
+
+
+233 FDP_UIT.2 Source data exchange recovery addresses recovery of the
+original user data by the receiving TSF with help from the source trusted IT
+product.
+
+
+234 FDP_UIT.3 Destination data exchange recovery addresses recovery of the
+original user data by the receiving TSF on its own without any help from the
+source trusted IT product.
+
+
+Management: FDP_UIT.1, FDP_UIT.2, FDP_UIT.3
+
+
+235 There are no management activities foreseen.
+
+
+Audit: FDP_UIT.1
+
+
+236 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: The identity of any user or subject using the data exchange
+mechanisms.
+
+
+b) Basic: The identity of any user or subject attempting to use the user
+data exchange mechanisms, but who is unauthorised to do so.
+
+
+c) Basic: A reference to the names or other indexing information useful
+in identifying the user data that was transmitted or received. This
+could include security attributes associated with the user data.
+
+
+d) Basic: Any identified attempts to block transmission of user data.
+
+
+Page 84 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+
+e) Detailed: The types and/or effects of any detected modifications of
+transmitted user data.
+
+
+Audit: FDP_UIT.2, FDP_UIT.3
+
+
+237 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: The identity of any user or subject using the data exchange
+mechanisms.
+
+
+b) Minimal: Successful recovery from errors including they type of error
+that was detected.
+
+
+c) Basic: The identity of any user or subject attempting to use the user
+data exchange mechanisms, but who is unauthorised to do so.
+
+
+d) Basic: A reference to the names or other indexing information useful
+in identifying the user data that was transmitted or received. This
+could include security attributes associated with the user data.
+
+
+e) Basic: Any identified attempts to block transmission of user data.
+
+
+f) Detailed: The types and/or effects of any detected modifications of
+transmitted user data.
+
+
+**FDP_UIT.1** **Data exchange integrity**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: [FDP_ACC.1 Subset access control, or
+FDP_IFC.1 Subset information flow control]
+
+[FTP_ITC.1 Inter-TSF trusted channel, or
+FTP_TRP.1 Trusted path]
+
+
+**FDP_UIT.1.1** **The TSF shall enforce the [assignment:** _**access control SFP(s) and/or**_
+_**information flow control SFP(s)**_ **] to [selection:** _**transmit, receive**_ **] user data**
+**in a manner protected from [selection:** _**modification, deletion, insertion,**_
+_**replay**_ **] errors.**
+
+
+**FDP_UIT.1.2** **The TSF shall be able to determine on receipt of user data, whether**
+
+**[selection:** _**modification, deletion, insertion, replay**_ **] has occurred.**
+
+
+**FDP_UIT.2** **Source data exchange recovery**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: [FDP_ACC.1 Subset access control, or
+FDP_IFC.1 Subset information flow control]
+
+[FDP_UIT.1 Data exchange integrity, or
+FTP_ITC.1 Inter-TSF trusted channel]
+
+
+April 2017 Version 3.1 Page 85 of 323
+
+
+**Class FDP: User data protection**
+
+
+**FDP_UIT.2.1** **The TSF shall enforce the [assignment:** _**access control SFP(s) and/or**_
+_**information flow control SFP(s)**_ **] to be able to recover from [assignment:**
+_**list of recoverable errors**_ **] with the help of the source trusted IT product.**
+
+
+**FDP_UIT.3** **Destination data exchange recovery**
+
+
+Hierarchical to: FDP_UIT.2 Source data exchange recovery
+
+
+Dependencies: [FDP_ACC.1 Subset access control, or
+FDP_IFC.1 Subset information flow control]
+
+[FDP_UIT.1 Data exchange integrity, or
+FTP_ITC.1 Inter-TSF trusted channel]
+
+
+**FDP_UIT.3.1** The TSF shall enforce the [assignment: _access control SFP(s) and/or_
+_information flow control SFP(s)_ ] to be able to recover from [assignment: _list_
+_of recoverable errors_ ] **without** **any** help **from** the source trusted IT product.
+
+
+Page 86 of 323 Version 3.1 April 2017
+
+
+**Class FIA: Identification and authentication**
+
+# **12 Class FIA: Identification and authentication**
+
+
+238 Families in this class address the requirements for functions to establish and
+verify a claimed user identity.
+
+
+239 Identification and Authentication is required to ensure that users are
+associated with the proper security attributes (e.g. identity, groups, roles,
+security or integrity levels).
+
+
+240 The unambiguous identification of authorised users and the correct
+association of security attributes with users and subjects is critical to the
+enforcement of the intended security policies. The families in this class deal
+with determining and verifying the identity of users, determining their
+authority to interact with the TOE, and with the correct association of
+security attributes for each authorised user. Other classes of requirements
+(e.g. User Data Protection, Security Audit) are dependent upon correct
+identification and authentication of users in order to be effective.
+
+
+April 2017 Version 3.1 Page 87 of 323
+
+
+**Class FIA: Identification and authentication**
+
+
+**Figure 11 - FIA: Identification and authentication class decomposition**
+
+
+Page 88 of 323 Version 3.1 April 2017
+
+
+**Class FIA: Identification and authentication**
+
+## **12.1 Authentication failures (FIA_AFL)**
+
+
+Family Behaviour
+
+
+241 This family contains requirements for defining values for some number of
+unsuccessful authentication attempts and TSF actions in cases of
+authentication attempt failures. Parameters include, but are not limited to, the
+number of failed authentication attempts and time thresholds.
+
+
+Component levelling
+
+
+242 FIA_AFL.1 Authentication failure handling, requires that the TSF be able to
+terminate the session establishment process after a specified number of
+unsuccessful user authentication attempts. It also requires that, after
+termination of the session establishment process, the TSF be able to disable
+the user account or the point of entry (e.g. workstation) from which the
+attempts were made until an administrator-defined condition occurs.
+
+
+Management: FIA_AFL.1
+
+
+243 The following actions could be considered for the management functions in
+FMT:
+
+
+a) management of the threshold for unsuccessful authentication
+attempts;
+
+
+b) management of actions to be taken in the event of an authentication
+failure.
+
+
+Audit: FIA_AFL.1
+
+
+244 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: the reaching of the threshold for the unsuccessful
+authentication attempts and the actions (e.g. disabling of a terminal)
+taken and the subsequent, if appropriate, restoration to the normal
+state (e.g. re-enabling of a terminal).
+
+
+**FIA_AFL.1** **Authentication failure handling**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FIA_UAU.1 Timing of authentication
+
+
+**FIA_AFL.1.1** **The TSF shall detect when [selection:** _**[assignment: positive integer**_
+_**number],**_ _**an**_ _**administrator**_ _**configurable**_ _**positive**_ _**integer**_
+_**within[assignment:**_ _**range**_ _**of**_ _**acceptable**_ _**values]**_ **]** **unsuccessful**
+
+
+April 2017 Version 3.1 Page 89 of 323
+
+
+**Class FIA: Identification and authentication**
+
+
+**authentication** **attempts** **occur** **related** **to** **[assignment:** _**list**_ _**of**_
+_**authentication events**_ **].**
+
+
+**FIA_AFL.1.2** **When the defined number of unsuccessful authentication attempts has**
+**been [selection:** _**met, surpassed**_ **], the TSF shall [assignment:** _**list of**_
+_**actions**_ **].**
+
+
+Page 90 of 323 Version 3.1 April 2017
+
+
+**Class FIA: Identification and authentication**
+
+## **12.2 User attribute definition (FIA_ATD)**
+
+
+Family Behaviour
+
+
+245 All authorised users may have a set of security attributes, other than the
+user's identity, that is used to enforce the SFRs. This family defines the
+requirements for associating user security attributes with users as needed to
+support the TSF in making security decisions.
+
+
+Component levelling
+
+
+246 FIA_ATD.1 User attribute definition, allows user security attributes for each
+user to be maintained individually.
+
+
+Management: FIA_ATD.1
+
+
+247 The following actions could be considered for the management functions in
+FMT:
+
+
+a) if so indicated in the assignment, the authorised administrator might
+be able to define additional security attributes for users.
+
+
+Audit: FIA_ATD.1
+
+
+248 There are no auditable events foreseen.
+
+
+**FIA_ATD.1** **User attribute definition**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FIA_ATD.1.1** **The TSF shall maintain the following list of security attributes belonging**
+**to individual users: [assignment:** _**list of security attributes**_ **].**
+
+
+April 2017 Version 3.1 Page 91 of 323
+
+
+**Class FIA: Identification and authentication**
+
+## **12.3 Specification of secrets (FIA_SOS)**
+
+
+Family Behaviour
+
+
+249 This family defines requirements for mechanisms that enforce defined
+quality metrics on provided secrets and generate secrets to satisfy the defined
+metric.
+
+
+Component levelling
+
+
+250 FIA_SOS.1 Verification of secrets, requires the TSF to verify that secrets
+meet defined quality metrics.
+
+
+251 FIA_SOS.2 TSF Generation of secrets, requires the TSF to be able to
+generate secrets that meet defined quality metrics.
+
+
+Management: FIA_SOS.1
+
+
+252 The following actions could be considered for the management functions in
+FMT:
+
+
+a) the management of the metric used to verify the secrets.
+
+
+Management: FIA_SOS.2
+
+
+253 The following actions could be considered for the management functions in
+FMT:
+
+
+a) the management of the metric used to generate the secrets.
+
+
+Audit: FIA_SOS.1, FIA_SOS.2
+
+
+254 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Rejection by the TSF of any tested secret;
+
+
+b) Basic: Rejection or acceptance by the TSF of any tested secret;
+
+
+c) Detailed: Identification of any changes to the defined quality metrics.
+
+
+Page 92 of 323 Version 3.1 April 2017
+
+
+**Class FIA: Identification and authentication**
+
+
+**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**
+
+**[assignment:** _**a defined quality metric**_ **].**
+
+
+**FIA_SOS.2** **TSF Generation of secrets**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FIA_SOS.2.1** **The TSF shall provide a mechanism to generate secrets that meet**
+
+**[assignment:** _**a defined quality metric**_ **].**
+
+
+**FIA_SOS.2.2** **The TSF shall be able to enforce the use of TSF generated secrets for**
+
+**[assignment:** _**list of TSF functions**_ **].**
+
+
+April 2017 Version 3.1 Page 93 of 323
+
+
+**Class FIA: Identification and authentication**
+
+## **12.4 User authentication (FIA_UAU)**
+
+
+Family Behaviour
+
+
+255 This family defines the types of user authentication mechanisms supported
+by the TSF. This family also defines the required attributes on which the user
+authentication mechanisms must be based.
+
+
+Component levelling
+
+
+256 FIA_UAU.1 Timing of authentication, allows a user to perform certain
+actions prior to the authentication of the user's identity.
+
+
+257 FIA_UAU.2 User authentication before any action, requires that users are
+authenticated before any other action will be allowed by the TSF.
+
+
+258 FIA_UAU.3 Unforgeable authentication Unforgeable authentication,
+requires the authentication mechanism to be able to detect and prevent the
+use of authentication data that has been forged or copied.
+
+
+259 FIA_UAU.4 Single-use authentication mechanisms, requires an
+authentication mechanism that operates with single-use authentication data.
+
+
+260 FIA_UAU.5 Multiple authentication mechanisms, requires that different
+authentication mechanisms be provided and used to authenticate user
+identities for specific events.
+
+
+261 FIA_UAU.6 Re-authenticating, requires the ability to specify events for
+which the user needs to be re-authenticated.
+
+
+262 FIA_UAU.7 Protected authentication feedback, requires that only limited
+feedback information is provided to the user during the authentication.
+
+
+Page 94 of 323 Version 3.1 April 2017
+
+
+**Class FIA: Identification and authentication**
+
+
+Management: FIA_UAU.1
+
+
+263 The following actions could be considered for the management functions in
+FMT:
+
+
+a) management of the authentication data by an administrator;
+
+
+b) management of the authentication data by the associated user;
+
+
+c) managing the list of actions that can be taken before the user is
+authenticated.
+
+
+Management: FIA_UAU.2
+
+
+264 The following actions could be considered for the management functions in
+FMT:
+
+
+a) management of the authentication data by an administrator;
+
+
+b) management of the authentication data by the user associated with
+this data.
+
+
+Management: FIA_UAU.3, FIA_UAU.4, FIA_UAU.7
+
+
+265 There are no management activities foreseen.
+
+
+Management: FIA_UAU.5
+
+
+266 The following actions could be considered for the management functions in
+FMT:
+
+
+a) the management of authentication mechanisms;
+
+
+b) the management of the rules for authentication.
+
+
+Management: FIA_UAU.6
+
+
+267 The following actions could be considered for the management functions in
+FMT:
+
+
+a) if an authorised administrator could request re-authentication, the
+management includes a re-authentication request.
+
+
+Audit: FIA_UAU.1
+
+
+268 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Unsuccessful use of the authentication mechanism;
+
+
+b) Basic: All use of the authentication mechanism;
+
+
+April 2017 Version 3.1 Page 95 of 323
+
+
+**Class FIA: Identification and authentication**
+
+
+c) Detailed: All TSF mediated actions performed before authentication
+of the user.
+
+
+Audit: FIA_UAU.2
+
+
+269 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Unsuccessful use of the authentication mechanism;
+
+
+b) Basic: All use of the authentication mechanism.
+
+
+Audit: FIA_UAU.3
+
+
+270 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Detection of fraudulent authentication data;
+
+
+b) Basic: All immediate measures taken and results of checks on the
+fraudulent data.
+
+
+Audit: FIA_UAU.4
+
+
+271 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Attempts to reuse authentication data.
+
+
+Audit: FIA_UAU.5
+
+
+272 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: The final decision on authentication;
+
+
+b) Basic: The result of each activated mechanism together with the final
+decision.
+
+
+Audit: FIA_UAU.6
+
+
+273 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Failure of reauthentication;
+
+
+b) Basic: All reauthentication attempts.
+
+
+Audit: FIA_UAU.7
+
+
+274 There are no auditable events foreseen.
+
+
+Page 96 of 323 Version 3.1 April 2017
+
+
+**Class FIA: Identification and authentication**
+
+
+**FIA_UAU.1** **Timing of authentication**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FIA_UID.1 Timing of identification
+
+
+**FIA_UAU.1.1** **The TSF shall allow [assignment:** _**list of TSF mediated actions**_ **] on behalf**
+**of the user to be performed before the user is authenticated.**
+
+
+**FIA_UAU.1.2** **The TSF shall require each user to be successfully authenticated before**
+**allowing any other TSF-mediated actions on behalf of that user.**
+
+
+**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 each user to be successfully authenticated before
+allowing any other TSF-mediated actions on behalf of that user.
+
+
+**FIA_UAU.3** **Unforgeable authentication**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FIA_UAU.3.1** **The TSF shall [selection:** _**detect, prevent**_ **] use of authentication data that**
+**has been forged by any user of the TSF.**
+
+
+**FIA_UAU.3.2** **The TSF shall [selection:** _**detect, prevent**_ **] use of authentication data that**
+**has been copied from any other user of the TSF.**
+
+
+**FIA_UAU.4** **Single-use authentication mechanisms**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FIA_UAU.4.1** **The TSF shall prevent reuse of authentication data related to**
+
+**[assignment:** _**identified authentication mechanism(s)**_ **].**
+
+
+**FIA_UAU.5** **Multiple authentication mechanisms**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FIA_UAU.5.1** **The TSF shall provide [assignment:** _**list of multiple authentication**_
+_**mechanisms**_ **] to support user authentication.**
+
+
+April 2017 Version 3.1 Page 97 of 323
+
+
+**Class FIA: Identification and authentication**
+
+
+**FIA_UAU.5.2** **The TSF shall authenticate any user's claimed identity according to the**
+
+**[assignment:** _**rules**_ _**describing**_ _**how**_ _**the**_ _**multiple**_ _**authentication**_
+_**mechanisms provide authentication**_ **].**
+
+
+**FIA_UAU.6** **Re-authenticating**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FIA_UAU.6.1** **The TSF shall re-authenticate the user under the conditions**
+
+**[assignment:** _**list of conditions under which re-authentication is required**_ **].**
+
+
+**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 [assignment:** _**list of feedback**_ **] to the user**
+**while the authentication is in progress.**
+
+
+Page 98 of 323 Version 3.1 April 2017
+
+
+**Class FIA: Identification and authentication**
+
+## **12.5 User identification (FIA_UID)**
+
+
+Family Behaviour
+
+
+275 This family defines the conditions under which users shall be required to
+identify themselves before performing any other actions that are to be
+mediated by the TSF and which require user identification.
+
+
+Component levelling
+
+
+276 FIA_UID.1 Timing of identification, allows users to perform certain actions
+before being identified by the TSF.
+
+
+277 FIA_UID.2 User identification before any action, requires that users identify
+themselves before any other action will be allowed by the TSF.
+
+
+Management: FIA_UID.1
+
+
+278 The following actions could be considered for the management functions in
+FMT:
+
+
+a) the management of the user identities;
+
+
+b) if an authorised administrator can change the actions allowed before
+identification, the managing of the action lists.
+
+
+Management: FIA_UID.2
+
+
+279 The following actions could be considered for the management functions in
+FMT:
+
+
+a) the management of the user identities.
+
+
+Audit: FIA_UID.1, FIA_UID.2
+
+
+280 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Unsuccessful use of the user identification mechanism,
+including the user identity provided;
+
+
+b) Basic: All use of the user identification mechanism, including the
+user identity provided.
+
+
+April 2017 Version 3.1 Page 99 of 323
+
+
+**Class FIA: Identification and authentication**
+
+
+**FIA_UID.1** **Timing of identification**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FIA_UID.1.1** **The TSF shall allow [assignment:** _**list of TSF-mediated actions**_ **] on behalf**
+**of the user to be performed before the user is identified.**
+
+
+**FIA_UID.1.2** **The TSF shall require each user to be successfully identified before**
+**allowing any other TSF-mediated actions on behalf of that user.**
+
+
+**FIA_UID.2** **User identification before any action**
+
+
+Hierarchical to: FIA_UID.1 Timing of 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.
+
+
+Page 100 of 323 Version 3.1 April 2017
+
+
+**Class FIA: Identification and authentication**
+
+## **12.6 User-subject binding (FIA_USB)**
+
+
+Family Behaviour
+
+
+281 An authenticated user, in order to use the TOE, typically activates a subject.
+The user's security attributes are associated (totally or partially) with this
+subject. This family defines requirements to create and maintain the
+association of the user's security attributes to a subject acting on the user's
+behalf.
+
+
+Component levelling
+
+
+282 FIA_USB.1 User-subject binding, requires the specification of any rules
+governing the association between user attributes and the subject attributes
+into which they are mapped.
+
+
+Management: FIA_USB.1
+
+
+283 The following actions could be considered for the management functions in
+FMT:
+
+
+a) an authorised administrator can define default subject security
+attributes.
+
+
+b) an authorised administrator can change subject security attributes.
+
+
+Audit: FIA_USB.1
+
+
+284 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Unsuccessful binding of user security attributes to a subject
+(e.g. creation of a subject).
+
+
+b) Basic: Success and failure of binding of user security attributes to a
+subject (e.g. success or failure to create a subject).
+
+
+**FIA_USB.1** **User-subject binding**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FIA_ATD.1 User attribute definition
+
+
+**FIA_USB.1.1** **The TSF shall associate the following user security attributes with**
+**subjects acting on the behalf of that user: [assignment:** _**list of user**_
+_**security attributes**_ **].**
+
+
+April 2017 Version 3.1 Page 101 of 323
+
+
+**Class FIA: Identification and authentication**
+
+
+**FIA_USB.1.2** **The TSF shall enforce the following rules on the initial association of**
+**user security attributes with subjects acting on the behalf of users:**
+
+**[assignment:** _**rules for the initial association of attributes**_ **].**
+
+
+**FIA_USB.1.3** **The TSF shall enforce the following rules governing changes to the user**
+**security attributes associated with subjects acting on the behalf of users:**
+
+**[assignment:** _**rules for the changing of attributes**_ **].**
+
+
+Page 102 of 323 Version 3.1 April 2017
+
+
+**Class FMT: Security management**
+
+# **13 Class FMT: Security management**
+
+
+285 This class is intended to specify the management of several aspects of the
+TSF: security attributes, TSF data and functions. The different management
+roles and their interaction, such as separation of capability, can be specified.
+
+
+286 This class has several objectives:
+
+
+a) management of TSF data, which include, for example, banners;
+
+
+b) management of security attributes, which include, for example, the
+Access Control Lists, and Capability Lists;
+
+
+c) management of functions of the TSF, which includes, for example,
+the selection of functions, and rules or conditions influencing the
+behaviour of the TSF;
+
+
+d) definition of security roles.
+
+
+April 2017 Version 3.1 Page 103 of 323
+
+
+**Class FMT: Security management**
+
+
+**Figure 12 - FMT: Security management class decomposition**
+
+
+Page 104 of 323 Version 3.1 April 2017
+
+
+**Class FMT: Security management**
+
+## **13.1 Management of functions in TSF (FMT_MOF)**
+
+
+Family Behaviour
+
+
+287 This family allows authorised users control over the management of
+functions in the TSF. Examples of functions in the TSF include the audit
+functions and the multiple authentication functions.
+
+
+Component levelling
+
+
+288 FMT_MOF.1 Management of security functions behaviour allows the
+authorised users (roles) to manage the behaviour of functions in the TSF that
+use rules or have specified conditions that may be manageable.
+
+
+Management: FMT_MOF.1
+
+
+289 The following actions could be considered for the management functions in
+FMT:
+
+
+a) managing the group of roles that can interact with the functions in the
+TSF;
+
+
+Audit: FMT_MOF.1
+
+
+290 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Basic: All modifications in the behaviour of the functions in the TSF.
+
+
+**FMT_MOF.1** **Management of security functions behaviour**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FMT_SMR.1 Security roles
+FMT_SMF.1 Specification of Management Functions
+
+
+**FMT_MOF.1.1** **The TSF shall restrict the ability to [selection:** _**determine the behaviour of,**_
+
+_**disable, enable, modify the behaviour of**_ **] the functions [assignment:** _**list of**_
+_**functions**_ **] to [assignment:** _**the authorised identified roles**_ **].**
+
+
+April 2017 Version 3.1 Page 105 of 323
+
+
+**Class FMT: Security management**
+
+## **13.2 Management of security attributes (FMT_MSA)**
+
+
+Family Behaviour
+
+
+291 This family allows authorised users control over the management of security
+attributes. This management might include capabilities for viewing and
+modifying of security attributes.
+
+
+Component levelling
+
+
+292 FMT_MSA.1 Management of security attributes allows authorised users
+(roles) to manage the specified security attributes.
+
+
+293 FMT_MSA.2 Secure security attributes ensures that values assigned to
+security attributes are valid with respect to the secure state.
+
+
+294 FMT_MSA.3 Static attribute initialisation ensures that the default values of
+security attributes are appropriately either permissive or restrictive in nature.
+
+
+295 FMT_MSA.4 Security attribute value inheritance allows the rules/policies to
+be specified that will dictate the value to be inherited by a security attribute.
+
+
+Management: FMT_MSA.1
+
+
+296 The following actions could be considered for the management functions in
+FMT:
+
+
+a) managing the group of roles that can interact with the security
+attributes;
+
+
+b) management of rules by which security attributes inherit specified
+values.
+
+
+Management: FMT_MSA.2
+
+
+297 The following actions could be considered for the management functions in
+FMT:
+
+
+Page 106 of 323 Version 3.1 April 2017
+
+
+**Class FMT: Security management**
+
+
+a) management of rules by which security attributes inherit specified
+values.
+
+
+Management: FMT_MSA.3
+
+
+298 The following actions could be considered for the management functions in
+FMT:
+
+
+a) managing the group of roles that can specify initial values;
+
+
+b) managing the permissive or restrictive setting of default values for a
+given access control SFP;
+
+
+c) management of rules by which security attributes inherit specified
+values.
+
+
+Management: FMT_MSA.4
+
+
+299 The following actions could be considered for the management functions in
+FMT:
+
+
+a) specification of the role permitted to establish or modify security
+attributes.
+
+
+Audit: FMT_MSA.1
+
+
+300 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Basic: All modifications of the values of security attributes.
+
+
+Audit: FMT_MSA.2
+
+
+301 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: All offered and rejected values for a security attribute;
+
+
+b) Detailed: All offered and accepted secure values for a security
+attribute.
+
+
+Audit: FMT_MSA.3
+
+
+302 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Basic: Modifications of the default setting of permissive or restrictive
+rules.
+
+
+b) Basic: All modifications of the initial values of security attributes.
+
+
+April 2017 Version 3.1 Page 107 of 323
+
+
+**Class FMT: Security management**
+
+
+Audit: FMT_MSA.4
+
+
+303 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Basic: Modifications of security attributes, possibly with the old
+and/or values of security attributes that were modified.
+
+
+**FMT_MSA.1** **Management of security attributes**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: [FDP_ACC.1 Subset access control, or
+FDP_IFC.1 Subset information flow control]
+FMT_SMR.1 Security roles
+FMT_SMF.1 Specification of Management Functions
+
+
+**FMT_MSA.1.1** **The TSF shall enforce the [assignment:** _**access control SFP(s),**_
+_**information flow control SFP(s)**_ **] to restrict the ability to [selection:**
+_**change_default, query, modify, delete, [assignment: other operations]**_ **] the**
+**security attributes [assignment:** _**list of security attributes**_ **] to [assignment:**
+_**the authorised identified roles**_ **].**
+
+
+**FMT_MSA.2** **Secure security attributes**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: [FDP_ACC.1 Subset access control, or
+FDP_IFC.1 Subset information flow control]
+FMT_MSA.1 Management of security attributes
+FMT_SMR.1 Security roles
+
+
+**FMT_MSA.2.1** **The TSF shall ensure that only secure values are accepted for**
+
+**[assignment:** _**list of security attributes**_ **].**
+
+
+**FMT_MSA.3** **Static attribute initialisation**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FMT_MSA.1 Management of security attributes
+FMT_SMR.1 Security roles
+
+
+**FMT_MSA.3.1** **The TSF shall enforce the [assignment:** _**access control SFP, information**_
+_**flow control SFP**_ **] to provide [selection, choose one of:** _**restrictive,**_
+_**permissive, [assignment: other property]**_ **] default values for security**
+**attributes that are used to enforce the SFP.**
+
+
+**FMT_MSA.3.2** **The TSF shall allow the [assignment:** _**the authorised identified roles**_ **] to**
+**specify alternative initial values to override the default values when an**
+**object or information is created.**
+
+
+Page 108 of 323 Version 3.1 April 2017
+
+
+**Class FMT: Security management**
+
+
+**FMT_MSA.4** **Security attribute value inheritance**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: [FDP_ACC.1 Subset access control, or
+FDP_IFC.1 Subset information flow control]
+
+
+**FMT_MSA.4.1** **The TSF shall use the following rules to set the value of security**
+**attributes: [assignment:** _**rules for setting the values of security attributes**_ **]**
+
+
+April 2017 Version 3.1 Page 109 of 323
+
+
+**Class FMT: Security management**
+
+## **13.3 Management of TSF data (FMT_MTD)**
+
+
+Family Behaviour
+
+
+304 This family allows authorised users (roles) control over the management of
+TSF data. Examples of TSF data include audit information, clock and other
+TSF configuration parameters.
+
+
+Component levelling
+
+
+305 FMT_MTD.1 Management of TSF data allows authorised users to manage
+TSF data.
+
+
+306 FMT_MTD.2 Management of limits on TSF data specifies the action to be
+taken if limits on TSF data are reached or exceeded.
+
+
+307 FMT_MTD.3 Secure TSF data ensures that values assigned to TSF data are
+valid with respect to the secure state.
+
+
+Management: FMT_MTD.1
+
+
+308 The following actions could be considered for the management functions in
+FMT:
+
+
+a) managing the group of roles that can interact with the TSF data.
+
+
+Management: FMT_MTD.2
+
+
+309 The following actions could be considered for the management functions in
+FMT:
+
+
+a) managing the group of roles that can interact with the limits on the
+TSF data.
+
+
+Management: FMT_MTD.3
+
+
+310 There are no management activities foreseen.
+
+
+Page 110 of 323 Version 3.1 April 2017
+
+
+**Class FMT: Security management**
+
+
+Audit: FMT_MTD.1
+
+
+311 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Basic: All modifications to the values of TSF data.
+
+
+Audit: FMT_MTD.2
+
+
+312 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Basic: All modifications to the limits on TSF data;
+
+
+b) Basic: All modifications in the actions to be taken in case of violation
+of the limits.
+
+
+Audit: FMT_MTD.3
+
+
+313 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: All rejected values of TSF data.
+
+
+**FMT_MTD.1** **Management of TSF data**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FMT_SMR.1 Security roles
+FMT_SMF.1 Specification of Management Functions
+
+
+**FMT_MTD.1.1** **The TSF shall restrict the ability to [selection:** _**change_default, query,**_
+_**modify, delete, clear, [assignment: other operations]**_ **] the [assignment:** _**list**_
+_**of TSF data**_ **] to [assignment:** _**the authorised identified roles**_ **].**
+
+
+**FMT_MTD.2** **Management of limits on TSF data**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FMT_MTD.1 Management of TSF data
+FMT_SMR.1 Security roles
+
+
+**FMT_MTD.2.1** **The TSF shall restrict the specification of the limits for [assignment:** _**list**_
+_**of TSF data**_ **] to [assignment:** _**the authorised identified roles**_ **].**
+
+
+**FMT_MTD.2.2** **The TSF shall take the following actions, if the TSF data are at, or**
+**exceed, the indicated limits: [assignment:** _**actions to be taken**_ **].**
+
+
+April 2017 Version 3.1 Page 111 of 323
+
+
+**Class FMT: Security management**
+
+
+**FMT_MTD.3** **Secure TSF data**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FMT_MTD.1 Management of TSF data
+
+
+**FMT_MTD.3.1** **The TSF shall ensure that only secure values are accepted for**
+
+**[assignment:** _**list of TSF data**_ **].**
+
+
+Page 112 of 323 Version 3.1 April 2017
+
+
+**Class FMT: Security management**
+
+## **13.4 Revocation (FMT_REV)**
+
+
+Family Behaviour
+
+
+314 This family addresses revocation of security attributes for a variety of entities
+within a TOE.
+
+
+Component levelling
+
+
+315 FMT_REV.1 Revocation provides for revocation of security attributes to be
+enforced at some point in time.
+
+
+Management: FMT_REV.1
+
+
+316 The following actions could be considered for the management functions in
+FMT:
+
+
+a) managing the group of roles that can invoke revocation of security
+attributes;
+
+
+b) managing the lists of users, subjects, objects and other resources for
+which revocation is possible;
+
+
+c) managing the revocation rules.
+
+
+Audit: FMT_REV.1
+
+
+317 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Unsuccessful revocation of security attributes;
+
+
+b) Basic: All attempts to revoke security attributes.
+
+
+**FMT_REV.1** **Revocation**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FMT_SMR.1 Security roles
+
+
+**FMT_REV.1.1** **The TSF shall restrict the ability to revoke [assignment:** _**list of security**_
+_**attributes**_ **] associated with the [selection:** _**users, subjects, objects,**_
+
+_**[assignment: other additional resources]**_ **] under the control of the TSF to**
+
+**[assignment:** _**the authorised identified roles**_ **].**
+
+
+**FMT_REV.1.2** **The TSF shall enforce the rules [assignment:** _**specification of revocation**_
+_**rules**_ **].**
+
+
+April 2017 Version 3.1 Page 113 of 323
+
+
+**Class FMT: Security management**
+
+## **13.5 Security attribute expiration (FMT_SAE)**
+
+
+Family Behaviour
+
+
+318 This family addresses the capability to enforce time limits for the validity of
+security attributes.
+
+
+Component levelling
+
+
+319 FMT_SAE.1 Time-limited authorisation provides the capability for an
+authorised user to specify an expiration time on specified security attributes.
+
+
+Management: FMT_SAE.1
+
+
+320 The following actions could be considered for the management functions in
+FMT:
+
+
+a) managing the list of security attributes for which expiration is to be
+supported;
+
+
+b) the actions to be taken if the expiration time has passed.
+
+
+Audit: FMT_SAE.1
+
+
+321 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Basic: Specification of the expiration time for an attribute;
+
+
+b) Basic: Action taken due to attribute expiration.
+
+
+**FMT_SAE.1** **Time-limited authorisation**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FMT_SMR.1 Security roles
+FPT_STM.1 Reliable time stamps
+
+
+**FMT_SAE.1.1** **The TSF shall restrict the capability to specify an expiration time for**
+
+**[assignment:** _**list of security attributes for which expiration is to be**_
+_**supported**_ **] to [assignment:** _**the authorised identified roles**_ **].**
+
+
+**FMT_SAE.1.2** **For each of these security attributes, the TSF shall be able to**
+
+**[assignment:** _**list of actions to be taken for each security attribute**_ **] after**
+**the expiration time for the indicated security attribute has passed.**
+
+
+Page 114 of 323 Version 3.1 April 2017
+
+
+**Class FMT: Security management**
+
+## **13.6 Specification of Management Functions (FMT_SMF)**
+
+
+Family Behaviour
+
+
+322 This family allows the specification of the management functions to be
+provided by the TOE. Management functions provide TSFI that allow
+administrators to define the parameters that control the operation of securityrelated aspects of the TOE, such as data protection attributes, TOE protection
+attributes, audit attributes, and identification and authentication attributes.
+Management functions also include those functions performed by an operator
+to ensure continued operation of the TOE, such as backup and recovery. This
+family works in conjunction with the other components in the FMT: Security
+management class: the component in this family calls out the management
+functions, and other families in FMT: Security management restrict the
+ability to use these management functions.
+
+
+Component levelling
+
+
+323 FMT_SMF.1 Specification of Management Functions requires that the TSF
+provide specific management functions.
+
+
+Management: FMT_SMF.1
+
+
+324 There are no management activities foreseen.
+
+
+Audit: FMT_SMF.1
+
+
+325 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Use of the management functions.
+
+
+**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: [assignment:** _**list of management functions to be provided by the**_
+_**TSF**_ **].**
+
+
+April 2017 Version 3.1 Page 115 of 323
+
+
+**Class FMT: Security management**
+
+## **13.7 Security management roles (FMT_SMR)**
+
+
+Family Behaviour
+
+
+326 This family is intended to control the assignment of different roles to users.
+The capabilities of these roles with respect to security management are
+described in the other families in this class.
+
+
+Component levelling
+
+
+327 FMT_SMR.1 Security roles specifies the roles with respect to security that
+the TSF recognises.
+
+
+328 FMT_SMR.2 Restrictions on security roles specifies that in addition to the
+specification of the roles, there are rules that control the relationship between
+the roles.
+
+
+329 FMT_SMR.3 Assuming roles, requires that an explicit request is given to the
+TSF to assume a role.
+
+
+Management: FMT_SMR.1
+
+
+330 The following actions could be considered for the management functions in
+FMT:
+
+
+a) managing the group of users that are part of a role.
+
+
+Management: FMT_SMR.2
+
+
+331 The following actions could be considered for the management functions in
+FMT:
+
+
+a) managing the group of users that are part of a role;
+
+
+b) managing the conditions that the roles must satisfy.
+
+
+Management: FMT_SMR.3
+
+
+332 There are no management activities foreseen.
+
+
+Audit: FMT_SMR.1
+
+
+333 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: modifications to the group of users that are part of a role;
+
+
+Page 116 of 323 Version 3.1 April 2017
+
+
+**Class FMT: Security management**
+
+
+b) Detailed: every use of the rights of a role.
+
+
+Audit: FMT_SMR.2
+
+
+334 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: modifications to the group of users that are part of a role;
+
+
+b) Minimal: unsuccessful attempts to use a role due to the given
+conditions on the roles;
+
+
+c) Detailed: every use of the rights of a role.
+
+
+Audit: FMT_SMR.3
+
+
+335 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: explicit request to assume a role.
+
+
+**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 [assignment:** _**the authorised identified**_
+_**roles**_ **].**
+
+
+**FMT_SMR.1.2** **The TSF shall be able to associate users with roles.**
+
+
+**FMT_SMR.2** **Restrictions on security roles**
+
+
+Hierarchical to: FMT_SMR.1 Security roles
+
+
+Dependencies: FIA_UID.1 Timing of identification
+
+
+**FMT_SMR.2.1** The TSF shall maintain the roles: [assignment: _**authorised**_ _identified roles_ ].
+
+
+**FMT_SMR.2.2** The TSF shall be able to associate users with roles.
+
+
+**FMT_SMR.2.3** **The TSF shall ensure that the conditions [assignment:** _**conditions for the**_
+_**different roles**_ **] are satisfied.**
+
+
+**FMT_SMR.3** **Assuming roles**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FMT_SMR.1 Security roles
+
+
+**FMT_SMR.3.1** **The TSF shall require an explicit request to assume the following roles:**
+
+**[assignment:** _**the roles**_ **].**
+
+
+April 2017 Version 3.1 Page 117 of 323
+
+
+**Class FPR: Privacy**
+
+# **14 Class FPR: Privacy**
+
+
+336 This class contains privacy requirements. These requirements provide a user
+protection against discovery and misuse of identity by other users.
+
+
+**Figure 13 - FPR: Privacy class decomposition**
+
+
+Page 118 of 323 Version 3.1 April 2017
+
+
+**Class FPR: Privacy**
+
+## **14.1 Anonymity (FPR_ANO)**
+
+
+Family Behaviour
+
+
+337 This family ensures that a user may use a resource or service without
+disclosing the user's identity. The requirements for Anonymity provide
+protection of the user identity. Anonymity is not intended to protect the
+subject identity.
+
+
+Component levelling
+
+
+338 FPR_ANO.1 Anonymity, requires that other users or subjects are unable to
+determine the identity of a user bound to a subject or operation.
+
+
+339 FPR_ANO.2 Anonymity without soliciting information enhances the
+requirements of FPR_ANO.1 Anonymity by ensuring that the TSF does not
+ask for the user identity.
+
+
+Management: FPR_ANO.1, FPR_ANO.2
+
+
+340 There are no management activities foreseen.
+
+
+Audit: FPR_ANO.1, FPR_ANO.2
+
+
+341 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: The invocation of the anonymity mechanism.
+
+
+**FPR_ANO.1** **Anonymity**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FPR_ANO.1.1** **The TSF shall ensure that [assignment:** _**set of users and/or subjects**_ **] are**
+**unable to determine the real user name bound to [assignment:** _**list of**_
+_**subjects and/or operations and/or objects**_ **].**
+
+
+**FPR_ANO.2** **Anonymity without soliciting information**
+
+
+Hierarchical to: FPR_ANO.1 Anonymity
+
+
+Dependencies: No dependencies.
+
+
+**FPR_ANO.2.1** The TSF shall ensure that [assignment: _set of users and/or subjects_ ] are
+unable to determine the real user name bound to [assignment: _list of subjects_
+_and/or operations and/or objects_ ].
+
+
+April 2017 Version 3.1 Page 119 of 323
+
+
+**Class FPR: Privacy**
+
+
+**FPR_ANO.2.2** **The TSF shall provide [assignment:** _**list of services**_ **] to [assignment:** _**list of**_
+_**subjects**_ **] without soliciting any reference to the real user name.**
+
+
+Page 120 of 323 Version 3.1 April 2017
+
+
+**Class FPR: Privacy**
+
+## **14.2 Pseudonymity (FPR_PSE)**
+
+
+Family Behaviour
+
+
+342 This family ensures that a user may use a resource or service without
+disclosing its user identity, but can still be accountable for that use.
+
+
+Component levelling
+
+
+343 FPR_PSE.1 Pseudonymity requires that a set of users and/or subjects are
+unable to determine the identity of a user bound to a subject or operation, but
+that this user is still accountable for its actions.
+
+
+344 FPR_PSE.2 Reversible pseudonymity, requires the TSF to provide a
+capability to determine the original user identity based on a provided alias.
+
+
+345 FPR_PSE.3 Alias pseudonymity, requires the TSF to follow certain
+construction rules for the alias to the user identity.
+
+
+Management: FPR_PSE.1, FPR_PSE.2, FPR_PSE.3
+
+
+346 There are no management activities foreseen.
+
+
+Audit: FPR_PSE.1, FPR_PSE.2, FPR_PSE.3
+
+
+347 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: The subject/user that requested resolution of the user
+identity should be audited.
+
+
+**FPR_PSE.1** **Pseudonymity**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FPR_PSE.1.1** **The TSF shall ensure that [assignment:** _**set of users and/or subjects**_ **] are**
+**unable to determine the real user name bound to [assignment:** _**list of**_
+_**subjects and/or operations and/or objects**_ **].**
+
+
+**FPR_PSE.1.2** **The TSF shall be able to provide [assignment:** _**number of aliases**_ **] aliases**
+**of the real user name to [assignment:** _**list of subjects**_ **].**
+
+
+April 2017 Version 3.1 Page 121 of 323
+
+
+**Class FPR: Privacy**
+
+
+**FPR_PSE.1.3** **The TSF shall [selection, choose one of:** _**determine an alias for a user,**_
+_**accept the alias from the user**_ **] and verify that it conforms to the**
+
+**[assignment:** _**alias metric**_ **].**
+
+
+**FPR_PSE.2** **Reversible pseudonymity**
+
+
+Hierarchical to: FPR_PSE.1 Pseudonymity
+
+
+Dependencies: FIA_UID.1 Timing of identification
+
+
+**FPR_PSE.2.1** The TSF shall ensure that [assignment: _set of users and/or subjects_ ] are
+unable to determine the real user name bound to [assignment: _list of subjects_
+_and/or operations and/or objects_ ].
+
+
+**FPR_PSE.2.2** The TSF shall be able to provide [assignment: _number of aliases_ ] aliases of
+the real user name to [assignment: _list of subjects_ ].
+
+
+**FPR_PSE.2.3** The TSF shall [selection, choose one of: _determine an alias for a user,_
+_accept the alias from the user_ ] and verify that it conforms to the [assignment:
+_alias metric_ ].
+
+
+**FPR_PSE.2.4** **The TSF shall provide [selection:** _**an authorised user, [assignment: list of**_
+_**trusted subjects]**_ **] a capability to determine the user identity based on the**
+**provided alias only under the following [assignment:** _**list of conditions**_ **].**
+
+
+**FPR_PSE.3** **Alias pseudonymity**
+
+
+Hierarchical to: FPR_PSE.1 Pseudonymity
+
+
+Dependencies: No dependencies.
+
+
+**FPR_PSE.3.1** The TSF shall ensure that [assignment: _set of users and/or subjects_ ] are
+unable to determine the real user name bound to [assignment: _list of subjects_
+_and/or operations and/or objects_ ].
+
+
+**FPR_PSE.3.2** The TSF shall be able to provide [assignment: _number of aliases_ ] aliases of
+the real user name to [assignment: _list of subjects_ ].
+
+
+**FPR_PSE.3.3** The TSF shall [selection, choose one of: _determine an alias for a user,_
+_accept the alias from the user_ ] and verify that it conforms to the [assignment:
+_alias metric_ ].
+
+
+**FPR_PSE.3.4** **The TSF shall provide an alias to the real user name which shall be**
+**identical to an alias provided previously under the following**
+
+**[assignment:** _**list of conditions**_ **] otherwise the alias provided shall be**
+**unrelated to previously provided aliases.**
+
+
+Page 122 of 323 Version 3.1 April 2017
+
+
+**Class FPR: Privacy**
+
+## **14.3 Unlinkability (FPR_UNL)**
+
+
+Family Behaviour
+
+
+348 This family ensures that a user may make multiple uses of resources or
+services without others being able to link these uses together.
+
+
+Component levelling
+
+
+349 FPR_UNL.1 Unlinkability, requires that users and/or subjects are unable to
+determine whether the same user caused certain specific operations.
+
+
+Management: FPR_UNL.1
+
+
+350 The following actions could be considered for the management functions in
+FMT:
+
+
+a) the management of the unlinkability function.
+
+
+Audit: FPR_UNL.1
+
+
+351 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: The invocation of the unlinkability mechanism.
+
+
+**FPR_UNL.1** **Unlinkability**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FPR_UNL.1.1** **The TSF shall ensure that [assignment:** _**set of users and/or subjects**_ **] are**
+**unable to determine whether [assignment:** _**list of operations**_ **][selection:**
+_**were caused by the same user, are related as follows[assignment: list of**_
+_**relations]**_ **].**
+
+
+April 2017 Version 3.1 Page 123 of 323
+
+
+**Class FPR: Privacy**
+
+## **14.4 Unobservability (FPR_UNO)**
+
+
+Family Behaviour
+
+
+352 This family ensures that a user may use a resource or service without others,
+especially third parties, being able to observe that the resource or service is
+being used.
+
+
+Component levelling
+
+
+353 FPR_UNO.1 Unobservability, requires that users and/or subjects cannot
+determine whether an operation is being performed.
+
+
+354 FPR_UNO.2 Allocation of information impacting unobservability, requires
+that the TSF provide specific mechanisms to avoid the concentration of
+privacy related information within the TOE. Such concentrations might
+impact unobservability if a security compromise occurs.
+
+
+355 FPR_UNO.3 Unobservability without soliciting information, requires that
+the TSF does not try to obtain privacy related information that might be used
+to compromise unobservability.
+
+
+356 FPR_UNO.4 Authorised user observability, requires the TSF to provide one
+or more authorised users with a capability to observe the usage of resources
+and/or services.
+
+
+Management: FPR_UNO.1, FPR_UNO.2
+
+
+357 The following actions could be considered for the management functions in
+FMT:
+
+
+a) the management of the behaviour of the unobservability function.
+
+
+Management: FPR_UNO.3
+
+
+358 There are no management activities foreseen.
+
+
+Management: FPR_UNO.4
+
+
+359 The following actions could be considered for the management functions in
+FMT:
+
+
+Page 124 of 323 Version 3.1 April 2017
+
+
+**Class FPR: Privacy**
+
+
+a) the list of authorised users that are capable of determining the
+occurrence of operations.
+
+
+Audit: FPR_UNO.1, FPR_UNO.2
+
+
+360 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: The invocation of the unobservability mechanism.
+
+
+Audit: FPR_UNO.3
+
+
+361 There are no auditable events foreseen.
+
+
+Audit: FPR_UNO.4
+
+
+362 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: The observation of the use of a resource or service by a user
+or subject.
+
+
+**FPR_UNO.1** **Unobservability**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FPR_UNO.1.1** **The TSF shall ensure that [assignment:** _**list of users and/or subjects**_ **] are**
+**unable to observe the operation [assignment:** _**list of operations**_ **] on**
+
+**[assignment:** _**list of objects**_ **] by [assignment:** _**list of protected users and/or**_
+_**subjects**_ **].**
+
+
+**FPR_UNO.2** **Allocation of information impacting unobservability**
+
+
+Hierarchical to: FPR_UNO.1 Unobservability
+
+
+Dependencies: No dependencies.
+
+
+**FPR_UNO.2.1** The TSF shall ensure that [assignment: _list of users and/or subjects_ ] are
+unable to observe the operation [assignment: _list of operations_ ] on
+
+[assignment: _list of objects_ ] by [assignment: _list of protected users and/or_
+_subjects_ ].
+
+
+**FPR_UNO.2.2** **The TSF shall allocate the [assignment:** _**unobservability related**_
+_**information**_ **] among different parts of the TOE such that the following**
+**conditions hold during the lifetime of the information: [assignment:** _**list**_
+_**of conditions**_ **].**
+
+
+April 2017 Version 3.1 Page 125 of 323
+
+
+**Class FPR: Privacy**
+
+
+**FPR_UNO.3** **Unobservability without soliciting information**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FPR_UNO.1 Unobservability
+
+
+**FPR_UNO.3.1** **The TSF shall provide [assignment:** _**list of services**_ **] to [assignment:** _**list of**_
+_**subjects**_ **] without soliciting any reference to [assignment:** _**privacy related**_
+_**information**_ **].**
+
+
+**FPR_UNO.4** **Authorised user observability**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FPR_UNO.4.1** **The TSF shall provide [assignment:** _**set of authorised users**_ **] with the**
+**capability to observe the usage of [assignment:** _**list of resources and/or**_
+_**services**_ **].**
+
+
+Page 126 of 323 Version 3.1 April 2017
+
+
+**Class FPT: Protection of the TSF**
+
+# **15 Class FPT: Protection of the TSF**
+
+
+363 This class contains families of functional requirements that relate to the
+integrity and management of the mechanisms that constitute the TSF and to
+the integrity of TSF data. In some sense, families in this class may appear to
+duplicate components in the FDP: User data protection class; they may even
+be implemented using the same mechanisms. However, FDP: User data
+protection focuses on user data protection, while FPT: Protection of the TSF
+focuses on TSF data protection. In fact, components from the FPT:
+Protection of the TSF class are necessary to provide requirements that the
+SFPs in the TOE cannot be tampered with or bypassed.
+
+
+364 From the point of view of this class, regarding to the TSF there are three
+significant elements:
+
+
+a) The TSF's implementation, which executes and implements the
+mechanisms that enforce the SFRs.
+
+
+b) The TSF's data, which are the administrative databases that guide the
+enforcement of the SFRs.
+
+
+c) The external entities that the TSF may interact with in order to
+enforce the SFRs.
+
+
+April 2017 Version 3.1 Page 127 of 323
+
+
+**Class FPT: Protection of the TSF**
+
+
+**Figure 14 - FPT: Protection of the TSF class decomposition**
+
+
+Page 128 of 323 Version 3.1 April 2017
+
+
+**Class FPT: Protection of the TSF**
+
+## **15.1 Fail secure (FPT_FLS)**
+
+
+Family Behaviour
+
+
+365 The requirements of this family ensure that the TOE will always enforce its
+SFRs in the event of identified categories of failures in the TSF.
+
+
+Component levelling
+
+
+366 This family consists of only one component, FPT_FLS.1 Failure with
+preservation of secure state, which requires that the TSF preserve a secure
+state in the face of the identified failures.
+
+
+Management: FPT_FLS.1
+
+
+367 There are no management activities foreseen.
+
+
+Audit: FPT_FLS.1
+
+
+368 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Basic: Failure of the TSF.
+
+
+**FPT_FLS.1** **Failure with preservation of secure state**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FPT_FLS.1.1** **The TSF shall preserve a secure state when the following types of**
+**failures occur: [assignment:** _**list of types of failures in the TSF**_ **].**
+
+
+April 2017 Version 3.1 Page 129 of 323
+
+
+**Class FPT: Protection of the TSF**
+
+## **15.2 Availability of exported TSF data (FPT_ITA)**
+
+
+Family Behaviour
+
+
+369 This family defines the rules for the prevention of loss of availability of TSF
+data moving between the TSF and another trusted IT product. This data
+could, for example, be TSF critical data such as passwords, keys, audit data,
+or TSF executable code.
+
+
+Component levelling
+
+
+370 This family consists of only one component, FPT_ITA.1 Inter-TSF
+availability within a defined availability metric. This component requires that
+the TSF ensure, to an identified degree of probability, the availability of TSF
+data provided to another trusted IT product.
+
+
+Management: FPT_ITA.1
+
+
+371 The following actions could be considered for the management functions in
+FMT:
+
+
+a) management of the list of types of TSF data that must be available to
+another trusted IT product.
+
+
+Audit: FPT_ITA.1
+
+
+372 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: the absence of TSF data when required by a TOE.
+
+
+**FPT_ITA.1** **Inter-TSF availability within a defined availability metric**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FPT_ITA.1.1** **The TSF shall ensure the availability of [assignment:** _**list of types of TSF**_
+_**data**_ **] provided to another trusted IT product within [assignment:** _**a**_
+_**defined availability metric**_ **] given the following conditions [assignment:**
+_**conditions to ensure availability**_ **].**
+
+
+Page 130 of 323 Version 3.1 April 2017
+
+
+**Class FPT: Protection of the TSF**
+
+## **15.3 Confidentiality of exported TSF data (FPT_ITC)**
+
+
+Family Behaviour
+
+
+373 This family defines the rules for the protection from unauthorised disclosure
+of TSF data during transmission between the TSF and another trusted IT
+product. This data could, for example, be TSF critical data such as passwords,
+keys, audit data, or TSF executable code.
+
+
+Component levelling
+
+
+374 This family consists of only one component, FPT_ITC.1 Inter-TSF
+confidentiality during transmission, which requires that the TSF ensure that
+data transmitted between the TSF and another trusted IT product is protected
+from disclosure while in transit.
+
+
+Management: FPT_ITC.1
+
+
+375 There are no management activities foreseen.
+
+
+Audit: FPT_ITC.1
+
+
+376 There are no auditable events foreseen.
+
+
+**FPT_ITC.1** **Inter-TSF confidentiality during transmission**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FPT_ITC.1.1** **The TSF shall protect all TSF data transmitted from the TSF to another**
+**trusted IT product from unauthorised disclosure during transmission.**
+
+
+April 2017 Version 3.1 Page 131 of 323
+
+
+**Class FPT: Protection of the TSF**
+
+## **15.4 Integrity of exported TSF data (FPT_ITI)**
+
+
+Family Behaviour
+
+
+377 This family defines the rules for the protection, from unauthorised
+modification, of TSF data during transmission between the TSF and another
+trusted IT product. This data could, for example, be TSF critical data such as
+passwords, keys, audit data, or TSF executable code.
+
+
+Component levelling
+
+
+378 FPT_ITI.1 Inter-TSF detection of modification, provides the ability to detect
+modification of TSF data during transmission between the TSF and another
+trusted IT product, under the assumption that another trusted IT product is
+cognisant of the mechanism used.
+
+
+379 FPT_ITI.2 Inter-TSF detection and correction of modification, provides the
+ability for another trusted IT product not only to detect modification, but to
+correct modified TSF data under the assumption that another trusted IT
+product is cognisant of the mechanism used.
+
+
+Management: FPT_ITI.1
+
+
+380 There are no management activities foreseen.
+
+
+Management: FPT_ITI.2
+
+
+381 The following actions could be considered for the management functions in
+FMT:
+
+
+a) management of the types of TSF data that the TSF should try to
+correct if modified in transit;
+
+
+b) management of the types of action that the TSF could take if TSF
+data is modified in transit.
+
+
+Audit: FPT_ITI.1
+
+
+382 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: the detection of modification of transmitted TSF data.
+
+
+b) Basic: the action taken upon detection of modification of transmitted
+TSF data.
+
+
+Page 132 of 323 Version 3.1 April 2017
+
+
+**Class FPT: Protection of the TSF**
+
+
+Audit: FPT_ITI.2
+
+
+383 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: the detection of modification of transmitted TSF data;
+
+
+b) Basic: the action taken upon detection of modification of transmitted
+TSF data.
+
+
+c) Basic: the use of the correction mechanism.
+
+
+**FPT_ITI.1** **Inter-TSF detection of modification**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FPT_ITI.1.1** **The TSF shall provide the capability to detect modification of all TSF**
+**data during transmission between the TSF and another trusted IT**
+**product within the following metric: [assignment:** _**a defined modification**_
+_**metric**_ **].**
+
+
+**FPT_ITI.1.2** **The TSF shall provide the capability to verify the integrity of all TSF**
+**data transmitted between the TSF and another trusted IT product and**
+**perform [assignment:** _**action to be taken**_ **] if modifications are detected.**
+
+
+**FPT_ITI.2** **Inter-TSF detection and correction of modification**
+
+
+Hierarchical to: FPT_ITI.1 Inter-TSF detection of modification
+
+
+Dependencies: No dependencies.
+
+
+**FPT_ITI.2.1** The TSF shall provide the capability to detect modification of all TSF data
+during transmission between the TSF and another trusted IT product within
+the following metric: [assignment: _a defined modification metric_ ].
+
+
+**FPT_ITI.2.2** The TSF shall provide the capability to verify the integrity of all TSF data
+transmitted between the TSF and another trusted IT product and perform
+
+[assignment: _action to be taken_ ] if modifications are detected.
+
+
+**FPT_ITI.2.3** **The TSF shall provide the capability to correct [assignment:** _**type of**_
+_**modification**_ **] of all TSF data transmitted between the TSF and another**
+**trusted IT product.**
+
+
+April 2017 Version 3.1 Page 133 of 323
+
+
+**Class FPT: Protection of the TSF**
+
+## **15.5 Internal TOE TSF data transfer (FPT_ITT)**
+
+
+Family Behaviour
+
+
+384 This family provides requirements that address protection of TSF data when
+it is transferred between separate parts of a TOE across an internal channel.
+
+
+Component levelling
+
+
+385 FPT_ITT.1 Basic internal TSF data transfer protection, requires that TSF
+data be protected when transmitted between separate parts of the TOE.
+
+
+386 FPT_ITT.2 TSF data transfer separation, requires that the TSF separate user
+data from TSF data during transmission.
+
+
+387 FPT_ITT.3 TSF data integrity monitoring, requires that the TSF data
+transmitted between separate parts of the TOE is monitored for identified
+integrity errors.
+
+
+Management: FPT_ITT.1
+
+
+388 The following actions could be considered for the management functions in
+FMT:
+
+
+a) management of the types of modification against which the TSF
+should protect;
+
+
+b) management of the mechanism used to provide the protection of the
+data in transit between different parts of the TSF.
+
+
+Management: FPT_ITT.2
+
+
+389 The following actions could be considered for the management functions in
+FMT:
+
+
+a) management of the types of modification against which the TSF
+should protect;
+
+
+b) management of the mechanism used to provide the protection of the
+data in transit between different parts of the TSF;
+
+
+c) management of the separation mechanism.
+
+
+Page 134 of 323 Version 3.1 April 2017
+
+
+**Class FPT: Protection of the TSF**
+
+
+Management: FPT_ITT.3
+
+
+390 The following actions could be considered for the management functions in
+FMT:
+
+
+a) management of the types of modification against which the TSF
+should protect;
+
+
+b) management of the mechanism used to provide the protection of the
+data in transit between different parts of the TSF;
+
+
+c) management of the types of modification of TSF data the TSF should
+try to detect;
+
+
+d) management of the action>s that will be taken.
+
+
+Audit: FPT_ITT.1, FPT_ITT.2
+
+
+391 There are no auditable events foreseen.
+
+
+Audit: FPT_ITT.3
+
+
+392 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: the detection of modification of TSF data;
+
+
+b) Basic: the action taken following detection of an integrity error.
+
+
+**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 [selection:** _**disclosure, modification**_ **]**
+**when it is transmitted between separate parts of the TOE.**
+
+
+**FPT_ITT.2** **TSF data transfer separation**
+
+
+Hierarchical to: FPT_ITT.1 Basic internal TSF data transfer protection
+
+
+Dependencies: No dependencies.
+
+
+**FPT_ITT.2.1** The TSF shall protect TSF data from [selection: _disclosure, modification_ ]
+when it is transmitted between separate parts of the TOE.
+
+
+**FPT_ITT.2.2** **The TSF shall separate user data from TSF data when such data is**
+**transmitted between separate parts of the TOE.**
+
+
+April 2017 Version 3.1 Page 135 of 323
+
+
+**Class FPT: Protection of the TSF**
+
+
+**FPT_ITT.3** **TSF data integrity monitoring**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FPT_ITT.1 Basic internal TSF data transfer protection
+
+
+**FPT_ITT.3.1** **The TSF shall be able to detect [selection:** _**modification of data,**_
+_**substitution of data, re-ordering of data, deletion of data, [assignment:**_
+_**other integrity errors]**_ **] for TSF data transmitted between separate parts**
+**of the TOE.**
+
+
+**FPT_ITT.3.2** **Upon detection of a data integrity error, the TSF shall take the following**
+**actions: [assignment:** _**specify the action to be taken**_ **].**
+
+
+Page 136 of 323 Version 3.1 April 2017
+
+
+**Class FPT: Protection of the TSF**
+
+## **15.6 TSF physical protection (FPT_PHP)**
+
+
+Family Behaviour
+
+
+393 TSF physical protection components refer to restrictions on unauthorised
+physical access to the TSF, and to the deterrence of, and resistance to,
+unauthorised physical modification, or substitution of the TSF.
+
+
+394 The requirements of components in this family ensure that the TSF is
+protected from physical tampering and interference. Satisfying the
+requirements of these components results in the TSF being packaged and
+used in such a manner that physical tampering is detectable, or resistance to
+physical tampering is enforced. Without these components, the protection
+functions of a TSF lose their effectiveness in environments where physical
+damage cannot be prevented. This family also provides requirements
+regarding how the TSF shall respond to physical tampering attempts.
+
+
+Component levelling
+
+
+395 FPT_PHP.1 Passive detection of physical attack, provides for features that
+indicate when a TSF device or TSF element is subject to tampering.
+However, notification of tampering is not automatic; an authorised user must
+invoke a security administrative function or perform manual inspection to
+determining if tampering has occurred.
+
+
+396 FPT_PHP.2 Notification of physical attack, provides for automatic
+notification of tampering for an identified subset of physical penetrations.
+
+
+397 FPT_PHP.3 Resistance to physical attack, provides for features that prevent
+or resist physical tampering with TSF devices and TSF elements.
+
+
+Management: FPT_PHP.1
+
+
+398 The following actions could be considered for the management functions in
+FMT:
+
+
+a) management of the user or role that determines whether physical
+tampering has occurred.
+
+
+Management: FPT_PHP.2
+
+
+399 The following actions could be considered for the management functions in
+FMT:
+
+
+a) management of the user or role that gets informed about intrusions;
+
+
+April 2017 Version 3.1 Page 137 of 323
+
+
+**Class FPT: Protection of the TSF**
+
+
+b) management of the list of devices that should inform the indicated
+user or role about the intrusion.
+
+
+Management: FPT_PHP.3
+
+
+400 The following actions could be considered for the management functions in
+FMT:
+
+
+a) management of the automatic responses to physical tampering.
+
+
+Audit: FPT_PHP.1
+
+
+401 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: if detection by IT means, detection of intrusion.
+
+
+Audit: FPT_PHP.2
+
+
+402 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: detection of intrusion.
+
+
+Audit: FPT_PHP.3
+
+
+403 There are no auditable events foreseen.
+
+
+**FPT_PHP.1** **Passive detection of physical attack**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FPT_PHP.1.1** **The TSF shall provide unambiguous detection of physical tampering**
+**that might compromise the TSF.**
+
+
+**FPT_PHP.1.2** **The TSF shall provide the capability to determine whether physical**
+**tampering with the TSF's devices or TSF's elements has occurred.**
+
+
+**FPT_PHP.2** **Notification of physical attack**
+
+
+Hierarchical to: FPT_PHP.1 Passive detection of physical attack
+
+
+Dependencies: FMT_MOF.1 Management of security functions
+behaviour
+
+
+**FPT_PHP.2.1** The TSF shall provide unambiguous detection of physical tampering that
+might compromise the TSF.
+
+
+**FPT_PHP.2.2** The TSF shall provide the capability to determine whether physical
+tampering with the TSF's devices or TSF's elements has occurred.
+
+
+Page 138 of 323 Version 3.1 April 2017
+
+
+**Class FPT: Protection of the TSF**
+
+
+**FPT_PHP.2.3** **For [assignment:** _**list of TSF devices/elements for which active detection is**_
+_**required**_ **], the TSF shall monitor the devices and elements and notify**
+
+**[assignment:** _**a designated user or role**_ **] when physical tampering with the**
+**TSF's devices or TSF's elements has occurred.**
+
+
+**FPT_PHP.3** **Resistance to physical attack**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FPT_PHP.3.1** **The TSF shall resist [assignment:** _**physical tampering scenarios**_ **] to the**
+
+**[assignment:** _**list of TSF devices/elements**_ **] by responding automatically**
+**such that the SFRs are always enforced.**
+
+
+April 2017 Version 3.1 Page 139 of 323
+
+
+**Class FPT: Protection of the TSF**
+
+## **15.7 Trusted recovery (FPT_RCV)**
+
+
+Family Behaviour
+
+
+404 The requirements of this family ensure that the TSF can determine that the
+TOE is started up without protection compromise and can recover without
+protection compromise after discontinuity of operations. This family is
+important because the start-up state of the TSF determines the protection of
+subsequent states.
+
+
+Component levelling
+
+
+405 FPT_RCV.1 Manual recovery, allows a TOE to only provide mechanisms
+that involve human intervention to return to a secure state.
+
+
+406 FPT_RCV.2 Automated recovery, provides, for at least one type of service
+discontinuity, recovery to a secure state without human intervention;
+recovery for other discontinuities may require human intervention.
+
+
+407 FPT_RCV.3 Automated recovery without undue loss, also provides for
+automated recovery, but strengthens the requirements by disallowing undue
+loss of protected objects.
+
+
+408 FPT_RCV.4 Function recovery, provides for recovery at the level of
+particular functions, ensuring either successful completion or rollback of
+TSF data to a secure state.
+
+
+Management: FPT_RCV.1
+
+
+409 The following actions could be considered for the management functions in
+FMT:
+
+
+a) management of who can access the restore capability within the
+maintenance mode.
+
+
+Management: FPT_RCV.2, FPT_RCV.3
+
+
+410 The following actions could be considered for the management functions in
+FMT:
+
+
+a) management of who can access the restore capability within the
+maintenance mode;
+
+
+b) management of the list of failures/service discontinuities that will be
+handled through the automatic procedures.
+
+
+Page 140 of 323 Version 3.1 April 2017
+
+
+**Class FPT: Protection of the TSF**
+
+
+Management: FPT_RCV.4
+
+
+411 There are no management activities foreseen.
+
+
+Audit: FPT_RCV.1, FPT_RCV.2, FPT_RCV.3
+
+
+412 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: the fact that a failure or service discontinuity occurred;
+
+
+b) Minimal: resumption of the regular operation;
+
+
+c) Basic: type of failure or service discontinuity.
+
+
+Audit: FPT_RCV.4
+
+
+413 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: if possible, the impossibility to return to a secure state after
+a failure of the TSF;
+
+
+b) Basic: if possible, the detection of a failure of a function.
+
+
+**FPT_RCV.1** **Manual recovery**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: AGD_OPE.1 Operational user guidance
+
+
+**FPT_RCV.1.1** **After [assignment:** _**list of failures/service discontinuities**_ **] the TSF shall**
+**enter a maintenance mode where the ability to return to a secure state is**
+**provided.**
+
+
+**FPT_RCV.2** **Automated recovery**
+
+
+Hierarchical to: FPT_RCV.1 Manual recovery
+
+
+Dependencies: AGD_OPE.1 Operational user guidance
+
+
+**FPT_RCV.2.1** **When** **automated** **recovery** **from** [assignment: _list of failures/service_
+_discontinuities_ ] **is** **not** **possible,** the TSF shall enter a maintenance mode
+where the ability to return to a secure state is provided.
+
+
+**FPT_RCV.2.2** **For [assignment:** _**list of failures/service discontinuities**_ **], the TSF shall**
+**ensure the return of the TOE to a secure state using automated**
+**procedures.**
+
+
+April 2017 Version 3.1 Page 141 of 323
+
+
+**Class FPT: Protection of the TSF**
+
+
+**FPT_RCV.3** **Automated recovery without undue loss**
+
+
+Hierarchical to: FPT_RCV.2 Automated recovery
+
+
+Dependencies: AGD_OPE.1 Operational user guidance
+
+
+**FPT_RCV.3.1** When automated recovery from [assignment: _list of failures/service_
+_discontinuities_ ] is not possible, the TSF shall enter a maintenance mode
+where the ability to return to a secure state is provided.
+
+
+**FPT_RCV.3.2** For [assignment: _list of failures/service discontinuities_ ], the TSF shall ensure
+the return of the TOE to a secure state using automated procedures.
+
+
+**FPT_RCV.3.3** **The functions provided by the TSF to recover from failure or service**
+**discontinuity shall ensure that the secure initial state is restored without**
+**exceeding [assignment:** _**quantification**_ **] for loss of TSF data or objects**
+**under the control of the TSF.**
+
+
+**FPT_RCV.3.4** **The TSF shall provide the capability to determine the objects that were**
+**or were not capable of being recovered.**
+
+
+**FPT_RCV.4** **Function recovery**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FPT_RCV.4.1** **The TSF shall ensure that [assignment:** _**list of functions and failure**_
+_**scenarios**_ **] have the property that the function either completes**
+**successfully, or for the indicated failure scenarios, recovers to a**
+**consistent and secure state.**
+
+
+Page 142 of 323 Version 3.1 April 2017
+
+
+**Class FPT: Protection of the TSF**
+
+## **15.8 Replay detection (FPT_RPL)**
+
+
+Family Behaviour
+
+
+414 This family addresses detection of replay for various types of entities (e.g.
+messages, service requests, service responses) and subsequent actions to
+correct. In the case where replay may be detected, this effectively prevents it.
+
+
+Component levelling
+
+
+415 The family consists of only one component, FPT_RPL.1 Replay detection,
+which requires that the TSF shall be able to detect the replay of identified
+entities.
+
+
+Management: FPT_RPL.1
+
+
+416 The following actions could be considered for the management functions in
+FMT:
+
+
+a) management of the list of identified entities for which replay shall be
+detected;
+
+
+b) management of the list of actions that need to be taken in case of
+replay.
+
+
+Audit: FPT_RPL.1
+
+
+417 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Basic: Detected replay attacks.
+
+
+b) Detailed: Action to be taken based on the specific actions.
+
+
+**FPT_RPL.1** **Replay detection**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FPT_RPL.1.1** **The TSF shall detect replay for the following entities: [assignment:** _**list of**_
+_**identified entities**_ **].**
+
+
+**FPT_RPL.1.2** **The TSF shall perform [assignment:** _**list of specific actions**_ **] when replay**
+**is detected.**
+
+
+April 2017 Version 3.1 Page 143 of 323
+
+
+**Class FPT: Protection of the TSF**
+
+## **15.9 State synchrony protocol (FPT_SSP)**
+
+
+Family Behaviour
+
+
+418 Distributed TOEs may give rise to greater complexity than monolithic TOEs
+through the potential for differences in state between parts of the TOE, and
+through delays in communication. In most cases synchronisation of state
+between distributed functions involves an exchange protocol, not a simple
+action. When malice exists in the distributed environment of these protocols,
+more complex defensive protocols are required.
+
+
+419 State synchrony protocol (FPT_SSP) establishes the requirement for certain
+critical functions of the TSF to use this trusted protocol. State synchrony
+protocol (FPT_SSP) ensures that two distributed parts of the TOE (e.g.
+hosts) have synchronised their states after a security-relevant action.
+
+
+Component levelling
+
+
+420 FPT_SSP.1 Simple trusted acknowledgement, requires only a simple
+acknowledgment by the data recipient.
+
+
+421 FPT_SSP.2 Mutual trusted acknowledgement, requires mutual
+acknowledgment of the data exchange.
+
+
+Management: FPT_SSP.1, FPT_SSP.2
+
+
+422 There are no management activities foreseen.
+
+
+Audit: FPT_SSP.1, FPT_SSP.2
+
+
+423 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: failure to receive an acknowledgement when expected.
+
+
+**FPT_SSP.1** **Simple trusted acknowledgement**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FPT_ITT.1 Basic internal TSF data transfer protection
+
+
+**FPT_SSP.1.1** **The TSF shall acknowledge, when requested by another part of the TSF,**
+**the receipt of an unmodified TSF data transmission.**
+
+
+Page 144 of 323 Version 3.1 April 2017
+
+
+**Class FPT: Protection of the TSF**
+
+
+**FPT_SSP.2** **Mutual trusted acknowledgement**
+
+
+Hierarchical to: FPT_SSP.1 Simple trusted acknowledgement
+
+
+Dependencies: FPT_ITT.1 Basic internal TSF data transfer protection
+
+
+**FPT_SSP.2.1** The TSF shall acknowledge, when requested by another part of the TSF, the
+receipt of an unmodified TSF data transmission.
+
+
+**FPT_SSP.2.2** **The TSF shall ensure that the relevant parts of the TSF know the**
+**correct status of transmitted data among its different parts, using**
+**acknowledgements.**
+
+
+April 2017 Version 3.1 Page 145 of 323
+
+
+**Class FPT: Protection of the TSF**
+
+## **15.10 Time stamps (FPT_STM)**
+
+
+Family Behaviour
+
+
+424 This family addresses requirements for a reliable time stamp function within
+a TOE.
+
+
+Component levelling
+
+
+425 This family consists of only one component, FPT_STM.1 Reliable time
+stamps, which requires that the TSF provide reliable time stamps for TSF
+functions.
+
+
+Management: FPT_STM.1
+
+
+426 The following actions could be considered for the management functions in
+FMT:
+
+
+a) management of the time.
+
+
+Audit: FPT_STM.1
+
+
+427 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: changes to the time;
+
+
+b) Detailed: providing a timestamp.
+
+
+**FPT_STM.1** **Reliable time stamps**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FPT_STM.1.1** **The TSF shall be able to provide reliable time stamps.**
+
+
+Page 146 of 323 Version 3.1 April 2017
+
+
+**Class FPT: Protection of the TSF**
+
+## **15.11 Inter-TSF TSF data consistency (FPT_TDC)**
+
+
+Family Behaviour
+
+
+428 In a distributed environment, a TOE may need to exchange TSF data (e.g.
+the SFP-attributes associated with data, audit information, identification
+information) with another trusted IT product, This family defines the
+requirements for sharing and consistent interpretation of these attributes
+between the TSF of the TOE and a different trusted IT product.
+
+
+Component levelling
+
+
+429 FPT_TDC.1 Inter-TSF basic TSF data consistency, requires that the TSF
+provide the capability to ensure consistency of attributes between TSFs.
+
+
+Management: FPT_TDC.1
+
+
+430 There are no management activities foreseen.
+
+
+Audit: FPT_TDC.1
+
+
+431 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Successful use of TSF data consistency mechanisms.
+
+
+b) Basic: Use of the TSF data consistency mechanisms.
+
+
+c) Basic: Identification of which TSF data have been interpreted.
+
+
+d) Basic: Detection of modified TSF data.
+
+
+**FPT_TDC.1** **Inter-TSF basic TSF data consistency**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FPT_TDC.1.1** **The TSF shall provide the capability to consistently interpret**
+
+**[assignment:** _**list of TSF data types**_ **] when shared between the TSF and**
+**another trusted IT product.**
+
+
+**FPT_TDC.1.2** **The TSF shall use [assignment:** _**list of interpretation rules to be applied by**_
+_**the TSF**_ **] when interpreting the TSF data from another trusted IT**
+**product.**
+
+
+April 2017 Version 3.1 Page 147 of 323
+
+
+**Class FPT: Protection of the TSF**
+
+## **15.12 Testing of external entities (FPT_TEE)**
+
+
+Family Behaviour
+
+
+432 This family defines requirements for the TSF to perform tests on one or more
+external entities.
+
+
+433 This component is not intended to be applied to human users.
+
+
+434 External entities may include applications running on the TOE, hardware or
+software running โunderneathโ the TOE (platforms, operating systems etc.)
+or applications/boxes connected to the TOE (intrusion detection systems,
+firewalls, login servers, time servers etc.).
+
+
+Component levelling
+
+
+435 FPT_TEE.1 Testing of external entities, provides for testing of the external
+entities by the TSF.
+
+
+Management: FPT_TEE.1
+
+
+436 The following actions could be considered for the management functions in
+FMT:
+
+
+a) management of the conditions under which the testing of external
+entities occurs, such as during initial start-up, regular interval, or
+under specified conditions;
+
+
+b) management of the time interval if appropriate.
+
+
+Audit: FPT_TEE.1
+
+
+437 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Basic: Execution of the tests of the external entities and the results of
+the tests.
+
+
+**FPT_TEE.1** **Testing of external entities**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FPT_TEE.1.1** **The TSF shall run a suite of tests [selection:** _**during initial start-up,**_
+_**periodically during normal operation, at the request of an authorised user,**_
+
+_**[assignment: other conditions]**_ **] to check the fulfillment of [assignment:**
+_**list of properties of the external entities**_ **] .**
+
+
+Page 148 of 323 Version 3.1 April 2017
+
+
+**Class FPT: Protection of the TSF**
+
+
+**FPT_TEE.1.2** **If the test fails, the TSF shall [assignment:** _**action(s)**_ **] .**
+
+
+April 2017 Version 3.1 Page 149 of 323
+
+
+**Class FPT: Protection of the TSF**
+
+## **15.13 Internal TOE TSF data replication consistency** **(FPT_TRC)**
+
+
+Family Behaviour
+
+
+438 The requirements of this family are needed to ensure the consistency of TSF
+data when such data is replicated internal to the TOE. Such data may become
+inconsistent if the internal channel between parts of the TOE becomes
+inoperative. If the TOE is internally structured as a network and parts of the
+TOE network connections are broken, this may occur when parts become
+disabled.
+
+
+Component levelling
+
+
+439 This family consists of only one component, FPT_TRC.1 Internal TSF
+consistency, which requires that the TSF ensure the consistency of TSF data
+that is replicated in multiple locations.
+
+
+Management: FPT_TRC.1
+
+
+440 There are no management activities foreseen.
+
+
+Audit: FPT_TRC.1
+
+
+441 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: restoring consistency upon reconnection.
+
+
+b) Basic: Detected inconsistency between TSF data.
+
+
+**FPT_TRC.1** **Internal TSF consistency**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FPT_ITT.1 Basic internal TSF data transfer protection
+
+
+**FPT_TRC.1.1** **The TSF shall ensure that TSF data is consistent when replicated**
+**between parts of the TOE.**
+
+
+**FPT_TRC.1.2** **When parts of the TOE containing replicated TSF data are disconnected,**
+
+**the TSF shall ensure the consistency of the replicated TSF data upon**
+**reconnection before processing any requests for [assignment:** _**list of**_
+_**functions dependent on TSF data replication consistency**_ **].**
+
+
+Page 150 of 323 Version 3.1 April 2017
+
+
+**Class FPT: Protection of the TSF**
+
+## **15.14 TSF self test (FPT_TST)**
+
+
+Family Behaviour
+
+
+442 The family defines the requirements for the self-testing of the TSF with
+respect to some expected correct operation. Examples are interfaces to
+enforcement functions, and sample arithmetical operations on critical parts of
+the TOE. These tests can be carried out at start-up, periodically, at the
+request of the authorised user, or when other conditions are met. The actions
+to be taken by the TOE as the result of self testing are defined in other
+families.
+
+
+443 The requirements of this family are also needed to detect the corruption of
+TSF data and TSF itself (i.e. TSF executable code or TSF hardware
+component) by various failures that do not necessarily stop the TOE's
+operation (which would be handled by other families). These checks must be
+performed because these failures may not necessarily be prevented. Such
+failures can occur either because of unforeseen failure modes or associated
+oversights in the design of hardware, firmware, or software, or because of
+malicious corruption of the TSF due to inadequate logical and/or physical
+protection.
+
+
+Component levelling
+
+
+444 FPT_TST.1 TSF testing, provides the ability to test the TSF's correct
+operation. These tests may be performed at start-up, periodically, at the
+request of the authorised user, or when other conditions are met. It also
+provides the ability to verify the integrity of TSF data and TSF itself.
+
+
+Management: FPT_TST.1
+
+
+445 The following actions could be considered for the management functions in
+FMT:
+
+
+a) management of the conditions under which TSF self testing occurs,
+such as during initial start-up, regular interval, or under specified
+conditions;
+
+
+b) management of the time interval if appropriate.
+
+
+Audit: FPT_TST.1
+
+
+446 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Basic: Execution of the TSF self tests and the results of the tests.
+
+
+April 2017 Version 3.1 Page 151 of 323
+
+
+**Class FPT: Protection of the TSF**
+
+
+**FPT_TST.1** **TSF testing**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FPT_TST.1.1** **The TSF shall run a suite of self tests [selection:** _**during initial start-up,**_
+_**periodically during normal operation, at the request of the authorised user,**_
+_**at the conditions[assignment: conditions under which self test should**_
+_**occur]**_ **] to demonstrate the correct operation of [selection:** _**[assignment:**_
+_**parts of TSF], the TSF**_ **].**
+
+
+**FPT_TST.1.2** **The TSF shall provide authorised users with the capability to verify the**
+**integrity of [selection:** _**[assignment: parts of TSF data], TSF data**_ **].**
+
+
+**FPT_TST.1.3** **The TSF shall provide authorised users with the capability to verify the**
+**integrity of [selection:** _**[assignment: parts of TSF], TSF**_ **].**
+
+
+Page 152 of 323 Version 3.1 April 2017
+
+
+**Class FRU: Resource utilisation**
+
+# **16 Class FRU: Resource utilisation**
+
+
+447 This class provides three families that support the availability of required
+resources such as processing capability and/or storage capacity. The family
+Fault Tolerance provides protection against unavailability of capabilities
+caused by failure of the TOE. The family Priority of Service ensures that the
+resources will be allocated to the more important or time-critical tasks and
+cannot be monopolised by lower priority tasks. The family Resource
+Allocation provides limits on the use of available resources, therefore
+preventing users from monopolising the resources.
+
+
+**Figure 15 - FRU: Resource utilisation class decomposition**
+
+
+April 2017 Version 3.1 Page 153 of 323
+
+
+**Class FRU: Resource utilisation**
+
+## **16.1 Fault tolerance (FRU_FLT)**
+
+
+Family Behaviour
+
+
+448 The requirements of this family ensure that the TOE will maintain correct
+operation even in the event of failures.
+
+
+Component levelling
+
+
+449 FRU_FLT.1 Degraded fault tolerance, requires the TOE to continue correct
+operation of identified capabilities in the event of identified failures.
+
+
+450 FRU_FLT.2 Limited fault tolerance, requires the TOE to continue correct
+operation of all capabilities in the event of identified failures.
+
+
+Management: FRU_FLT.1, FRU_FLT.2
+
+
+451 There are no management activities foreseen.
+
+
+Audit: FRU_FLT.1
+
+
+452 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Any failure detected by the TSF.
+
+
+b) Basic: All TOE capabilities being discontinued due to a failure.
+
+
+Audit: FRU_FLT.2
+
+
+453 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Any failure detected by the TSF.
+
+
+**FRU_FLT.1** **Degraded fault tolerance**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FPT_FLS.1 Failure with preservation of secure state
+
+
+**FRU_FLT.1.1** **The TSF shall ensure the operation of [assignment:** _**list of TOE**_
+_**capabilities**_ **] when the following failures occur: [assignment:** _**list of type of**_
+_**failures**_ **].**
+
+
+Page 154 of 323 Version 3.1 April 2017
+
+
+**Class FRU: Resource utilisation**
+
+
+**FRU_FLT.2** **Limited fault tolerance**
+
+
+Hierarchical to: FRU_FLT.1 Degraded fault tolerance
+
+
+Dependencies: FPT_FLS.1 Failure with preservation of secure state
+
+
+**FRU_FLT.2.1** The TSF shall ensure the operation of **all** **the** **TOE's** **capabilities** when the
+following failures occur: [assignment: _list of type of failures_ ].
+
+
+April 2017 Version 3.1 Page 155 of 323
+
+
+**Class FRU: Resource utilisation**
+
+## **16.2 Priority of service (FRU_PRS)**
+
+
+Family Behaviour
+
+
+454 The requirements of this family allow the TSF to control the use of resources
+under the control of the TSF by users and subjects such that high priority
+activities under the control of the TSF will always be accomplished without
+undue interference or delay caused by low priority activities.
+
+
+Component levelling
+
+
+455 FRU_PRS.1 Limited priority of service, provides priorities for a subject's use
+of a subset of the resources under the control of the TSF.
+
+
+456 FRU_PRS.2 Full priority of service, provides priorities for a subject's use of
+all of the resources under the control of the TSF.
+
+
+Management: FRU_PRS.1, FRU_PRS.2
+
+
+457 The following actions could be considered for the management functions in
+FMT:
+
+
+a) assignment of priorities to each subject in the TSF.
+
+
+Audit: FRU_PRS.1, FRU_PRS.2
+
+
+458 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Rejection of operation based on the use of priority within
+an allocation.
+
+
+b) Basic: All attempted uses of the allocation function which involves
+the priority of the service functions.
+
+
+**FRU_PRS.1** **Limited priority of service**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FRU_PRS.1.1** **The TSF shall assign a priority to each subject in the TSF.**
+
+
+**FRU_PRS.1.2** **The TSF shall ensure that each access to [assignment:** _**controlled**_
+_**resources**_ **] shall be mediated on the basis of the subjects assigned**
+**priority.**
+
+
+Page 156 of 323 Version 3.1 April 2017
+
+
+**Class FRU: Resource utilisation**
+
+
+**FRU_PRS.2** **Full priority of service**
+
+
+Hierarchical to: FRU_PRS.1 Limited priority of service
+
+
+Dependencies: No dependencies.
+
+
+**FRU_PRS.2.1** The TSF shall assign a priority to each subject in the TSF.
+
+
+**FRU_PRS.2.2** The TSF shall ensure that each access to **all** **shareable** **resources** shall be
+mediated on the basis of the subjects assigned priority.
+
+
+April 2017 Version 3.1 Page 157 of 323
+
+
+**Class FRU: Resource utilisation**
+
+## **16.3 Resource allocation (FRU_RSA)**
+
+
+Family Behaviour
+
+
+459 The requirements of this family allow the TSF to control the use of resources
+by users and subjects such that denial of service will not occur because of
+unauthorised monopolisation of resources.
+
+
+Component levelling
+
+
+460 FRU_RSA.1 Maximum quotas, provides requirements for quota mechanisms
+that ensure that users and subjects will not monopolise a controlled resource.
+
+
+461 FRU_RSA.2 Minimum and maximum quotas, provides requirements for
+quota mechanisms that ensure that users and subjects will always have at
+least a minimum of a specified resource and that they will not be able to
+monopolise a controlled resource.
+
+
+Management: FRU_RSA.1
+
+
+462 The following actions could be considered for the management functions in
+FMT:
+
+
+a) specifying maximum limits for a resource for groups and/or
+individual users and/or subjects by an administrator.
+
+
+Management: FRU_RSA.2
+
+
+463 The following actions could be considered for the management functions in
+FMT:
+
+
+a) specifying minimum and maximum limits for a resource for groups
+and/or individual users and/or subjects by an administrator.
+
+
+Audit: FRU_RSA.1, FRU_RSA.2
+
+
+464 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Rejection of allocation operation due to resource limits.
+
+
+b) Basic: All attempted uses of the resource allocation functions for
+resources that are under control of the TSF.
+
+
+Page 158 of 323 Version 3.1 April 2017
+
+
+**Class FRU: Resource utilisation**
+
+
+**FRU_RSA.1** **Maximum quotas**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FRU_RSA.1.1** **The TSF shall enforce maximum quotas of the following resources:**
+
+**[assignment:** _**controlled resources**_ **] that [selection:** _**individual user, defined**_
+_**group of users, subjects**_ **] can use [selection:** _**simultaneously, over a**_
+_**specified period of time**_ **].**
+
+
+**FRU_RSA.2** **Minimum and maximum quotas**
+
+
+Hierarchical to: FRU_RSA.1 Maximum quotas
+
+
+Dependencies: No dependencies.
+
+
+**FRU_RSA.2.1** The TSF shall enforce maximum quotas of the following resources
+
+[assignment: _controlled resources_ ] that [selection: _individual user, defined_
+_group of users, subjects_ ] can use [selection: _simultaneously, over a specified_
+_period of time_ ].
+
+
+**FRU_RSA.2.2** **The TSF shall ensure the provision of minimum quantity of each**
+
+**[assignment:** _**controlled resource**_ **] that is available for [selection:** _**an**_
+_**individual user, defined group of users, subjects**_ **] to use [selection:**
+_**simultaneously, over a specified period of time**_ **].**
+
+
+April 2017 Version 3.1 Page 159 of 323
+
+
+**Class FTA: TOE access**
+
+# **17 Class FTA: TOE access**
+
+
+465 This family specifies functional requirements for controlling the
+establishment of a user's session.
+
+
+**Figure 16 - FTA: TOE access class decomposition**
+
+
+Page 160 of 323 Version 3.1 April 2017
+
+
+**Class FTA: TOE access**
+
+## **17.1 Limitation on scope of selectable attributes (FTA_LSA)**
+
+
+Family Behaviour
+
+
+466 This family defines requirements to limit the scope of session security
+attributes that a user may select for a session.
+
+
+Component levelling
+
+
+467 FTA_LSA.1 Limitation on scope of selectable attributes, provides the
+requirement for a TOE to limit the scope of the session security attributes
+during session establishment.
+
+
+Management: FTA_LSA.1
+
+
+468 The following actions could be considered for the management functions in
+FMT:
+
+
+a) management of the scope of the session security attributes by an
+administrator.
+
+
+Audit: FTA_LSA.1
+
+
+469 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: All failed attempts at selecting a session security attributes;
+
+
+b) Basic: All attempts at selecting a session security attributes;
+
+
+c) Detailed: Capture of the values of each session security attributes.
+
+
+**FTA_LSA.1** **Limitation on scope of selectable attributes**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FTA_LSA.1.1** **The TSF shall restrict the scope of the session security attributes**
+
+**[assignment:** _**session security attributes**_ **], based on [assignment:** _**attributes**_ **].**
+
+
+April 2017 Version 3.1 Page 161 of 323
+
+
+**Class FTA: TOE access**
+
+## **17.2 Limitation on multiple concurrent sessions (FTA_MCS)**
+
+
+Family Behaviour
+
+
+470 This family defines requirements to place limits on the number of concurrent
+sessions that belong to the same user.
+
+
+Component levelling
+
+
+471 FTA_MCS.1 Basic limitation on multiple concurrent sessions, provides
+limitations that apply to all users of the TSF.
+
+
+472 FTA_MCS.2 Per user attribute limitation on multiple concurrent sessions
+extends FTA_MCS.1 Basic limitation on multiple concurrent sessions by
+requiring the ability to specify limitations on the number of concurrent
+sessions based on the related security attributes.
+
+
+Management: FTA_MCS.1
+
+
+473 The following actions could be considered for the management functions in
+FMT:
+
+
+a) management of the maximum allowed number of concurrent user
+sessions by an administrator.
+
+
+Management: FTA_MCS.2
+
+
+474 The following actions could be considered for the management functions in
+FMT:
+
+
+a) management of the rules that govern the maximum allowed number
+of concurrent user sessions by an administrator.
+
+
+Audit: FTA_MCS.1, FTA_MCS.2
+
+
+475 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Rejection of a new session based on the limitation of
+multiple concurrent sessions.
+
+
+b) Detailed: Capture of the number of currently concurrent user sessions
+and the user security attribute(s).
+
+
+Page 162 of 323 Version 3.1 April 2017
+
+
+**Class FTA: TOE access**
+
+
+**FTA_MCS.1** **Basic limitation on multiple concurrent sessions**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FIA_UID.1 Timing of identification
+
+
+**FTA_MCS.1.1** **The TSF shall restrict the maximum number of concurrent sessions that**
+**belong to the same user.**
+
+
+**FTA_MCS.1.2** **The TSF shall enforce, by default, a limit of [assignment:** _**default**_
+_**number**_ **] sessions per user.**
+
+
+**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** **[assignment:** _**rules**_ _**for**_ _**the**_
+_**number**_ _**of**_ _**maximum**_ _**concurrent**_ _**sessions**_ **].**
+
+
+**FTA_MCS.2.2** The TSF shall enforce, by default, a limit of [assignment: _default number_ ]
+sessions per user.
+
+
+April 2017 Version 3.1 Page 163 of 323
+
+
+**Class FTA: TOE access**
+
+## **17.3 Session locking and termination (FTA_SSL)**
+
+
+Family Behaviour
+
+
+476 This family defines requirements for the TSF to provide the capability for
+TSF-initiated and user-initiated locking, unlocking, and termination of
+interactive sessions.
+
+
+Component levelling
+
+
+477 FTA_SSL.1 TSF-initiated session locking includes system initiated locking
+of an interactive session after a specified period of user inactivity.
+
+
+478 FTA_SSL.2 User-initiated locking, provides capabilities for the user to lock
+and unlock the user's own interactive sessions.
+
+
+479 FTA_SSL.3 TSF-initiated termination, provides requirements for the TSF to
+terminate the session after a specified period of user inactivity.
+
+
+480 FTA_SSL.4 User-initiated termination, provides capabilities for the user to
+terminate the user's own interactive sessions.
+
+
+Management: FTA_SSL.1
+
+
+481 The following actions could be considered for the management functions in
+FMT:
+
+
+a) specification of the time of user inactivity after which lock-out occurs
+for an individual user;
+
+
+b) specification of the default time of user inactivity after which lockout occurs;
+
+
+c) management of the events that should occur prior to unlocking the
+session.
+
+
+Page 164 of 323 Version 3.1 April 2017
+
+
+**Class FTA: TOE access**
+
+
+Management: FTA_SSL.2
+
+
+482 The following actions could be considered for the management functions in
+FMT:
+
+
+a) management of the events that should occur prior to unlocking the
+session.
+
+
+Management: FTA_SSL.3
+
+
+483 The following actions could be considered for the management functions in
+FMT:
+
+
+a) specification of the time of user inactivity after which termination of
+the interactive session occurs for an individual user;
+
+
+b) specification of the default time of user inactivity after which
+termination of the interactive session occurs.
+
+
+Management: FTA_SSL.4
+
+
+484 There are no management activities foreseen.
+
+
+Audit: FTA_SSL.1, FTA_SSL.2
+
+
+485 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Locking of an interactive session by the session locking
+mechanism.
+
+
+b) Minimal: Successful unlocking of an interactive session.
+
+
+c) Basic: Any attempts at unlocking an interactive session.
+
+
+Audit: FTA_SSL.3
+
+
+486 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Termination of an interactive session by the session locking
+mechanism.
+
+
+Audit: FTA_SSL.4
+
+
+487 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Termination of an interactive session by the user.
+
+
+April 2017 Version 3.1 Page 165 of 323
+
+
+**Class FTA: TOE access**
+
+
+**FTA_SSL.1** **TSF-initiated session locking**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FIA_UAU.1 Timing of authentication
+
+
+**FTA_SSL.1.1** **The TSF shall lock an interactive session after [assignment:** _**time interval**_
+_**of user inactivity**_ **] by:**
+
+
+**a)** **clearing or overwriting display devices, making the current**
+**contents unreadable;**
+
+
+**b)** **disabling any activity of the user's data access/display devices**
+**other than unlocking the session.**
+
+
+**FTA_SSL.1.2** **The TSF shall require the following events to occur prior to unlocking**
+**the session: [assignment:** _**events to occur**_ **].**
+
+
+**FTA_SSL.2** **User-initiated locking**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: FIA_UAU.1 Timing of authentication
+
+
+**FTA_SSL.2.1** **The TSF shall allow user-initiated locking of the user's own interactive**
+**session, by:**
+
+
+**a)** **clearing or overwriting display devices, making the current**
+**contents unreadable;**
+
+
+**b)** **disabling any activity of the user's data access/display devices**
+**other than unlocking the session.**
+
+
+**FTA_SSL.2.2** **The TSF shall require the following events to occur prior to unlocking**
+**the session: [assignment:** _**events to occur**_ **].**
+
+
+**FTA_SSL.3** **TSF-initiated termination**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FTA_SSL.3.1** **The TSF shall terminate an interactive session after a [assignment:** _**time**_
+_**interval of user inactivity**_ **].**
+
+
+**FTA_SSL.4** **User-initiated termination**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FTA_SSL.4.1** **The TSF shall allow user-initiated termination of the user's own**
+**interactive session.**
+
+
+Page 166 of 323 Version 3.1 April 2017
+
+
+**Class FTA: TOE access**
+
+## **17.4 TOE access banners (FTA_TAB)**
+
+
+Family Behaviour
+
+
+488 This family defines requirements to display a configurable advisory warning
+message to users regarding the appropriate use of the TOE.
+
+
+Component levelling
+
+
+489 FTA_TAB.1 Default TOE access banners, provides the requirement for a
+TOE Access Banner. This banner is displayed prior to the establishment
+dialogue for a session.
+
+
+Management: FTA_TAB.1
+
+
+490 The following actions could be considered for the management functions in
+FMT:
+
+
+a) maintenance of the banner by the authorised administrator.
+
+
+Audit: FTA_TAB.1
+
+
+491 There are no auditable events foreseen.
+
+
+**FTA_TAB.1** **Default TOE access banners**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FTA_TAB.1.1** **Before establishing a user session, the TSF shall display an advisory**
+**warning message regarding unauthorised use of the TOE.**
+
+
+April 2017 Version 3.1 Page 167 of 323
+
+
+**Class FTA: TOE access**
+
+## **17.5 TOE access history (FTA_TAH)**
+
+
+Family Behaviour
+
+
+492 This family defines requirements for the TSF to display to a user, upon
+successful session establishment, a history of successful and unsuccessful
+attempts to access the user's account.
+
+
+Component levelling
+
+
+493 FTA_TAH.1 TOE access history, provides the requirement for a TOE to
+display information related to previous attempts to establish a session.
+
+
+Management: FTA_TAH.1
+
+
+494 There are no management activities foreseen.
+
+
+Audit: FTA_TAH.1
+
+
+495 There are no auditable events foreseen.
+
+
+**FTA_TAH.1** **TOE access history**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FTA_TAH.1.1** **Upon successful session establishment, the TSF shall display the**
+
+**[selection:** _**date, time, method, location**_ **] of the last successful session**
+**establishment to the user.**
+
+
+**FTA_TAH.1.2** **Upon successful session establishment, the TSF shall display the**
+
+**[selection:** _**date, time, method, location**_ **] of the last unsuccessful attempt to**
+**session establishment and the number of unsuccessful attempts since the**
+**last successful session establishment.**
+
+
+**FTA_TAH.1.3** **The TSF shall not erase the access history information from the user**
+**interface without giving the user an opportunity to review the**
+**information.**
+
+
+Page 168 of 323 Version 3.1 April 2017
+
+
+**Class FTA: TOE access**
+
+## **17.6 TOE session establishment (FTA_TSE)**
+
+
+Family Behaviour
+
+
+496 This family defines requirements to deny a user permission to establish a
+session with the TOE.
+
+
+Component levelling
+
+
+497 FTA_TSE.1 TOE session establishment, provides requirements for denying
+users access to the TOE based on attributes.
+
+
+Management: FTA_TSE.1
+
+
+498 The following actions could be considered for the management functions in
+FMT:
+
+
+a) management of the session establishment conditions by the
+authorised administrator.
+
+
+Audit: FTA_TSE.1
+
+
+499 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Denial of a session establishment due to the session
+establishment mechanism.
+
+
+b) Basic: All attempts at establishment of a user session.
+
+
+c) Detailed: Capture of the value of the selected access parameters (e.g.
+location of access, time of access).
+
+
+**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 session establishment based on**
+
+**[assignment:** _**attributes**_ **].**
+
+
+April 2017 Version 3.1 Page 169 of 323
+
+
+**Class FTP: Trusted path/channels**
+
+# **18 Class FTP: Trusted path/channels**
+
+
+500 Families in this class provide requirements for a trusted communication path
+between users and the TSF, and for a trusted communication channel
+between the TSF and other trusted IT products. Trusted paths and channels
+have the following general characteristics:
+
+
+๏ญ The communications path is constructed using internal and external
+communications channels (as appropriate for the component) that
+isolate an identified subset of TSF data and commands from the
+remainder of the TSF and user data.
+
+
+๏ญ Use of the communications path may be initiated by the user and/or
+the TSF (as appropriate for the component).
+
+
+๏ญ The communications path is capable of providing assurance that the
+user is communicating with the correct TSF, and that the TSF is
+communicating with the correct user (as appropriate for the
+component).
+
+
+501 In this paradigm, a trusted channel is a communication channel that may be
+initiated by either side of the channel, and provides non-repudiation
+characteristics with respect to the identity of the sides of the channel.
+
+
+502 A trusted path provides a means for users to perform functions through an
+assured direct interaction with the TSF. Trusted path is usually desired for
+user actions such as initial identification and/or authentication, but may also
+be desired at other times during a user's session. Trusted path exchanges may
+be initiated by a user or the TSF. User responses via the trusted path are
+guaranteed to be protected from modification by or disclosure to untrusted
+applications.
+
+
+**Figure 17 - FTP: Trusted path/channels class decomposition**
+
+
+Page 170 of 323 Version 3.1 April 2017
+
+
+**Class FTP: Trusted path/channels**
+
+## **18.1 Inter-TSF trusted channel (FTP_ITC)**
+
+
+Family Behaviour
+
+
+503 This family defines requirements for the creation of a trusted channel
+between the TSF and other trusted IT products for the performance of
+security critical operations. This family should be included whenever there
+are requirements for the secure communication of user or TSF data between
+the TOE and other trusted IT products.
+
+
+Component levelling
+
+
+504 FTP_ITC.1 Inter-TSF trusted channel, requires that the TSF provide a trusted
+communication channel between itself and another trusted IT product.
+
+
+Management: FTP_ITC.1
+
+
+505 The following actions could be considered for the management functions in
+FMT:
+
+
+a) Configuring the actions that require trusted channel, if supported.
+
+
+Audit: FTP_ITC.1
+
+
+506 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Failure of the trusted channel functions.
+
+
+b) Minimal: Identification of the initiator and target of failed trusted
+channel functions.
+
+
+c) Basic: All attempted uses of the trusted channel functions.
+
+
+d) Basic: Identification of the initiator and target of all trusted channel
+functions.
+
+
+**FTP_ITC.1** **Inter-TSF trusted channel**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FTP_ITC.1.1** **The TSF shall provide a communication channel between itself and**
+**another trusted IT product that is logically distinct from other**
+**communication channels and provides assured identification of its end**
+**points and protection of the channel data from modification or**
+**disclosure.**
+
+
+April 2017 Version 3.1 Page 171 of 323
+
+
+**Class FTP: Trusted path/channels**
+
+
+**FTP_ITC.1.2** **The TSF shall permit [selection:** _**the TSF, another trusted IT product**_ **] to**
+**initiate communication via the trusted channel.**
+
+
+**FTP_ITC.1.3** **The TSF shall initiate communication via the trusted channel for**
+
+**[assignment:** _**list of functions for which a trusted channel is required**_ **].**
+
+
+Page 172 of 323 Version 3.1 April 2017
+
+
+**Class FTP: Trusted path/channels**
+
+## **18.2 Trusted path (FTP_TRP)**
+
+
+Family Behaviour
+
+
+507 This family defines the requirements to establish and maintain trusted
+communication to or from users and the TSF. A trusted path may be required
+for any security-relevant interaction. Trusted path exchanges may be initiated
+by a user during an interaction with the TSF, or the TSF may establish
+communication with the user via a trusted path.
+
+
+Component levelling
+
+
+508 FTP_TRP.1 Trusted path, requires that a trusted path between the TSF and a
+user be provided for a set of events defined by a PP/ST author. The user
+and/or the TSF may have the ability to initiate the trusted path.
+
+
+Management: FTP_TRP.1
+
+
+509 The following actions could be considered for the management functions in
+FMT:
+
+
+a) Configuring the actions that require trusted path, if supported.
+
+
+Audit: FTP_TRP.1
+
+
+510 The following actions should be auditable if FAU_GEN Security audit data
+generation is included in the PP/ST:
+
+
+a) Minimal: Failures of the trusted path functions.
+
+
+b) Minimal: Identification of the user associated with all trusted path
+failures, if available.
+
+
+c) Basic: All attempted uses of the trusted path functions.
+
+
+d) Basic: Identification of the user associated with all trusted path
+invocations, if available.
+
+
+**FTP_TRP.1** **Trusted path**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies: No dependencies.
+
+
+**FTP_TRP.1.1** **The TSF shall provide a communication path between itself and**
+
+**[selection:** _**remote, local**_ **] users that is logically distinct from other**
+**communication paths and provides assured identification of its end**
+**points and protection of the communicated data from [selection:**
+
+
+April 2017 Version 3.1 Page 173 of 323
+
+
+**Class FTP: Trusted path/channels**
+
+
+_**modification, disclosure, [assignment: other types of integrity or**_
+_**confidentiality violation]**_ **].**
+
+
+**FTP_TRP.1.2** **The TSF shall permit [selection:** _**the TSF, local users, remote users**_ **] to**
+**initiate communication via the trusted path.**
+
+
+**FTP_TRP.1.3** **The TSF shall require the use of the trusted path for [selection:** _**initial**_
+_**user authentication, [assignment: other services for which trusted path is**_
+_**required]**_ **].**
+
+
+Page 174 of 323 Version 3.1 April 2017
+
+
+**Security functional requirements application notes**
+
+# **A Security functional requirements** **application notes** **(normative)**
+
+
+511 This annex contains additional guidance for the families and components
+defined in the elements of this CC Part 2, which may be required by users,
+developers or evaluators to use the components. To facilitate finding the
+appropriate information, the presentation of the classes, families and
+components in this annex is similar to the presentation within the elements.
+
+## **A.1 Structure of the notes**
+
+
+512 This chapter defines the content and presentation of the notes related to
+functional requirements of the CC.
+
+
+**A.1.1** **Class structure**
+
+
+513 Figure 18 below illustrates the functional class structure in this annex.
+
+
+**Figure 18 - Functional class structure**
+
+
+**A.1.1.1** Class name
+
+
+514 This is the unique name of the class defined within the normative elements of
+this part of the CC.
+
+
+**A.1.1.2** Class introduction
+
+
+515 The class introduction in this annex provides information about the use of the
+families and components of the class. This information is completed with the
+informative diagram that describes the organisation of each class with the
+families in each class and the hierarchical relationship between components
+in each family.
+
+
+April 2017 Version 3.1 Page 175 of 323
+
+
+**Security functional requirements application notes**
+
+
+**A.1.2** **Family structure**
+
+
+516 Figure 19 illustrates the functional family structure for application notes in
+diagrammatic form.
+
+
+**Figure 19 - Functional family structure for application notes**
+
+
+**A.1.2.1** Family name
+
+
+517 This is the unique name of the family defined within the normative elements
+of this part of the CC.
+
+
+**A.1.2.2** User notes
+
+
+518 The user notes contain additional information that is of interest to potential
+users of the family, that is PP, ST and functional package authors, and
+developers of TOEs incorporating the functional components. The
+presentation is informative, and might cover warnings about limitations of
+use and areas where specific attention might be required when using the
+components.
+
+
+**A.1.2.3** Evaluator notes
+
+
+519 The evaluator notes contain any information that is of interest to developers
+and evaluators of TOEs that claim compliance with a component of the
+family. The presentation is informative and can cover a variety of areas
+where specific attention might be needed when evaluating the TOE. This can
+include clarifications of meaning and specification of the way to interpret
+requirements, as well as caveats and warnings of specific interest to
+evaluators.
+
+
+520 These User Notes and Evaluator Notes sections are not mandatory and
+appear only if appropriate.
+
+
+**A.1.3** **Component structure**
+
+
+521 Figure 20 illustrates the functional component structure for the application
+notes.
+
+
+Page 176 of 323 Version 3.1 April 2017
+
+
+**Security functional requirements application notes**
+
+
+**Figure 20 - Functional component structure**
+
+
+**A.1.3.1** Component identification
+
+
+522 This is the unique name of the component defined within the normative
+elements of this part of the CC.
+
+
+**A.1.3.2** Component rationale and application notes
+
+
+523 Any specific information related to the component can be found in this
+section.
+
+
+๏ญ The _rationale_ contains the specifics of the rationale that refine the
+general statements on rationale for the specific level, and should only
+be used if level specific amplification is required.
+
+
+๏ญ The _application notes_ contain additional refinement in terms of
+narrative qualification as it pertains to a specific component. This
+refinement can pertain to user notes, and/or evaluator notes as
+described in Section A.1.2. This refinement can be used to explain
+the nature of the dependencies (e.g. shared information, or shared
+operation).
+
+
+524 This section is not mandatory and appears only if appropriate.
+
+
+**A.1.3.3** Permitted operations
+
+
+525 This portion of each component contains advice relating to the permitted
+operations of the component.
+
+
+526 This section is not mandatory and appears only if appropriate.
+
+## **A.2 Dependency tables**
+
+
+527 The following dependency tables for functional components show their
+direct, indirect and optional dependencies. Each of the components that is a
+dependency of some functional component is allocated a column. Each
+functional component is allocated a row. The value in the table cell indicate
+whether the column label component is directly required (indicated by a
+
+
+April 2017 Version 3.1 Page 177 of 323
+
+
+**Security functional requirements application notes**
+
+
+cross โXโ), indirectly required (indicated by a dash โ-โ), or optionally
+required (indicated by a โoโ) by the row label component. An example of a
+component with optional dependencies is FDP_ETC.1 Export of user data
+without security attributes, which requires either FDP_ACC.1 Subset access
+control or FDP_IFC.1 Subset information flow control to be present. So if
+FDP_ACC.1 Subset access control is present, FDP_IFC.1 Subset
+information flow control is not necessary and vice versa. If no character is
+presented, the component is not dependent upon another component.
+
+|Col1|FAU_GEN.1|FAU_SAA.1|FAU_SAR.1|FAU_STG.1|FIA_UID.1|FMT_MTD.1|FMT_SMF.1|FMT_SMR.1|FPT_STM.1|
+|---|---|---|---|---|---|---|---|---|---|
+|FAU_ARP.1|-|X|||||||-|
+|FAU_GEN.1|||||||||X|
+|FAU_GEN.2|X||||X||||-|
+|FAU_SAA.1|X||||||||-|
+|FAU_SAA.2|||||X|||||
+|FAU_SAA.3||||||||||
+|FAU_SAA.4||||||||||
+|FAU_SAR.1|X||||||||-|
+|FAU_SAR.2|-||X||||||-|
+|FAU_SAR.3|-||X||||||-|
+|FAU_SEL.1|X||||-|X|-|-|-|
+|FAU_STG.1|X||||||||-|
+|FAU_STG.2|X||||||||-|
+|FAU_STG.3|-|||X|||||-|
+|FAU_STG.4|-|||X|||||-|
+
+
+
+**Table 1 Dependency table for Class FAU: Security audit**
+
+|Col1|FIA_UID.1|
+|---|---|
+|FCO_NRO.1|X|
+|FCO_NRO.2|X|
+|FCO_NRR.1|X|
+|FCO_NRR.2|X|
+
+
+
+**Table 2 Dependency table for Class FCO: Communication**
+
+
+Page 178 of 323 Version 3.1 April 2017
+
+
+**Security functional requirements application notes**
+
+|Col1|FCS_CKM.1|FCS_CKM.2|FCS_CKM.4|FCS_COP.1|FDP_ACC.1|FDP_ACF.1|FDP_IFC.1|FDP_IFF.1|FDP_ITC.1|FDP_ITC.2|FIA_UID.1|FMT_MSA.1|FMT_MSA.3|FMT_SMF.1|FMT_SMR.1|FPT_TDC.1|FTP_ITC.1|FTP_TRP.1|
+|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
+|FCS_CKM.1|-|O|X|O|-|-|-|-|-|-|-|-|-|-|-|-|-|-|
+|FCS_CKM.2|O|-|X|-|-|-|-|-|O|O|-|-|-|-|-|-|-|-|
+|FCS_CKM.3|O|-|X|-|-|-|-|-|O|O|-|-|-|-|-|-|-|-|
+|FCS_CKM.4|O|-|-|-|-|-|-|-|O|O|-|-|-|-|-|-|-|-|
+|FCS_COP.1|O|-|X|-|-|-|-|-|O|O|-|-|-|-|-|-|-|-|
+
+
+
+**Table 3 Dependency table for Class FCS: Cryptographic support**
+
+
+April 2017 Version 3.1 Page 179 of 323
+
+
+**Security functional requirements application notes**
+
+|Col1|FDP_ACC.1|FDP_ACF.1|FDP_IFC.1|FDP_IFF.1|FDP_ITT.1|FDP_ITT.2|FDP_UIT.1|FIA_UID.1|FMT_MSA.1|FMT_MSA.3|FMT_SMF.1|FMT_SMR.1|FPT_TDC.1|FTP_ITC.1|FTP_TRP.1|
+|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
+|FDP_ACC.1|-|X|-|-||||-|-|-|-|-||||
+|FDP_ACC.2|-|X|-|-||||-|-|-|-|-||||
+|FDP_ACF.1|X|-|-|-||||-|-|X|-|-||||
+|FDP_DAU.1||||||||||||||||
+|FDP_DAU.2||||||||X||||||||
+|FDP_ETC.1|O|-|O|-||||-|-|-|-|-||||
+|FDP_ETC.2|O|-|O|-||||-|-|-|-|-||||
+|FDP_IFC.1|-|-|-|X||||-|-|-|-|-||||
+|FDP_IFC.2|-|-|-|X||||-|-|-|-|-||||
+|FDP_IFF.1|-|-|X|-||||-|-|X|-|-||||
+|FDP_IFF.2|-|-|X|-||||-|-|X|-|-||||
+|FDP_IFF.3|-|-|X|-||||-|-|-|-|-||||
+|FDP_IFF.4|-|-|X|-||||-|-|-|-|-||||
+|FDP_IFF.5|-|-|X|-||||-|-|-|-|-||||
+|FDP_IFF.6|-|-|X|-||||-|-|-|-|-||||
+|FDP_ITC.1|O|-|O|-||||-|-|X|-|-||||
+|FDP_ITC.2|O|-|O|-||||-|-|-|-|-|X|O|O|
+|FDP_ITT.1|O|-|O|-||||-|-|-|-|-||||
+|FDP_ITT.2|O|-|O|-||||-|-|-|-|-||||
+|FDP_ITT.3|O|-|O|-|X|||-|-|-|-|-||||
+|FDP_ITT.4|O|-|O|-||X||-|-|-|-|-||||
+|FDP_RIP.1||||||||||||||||
+|FDP_RIP.2||||||||||||||||
+|FDP_ROL.1|O|-|O|-||||-|-|-|-|-||||
+|FDP_ROL.2|O|-|O|-||||-|-|-|-|-||||
+|FDP_SDI.1||||||||||||||||
+|FDP_SDI.2||||||||||||||||
+|FDP_UCT.1|O|-|O|-||||-|-|-|-|-||O|O|
+|FDP_UIT.1|O|-|O|-||||-|-|-|-|-||O|O|
+|FDP_UIT.2|O|-|O|-|||O|-|-|-|-|-||O|-|
+|FDP_UIT.3|O|-|O|-|||O|-|-|-|-|-||O|-|
+
+
+
+**Table 4 Dependency table for Class FDP: User data protection**
+
+
+Page 180 of 323 Version 3.1 April 2017
+
+
+**Security functional requirements application notes**
+
+|Col1|FIA_ATD.1|FIA_UAU.1|FIA_UID.1|
+|---|---|---|---|
+|FIA_AFL.1||X|-|
+|FIA_ATD.1||||
+|FIA_SOS.1||||
+|FIA_SOS.2||||
+|FIA_UAU.1|||X|
+|FIA_UAU.2|||X|
+|FIA_UAU.3||||
+|FIA_UAU.4||||
+|FIA_UAU.5||||
+|FIA_UAU.6||||
+|FIA_UAU.7||X|-|
+|FIA_UID.1||||
+|FIA_UID.2||||
+|FIA_USB.1|X|||
+
+
+
+**Table 5 Dependency table for Class FIA: Identification and authentication**
+
+|Col1|FDP_ACC.1|FDP_ACF.1|FDP_IFC.1|FDP_IFF.1|FIA_UID.1|FMT_MSA.1|FMT_MSA.3|FMT_MTD.1|FMT_SMF.1|FMT_SMR.1|FPT_STM.1|
+|---|---|---|---|---|---|---|---|---|---|---|---|
+|FMT_MOF.1|||||-||||X|X||
+|FMT_MSA.1|O|-|O|-|-|-|-||X|X||
+|FMT_MSA.2|O|-|O|-|-|X|-||-|X||
+|FMT_MSA.3|-|-|-|-|-|X|-||-|X||
+|FMT_MSA.4|O|-|O|-|-|-|-||-|-||
+|FMT_MTD.1|||||-||||X|X||
+|FMT_MTD.2|||||-|||X|-|X||
+|FMT_MTD.3|||||-|||X|-|-||
+|FMT_REV.1|||||-|||||X||
+|FMT_SAE.1|||||-|||||X|X|
+|FMT_SMF.1||||||||||||
+|FMT_SMR.1|||||X|||||||
+|FMT_SMR.2|||||X|||||||
+|FMT_SMR.3|||||-|||||X||
+
+
+
+**Table 6 Dependency table for Class FMT: Security management**
+
+
+April 2017 Version 3.1 Page 181 of 323
+
+
+**Security functional requirements application notes**
+
+|Col1|FIA_UID.1|FPR_UNO.1|
+|---|---|---|
+|FPR_ANO.1|||
+|FPR_ANO.2|||
+|FPR_PSE.1|||
+|FPR_PSE.2|X||
+|FPR_PSE.3|||
+|FPR_UNL.1|||
+|FPR_UNO.1|||
+|FPR_UNO.2|||
+|FPR_UNO.3||X|
+|FPR_UNO.4|||
+
+
+
+**Table 7 Dependency table for Class FPR: Privacy**
+
+|Col1|AGD_OPE.1|FIA_UID.1|FMT_MOF.1|FMT_SMF.1|FMT_SMR.1|FPT_ITT.1|
+|---|---|---|---|---|---|---|
+|FPT_FLS.1|||||||
+|FPT_ITA.1|||||||
+|FPT_ITC.1|||||||
+|FPT_ITI.1|||||||
+|FPT_ITI.2|||||||
+|FPT_ITT.1|||||||
+|FPT_ITT.2|||||||
+|FPT_ITT.3||||||X|
+|FPT_PHP.1|||||||
+|FPT_PHP.2||-|X|-|-||
+|FPT_PHP.3|||||||
+|FPT_RCV.1|X||||||
+|FPT_RCV.2|X||||||
+|FPT_RCV.3|X||||||
+|FPT_RCV.4|||||||
+|FPT_RPL.1|||||||
+|FPT_SSP.1||||||X|
+|FPT_SSP.2||||||X|
+|FPT_STM.1|||||||
+|FPT_TDC.1|||||||
+|FPT_TEE.1|||||||
+|FPT_TRC.1||||||X|
+|FPT_TST.1|||||||
+
+
+
+**Table 8 Dependency table for Class FPT: Protection of the TSF**
+
+
+Page 182 of 323 Version 3.1 April 2017
+
+
+**Security functional requirements application notes**
+
+|Col1|FPT_FLS.1|
+|---|---|
+|FRU_FLT.1|X|
+|FRU_FLT.2|X|
+|FRU_PRS.1||
+|FRU_PRS.2||
+|FRU_RSA.1||
+|FRU_RSA.2||
+
+
+
+**Table 9 Dependency table for Class FRU: Resource utilisation**
+
+|Col1|FIA_UAU.1|FIA_UID.1|
+|---|---|---|
+|FTA_LSA.1|||
+|FTA_MCS.1||X|
+|FTA_MCS.2||X|
+|FTA_SSL.1|X|-|
+|FTA_SSL.2|X|-|
+|FTA_SSL.3|||
+|FTA_SSL.4|||
+|FTA_TAB.1|||
+|FTA_TAH.1|||
+|FTA_TSE.1|||
+
+
+
+**Table 10 Dependency table for Class FTA: TOE access**
+
+
+April 2017 Version 3.1 Page 183 of 323
+
+
+**Functional classes, families, and components**
+
+# **B Functional classes, families, and** **components** **(normative)**
+
+
+528 The following annexes C through M provide the application notes for the
+functional classes defined in the main body of this part of the CC.
+
+
+Page 184 of 323 Version 3.1 April 2017
+
+
+**Class FAU: Security audit**
+
+# **C Class FAU: Security audit** **(normative)**
+
+
+529 CC audit families allow PP/ST authors the ability to define requirements for
+monitoring user activities and, in some cases, detecting real, possible, or
+imminent violations of the enforcement of the SFRs. The TOE's security
+audit functions are defined to help monitor security-relevant events, and act
+as a deterrent against security violations. The requirements of the audit
+families refer to functions that include audit data protection, record format,
+and event selection, as well as analysis tools, violation alarms, and real-time
+analysis. The audit trail should be presented in human-readable format either
+directly (e.g. storing the audit trail in human-readable format) or indirectly
+(e.g. using audit reduction tools), or both.
+
+
+530 While developing the security audit requirements, the PP/ST author should
+take note of the inter-relationships among the audit families and components.
+The potential exists to specify a set of audit requirements that comply with
+the family/component dependencies lists, while at the same time resulting in
+a deficient audit function (e.g. an audit function that requires all security
+relevant events to be audited but without the selectivity to control them on
+any reasonable basis such as individual user or object).
+
+## **C.1 Audit requirements in a distributed environment**
+
+
+531 The implementation of audit requirements for networks and other large
+systems may differ significantly from those needed for stand-alone systems.
+Larger, more complex and active systems require more thought concerning
+which audit data to collect and how this should be managed, due to lowered
+feasibility of interpreting (or even storing) what gets collected. The
+traditional notion of a time-ordered list or โtrailโ of audited events may not
+be applicable in a global asynchronous network with arbitrarily many events
+occurring at once.
+
+
+532 Also, different hosts and servers on a distributed TOE may have differing
+naming policies and values. Symbolic names presentation for audit review
+may require a net-wide convention to avoid redundancies and โname
+clashes.โ
+
+
+533 A multi-object audit repository, portions of which are accessible by a
+potentially wide variety of authorised users, may be required if audit
+repositories are to serve a useful function in distributed systems.
+
+
+534 Finally, misuse of authority by authorised users should be addressed by
+systematically avoiding local storage of audit data pertaining to administrator
+actions.
+
+
+535 Figure 21 shows the decomposition of this class into its constituent
+components.
+
+
+April 2017 Version 3.1 Page 185 of 323
+
+
+**Class FAU: Security audit**
+
+
+**Figure 21 - FAU: Security audit class decomposition**
+
+## **C.2 Security audit automatic response (FAU_ARP)**
+
+
+User notes
+
+
+536 The Security audit automatic response family describes requirements for the
+handling of audit events. The requirement could include requirements for
+alarms or TSF action (automatic response). For example, the TSF could
+include the generation of real time alarms, termination of the offending
+process, disabling of a service, or disconnection or invalidation of a user
+account.
+
+
+Page 186 of 323 Version 3.1 April 2017
+
+
+**Class FAU: Security audit**
+
+
+537 An audit event is defined to be an โpotential security violationโ if so
+indicated by the Security audit analysis (FAU_SAA) components.
+
+
+**FAU_ARP.1** **Security alarms**
+
+
+User application notes
+
+
+538 An action should be taken for follow up action in the event of an alarm. This
+action can be to inform the authorised user, to present the authorised user
+with a set of possible containment actions, or to take corrective actions. The
+timing of the actions should be carefully considered by the PP/ST author.
+
+
+Operations
+
+
+Assignment:
+
+
+539 In **FAU_ARP.1.1**, the PP/ST author should specify the actions to be
+taken in case of a potential security violation. An example of such a
+list is: โinform the authorised user, disable the subject that created the
+potential security violation.โ It can also specify that the action to be
+taken can be specified by an authorised user.
+
+## **C.3 Security audit data generation (FAU_GEN)**
+
+
+User notes
+
+
+540 The Security audit data generation family includes requirements to specify
+the audit events that should be generated by the TSF for security-relevant
+events.
+
+
+541 This family is presented in a manner that avoids a dependency on all
+components requiring audit support. Each component has an audit section
+developed in which the events to be audited for that functional area are listed.
+When the PP/ST author assembles the PP/ST, the items in the audit area are
+used to complete the variable in this component. Thus, the specification of
+what could be audited for a functional area is localised in that functional area.
+
+
+542 The list of auditable events is entirely dependent on the other functional
+families within the PP/ST. Each family definition should therefore include a
+list of its family-specific auditable events. Each auditable event in the list of
+auditable events specified in the functional family should correspond to one
+of the levels of audit event generation specified in this family (i.e. minimal,
+basic, detailed). This provides the PP/ST author with information necessary
+to ensure that all appropriate auditable events are specified in the PP/ST. The
+following example shows how auditable events are to be specified in
+appropriate functional families:
+
+
+543 โThe following actions should be auditable if Security audit data generation
+(FAU_GEN) is included in the PP/ST:
+
+
+a) Minimal: Successful use of the user security attribute administration
+functions;
+
+
+April 2017 Version 3.1 Page 187 of 323
+
+
+**Class FAU: Security audit**
+
+
+b) Basic: All attempted uses of the user security attribute administration
+functions;
+
+
+c) Basic: Identification of which user security attributes have been
+modified;
+
+
+d) Detailed: With the exception of specific sensitive attribute data items
+(e.g. passwords, cryptographic keys), the new values of the attributes
+should be captured.โ
+
+
+544 For each functional component that is chosen, the auditable events that are
+indicated in that component, at and below the level indicated in Security
+audit data generation (FAU_GEN) should be auditable. If, for example, in
+the previous example โBasicโ would be selected in Security audit data
+generation (FAU_GEN), the auditable events mentioned in a), b) and c)
+should be auditable.
+
+
+545 Observe that the categorisation of auditable events is hierarchical. For
+example, when Basic Audit Generation is desired, all auditable events
+identified as being either Minimal or Basic, should also be included in the
+PP/ST through the use of the appropriate assignment operation, except when
+the higher level event simply provides more detail than the lower level event.
+When Detailed Audit Generation is desired, all identified auditable events
+(Minimal, Basic, and Detailed) should be included in the PP/ST.
+
+
+546 A PP/ST author may decide to include other auditable events beyond those
+required for a given audit level. For example, the PP/ST may claim only
+minimal audit capabilities while including most of the basic capabilities
+because the few excluded capabilities conflict with other PP/ST constraints
+(e.g. because they require the collection of unavailable data).
+
+
+547 The functionality that creates the auditable event should be specified in the
+PP or ST as a functional requirement.
+
+
+548 The following are examples of the types of the events that should be defined
+as auditable within each PP/ST functional component:
+
+
+a) Introduction of objects within the control of the TSF into a subject's
+address space;
+
+
+b) Deletion of objects;
+
+
+c) Distribution or revocation of access rights or capabilities;
+
+
+d) Changes to subject or object security attributes;
+
+
+e) Policy checks performed by the TSF as a result of a request by a
+subject;
+
+
+f) The use of access rights to bypass a policy check;
+
+
+g) Use of Identification and Authentication functions;
+
+
+Page 188 of 323 Version 3.1 April 2017
+
+
+**Class FAU: Security audit**
+
+
+h) Actions taken by an operator, and/or authorised user (e.g. suppression
+of a TSF protection mechanism as human-readable labels);
+
+
+i) Import/export of data from/to removable media (e.g. printed output,
+tapes, diskettes).
+
+
+**FAU_GEN.1** **Audit data generation**
+
+
+User application notes
+
+
+549 This component defines requirements to identify the auditable events for
+which audit records should be generated, and the information to be provided
+in the audit records.
+
+
+550 FAU_GEN.1 Audit data generation by itself might be used when the SFRs
+do not require that individual user identities be associated with audit events.
+This could be appropriate when the PP/ST also contains privacy
+requirements. If the user identity must be incorporated FAU_GEN.2 User
+identity association could be used in addition.
+
+
+551 If the subject is a user, the user identity may be recorded as the subject
+identity. The identity of the user may not yet been verified if User
+authentication (FIA_UAU) has not been applied. Therefore in the instance of
+an invalid login the claimed user identity should be recorded. It should be
+considered to indicate when a recorded identity has not been authenticated.
+
+
+Evaluator notes
+
+
+552 There is a dependency on Time stamps (FPT_STM). If correctness of time is
+not an issue for this TOE, elimination of this dependency could be justified.
+
+
+Operations
+
+
+Selection:
+
+
+553 In **FAU_GEN.1.1**, the PP/ST author should select the level of auditable
+events called out in the audit section of other functional components
+included in the PP/ST. This level is one of the following: โminimumโ,
+โbasicโ, โdetailedโ or โnot specifiedโ.
+
+
+Assignment:
+
+
+554 In **FAU_GEN.1.1**, the PP/ST author should assign a list of other
+specifically defined auditable events to be included in the list of
+auditable events. The assignment may comprise none, or events that
+could be auditable events of a functional requirement that are of a
+higher audit level than requested in b), as well as the events generated
+through the use of a specified Application Programming Interface
+(API).
+
+
+April 2017 Version 3.1 Page 189 of 323
+
+
+**Class FAU: Security audit**
+
+
+555 In **FAU_GEN.1.2**, the PP/ST author should assign, for each auditable
+events included in the PP/ST, either a list of other audit relevant
+information to be included in audit events records or none.
+
+
+**FAU_GEN.2** **User identity association**
+
+
+User application notes
+
+
+556 This component addresses the requirement of accountability of auditable
+events at the level of individual user identity. This component should be used
+in addition to FAU_GEN.1 Audit data generation.
+
+
+557 There is a potential conflict between the audit and privacy requirements. For
+audit purposes it may be desirable to know who performed an action. The
+user may want to keep his/her actions to himself/herself and not be identified
+by other persons (e.g. a site with job offers). Or it might be required in the
+Organisational Security Policy that the identity of the users must be protected.
+In those cases the objectives for audit and privacy might contradict each
+other. Therefore if this requirement is selected and privacy is important,
+inclusion of the component user pseudonimity might be considered.
+Requirements on determining the real user name based on its pseudonym are
+specified in the privacy class.
+
+
+558 If the identity of the user has not yet been verified through authentication, in
+the instance of an invalid login the claimed user identity should be recorded.
+It should be considered to indicate when a recorded identity has not been
+authenticated.
+
+## **C.4 Security audit analysis (FAU_SAA)**
+
+
+User notes
+
+
+559 This family defines requirements for automated means that analyse system
+activity and audit data looking for possible or real security violations. This
+analysis may work in support of intrusion detection, or automatic response to
+a potential security violation.
+
+
+560 The action to be performed by the TSF on detection of a potential violation is
+defined in Security audit automatic response (FAU_ARP) components.
+
+
+561 For real-time analysis, audit data could be transformed into a useful format
+for automated treatment, but into a different useful format for delivery to
+authorised users for review.
+
+
+**FAU_SAA.1** **Potential violation analysis**
+
+
+User application notes
+
+
+562 This component is used to specify the set of auditable events whose
+occurrence or accumulated occurrence held to indicate a potential violation
+of the enforcement of the SFRs, and any rules to be used to perform the
+violation analysis.
+
+
+Page 190 of 323 Version 3.1 April 2017
+
+
+**Class FAU: Security audit**
+
+
+Operations
+
+
+Assignment:
+
+
+563 In **FAU_SAA.1.2**, the PP/ST author should identify the subset of defined
+auditable events whose occurrence or accumulated occurrence need
+to be detected as an indication of a potential violation of the
+enforcement of the SFRs.
+
+
+564 In **FAU_SAA.1.2**, the PP/ST author should specify any other rules that
+the TSF should use in its analysis of the audit trail. Those rules could
+include specific requirements to express the needs for the events to
+occur in a certain period of time (e.g. period of the day, duration). If
+there are no additional rules that the TSF should use in the analysis of
+the audit trail, this assignment can be completed with โnoneโ.
+
+
+**FAU_SAA.2** **Profile based anomaly detection**
+
+
+User application notes
+
+
+565 A _profile_ is a structure that characterises the behaviour of users and/or
+subjects; it represents how the users/subjects interact with the TSF in a
+variety of ways. Patterns of usage are established with respect to the various
+types of activity the users/subjects engage in (e.g. patterns in exceptions
+raised, patterns in resource utilisation (when, which, how), patterns in actions
+performed). The ways in which the various types of activity are recorded in
+the profile (e.g. resource measures, event counters, timers) are referred to as
+_profile metrics_ .
+
+
+566 Each profile represents the expected patterns of usage performed by
+members of the _profile target group_ . This pattern may be based on past use
+(historical patterns) or on normal use for users of similar target groups
+(expected behaviour). A profile target group refers to one or more users who
+interact with the TSF. The activity of each member of the profile group is
+used by the analysis tool in establishing the usage patterns represented in the
+profile. The following are some examples of profile target groups:
+
+
+a) **Single user account** : one profile per user;
+
+
+b) **Group ID or Group Account** : one profile for all users who possess
+the same group ID or operate using the same group account;
+
+
+c) **Operating Role** : one profile for all users sharing a given operating
+role;
+
+
+d) **System** : one profile for all users of a system.
+
+
+567 Each member of a profile target group is assigned an individual _suspicion_
+_rating_ that represents how closely that member's new activity corresponds to
+the established patterns of usage represented in the group profile.
+
+
+April 2017 Version 3.1 Page 191 of 323
+
+
+**Class FAU: Security audit**
+
+
+568 The sophistication of the anomaly detection tool will largely be determined
+by the number of target profile groups required by the PP/ST and the
+complexity of the required profile metrics.
+
+
+569 The PP/ST author should enumerate specifically what activity should be
+monitored and/or analysed by the TSF. The PP/ST author should also
+identify specifically what information pertaining to the activity is necessary
+to construct the usage profiles.
+
+
+570 FAU_SAA.2 Profile based anomaly detection requires that the TSF maintain
+profiles of system usage. The word maintain implies that the anomaly
+detector is actively updating the usage profile based on new activity
+performed by the profile target members. It is important here that the metrics
+for representing user activity are defined by the PP/ST author. For example,
+there may be a thousand different actions an individual may be capable of
+performing, but the anomaly detector may choose to monitor a subset of that
+activity. Anomalous activity gets integrated into the profile just like nonanomalous activity (assuming the tool is monitoring those actions). Things
+that may have appeared anomalous four months ago, might over time
+become the norm (and vice-versa) as the user's work duties change. The TSF
+wouldn't be able to capture this notion if it filtered out anomalous activity
+from the profile updating algorithms.
+
+
+571 Administrative notification should be provided such that the authorised user
+understands the significance of the suspicion rating.
+
+
+572 The PP/ST author should define how to interpret suspicion ratings and the
+conditions under which anomalous activity is indicated to the Security audit
+automatic response (FAU_ARP) mechanism.
+
+
+Operations
+
+
+Assignment:
+
+
+573 In **FAU_SAA.2.1**, the PP/ST author should specify the profile target
+group. A single PP/ST may include multiple profile target groups.
+
+
+574 In **FAU_SAA.2.3**, the PP/ST author should specify conditions under
+which anomalous activity is reported by the TSF. Conditions may
+include the suspicion rating reaching a certain value, or be based on
+the type of anomalous activity observed.
+
+
+**FAU_SAA.3** **Simple attack heuristics**
+
+
+User application notes
+
+
+575 In practice, it is at best rare when an analysis tool can detect with certainty
+when a security violation is imminent. However, there do exist some system
+events that are so significant that they are always worthy of independent
+review. Example of such events include the deletion of a key TSF security
+data file (e.g. the password file) or activity such as a remote user attempting
+
+
+Page 192 of 323 Version 3.1 April 2017
+
+
+**Class FAU: Security audit**
+
+
+to gain administrative privilege. These events are referred to as signature
+events in that their occurrence in isolation from the rest of the system activity
+are indicative of intrusive activity.
+
+
+576 The complexity of a given tool will depend greatly on the assignments
+defined by the PP/ST author in identifying the base set of _signature events_ .
+
+
+577 The PP/ST author should enumerate specifically what events should be
+monitored by the TSF in order to perform the analysis. The PP/ST author
+should identify specifically what information pertaining to the event is
+necessary to determine if the event maps to a signature event.
+
+
+578 Administrative notification should be provided such that the authorised user
+understands the significance of the event and the appropriate possible
+responses.
+
+
+579 An effort was made in the specification of these requirements to avoid a
+dependency on audit data as the sole input for monitoring system activity.
+This was done in recognition of the existence of previously developed
+intrusion detection tools that do not perform their analyses of system activity
+solely through the use of audit data (examples of other input data include
+network datagrams, resource/accounting data, or combinations of various
+system data).
+
+
+580 The elements of FAU_SAA.3 Simple attack heuristics do not require that the
+TSF implementing the immediate attack heuristics be the same TSF whose
+activity is being monitored. Thus, one can develop an intrusion detection
+component that operates independently of the system whose system activity
+is being analysed.
+
+
+Operations
+
+
+Assignment:
+
+
+581 In **FAU_SAA.3.1**, the PP/ST author should identify a base subset of
+system events whose occurrence, in isolation from all other system
+activity, may indicate a violation of the enforcement of the SFRs.
+These include events that by themselves indicate a clear violation to
+the enforcement of the SFRs, or whose occurrence is so significant
+that they warrant actions.
+
+
+582 In **FAU_SAA.3.2**, the PP/ST author should specify the information used
+to determine system activity. This information is the input data used
+by the analysis tool to determine the system activity that has occurred
+on the TOE. This data may include audit data, combinations of audit
+data with other system data, or may consist of data other than the
+audit data. The PP/ST author should define precisely what system
+events and event attributes are being monitored within the input data.
+
+
+April 2017 Version 3.1 Page 193 of 323
+
+
+**Class FAU: Security audit**
+
+
+**FAU_SAA.4** **Complex attack heuristics**
+
+
+User application notes
+
+
+583 In practice, it is at best rare when an analysis tool can detect with certainty
+when a security violation is imminent. However, there do exist some system
+events that are so significant they are always worthy of independent review.
+Example of such events include the deletion of a key TSF security data file
+(e.g. the password file) or activity such as a remote user attempting to gain
+administrative privilege. These events are referred to as signature events in
+that their occurrence in isolation from the rest of the system activity are
+indicative of intrusive activity. Event sequences are an ordered set of
+signature events that might indicate intrusive activity.
+
+
+584 The complexity of a given tool will depend greatly on the assignments
+defined by the PP/ST author in identifying the base set of signature events
+and event sequences.
+
+
+585 The PP/ST author should enumerate specifically what events should be
+monitored by the TSF in order to perform the analysis. The PP/ST author
+should identify specifically what information pertaining to the event is
+necessary to determine if the event maps to a signature event.
+
+
+586 Administrative notification should be provided such that the authorised user
+understands the significance of the event and the appropriate possible
+responses.
+
+
+587 An effort was made in the specification of these requirements to avoid a
+dependency on audit data as the sole input for monitoring system activity.
+This was done in recognition of the existence of previously developed
+intrusion detection tools that do not perform their analyses of system activity
+solely through the use of audit data (examples of other input data include
+network datagrams, resource/accounting data, or combinations of various
+system data). Levelling, therefore, requires the PP/ST author to specify the
+type of input data used to monitor system activity.
+
+
+588 The elements of FAU_SAA.4 Complex attack heuristics do not require that
+the TSF implementing the complex attack heuristics be the same TSF whose
+activity is being monitored. Thus, one can develop an intrusion detection
+component that operates independently of the system whose system activity
+is being analysed.
+
+
+Operations
+
+
+Assignment:
+
+
+589 In **FAU_SAA.4.1**, the PP/ST author should identify a base set of list of
+sequences of system events whose occurrence are representative of
+known penetration scenarios. These event sequences represent known
+penetration scenarios. Each event represented in the sequence should
+map to a monitored system event, such that as the system events are
+
+
+Page 194 of 323 Version 3.1 April 2017
+
+
+**Class FAU: Security audit**
+
+
+performed, they are bound (mapped) to the known penetration event
+sequences.
+
+
+590 In **FAU_SAA.4.1**, the PP/ST author should identify a base subset of
+system events whose occurrence, in isolation from all other system
+activity, may indicate a violation of the enforcement of the SFRs.
+These include events that by themselves indicate a clear violation to
+the SFRs, or whose occurrence is so significant they warrant action.
+
+
+591 In **FAU_SAA.4.2**, the PP/ST author should specify the information used
+to determine system activity. This information is the input data used
+by the analysis tool to determine the system activity that has occurred
+on the TOE. This data may include audit data, combinations of audit
+data with other system data, or may consist of data other than the
+audit data. The PP/ST author should define precisely what system
+events and event attributes are being monitored within the input data.
+
+## **C.5 Security audit review (FAU_SAR)**
+
+
+User notes
+
+
+592 The Security audit review family defines requirements related to review of
+the audit information.
+
+
+593 These functions should allow pre-storage or post-storage audit selection that
+includes, for example, the ability to selectively review:
+
+
+๏ญ the actions of one or more users (e.g. identification, authentication,
+TOE entry, and access control actions);
+
+
+๏ญ the actions performed on a specific object or TOE resource;
+
+
+๏ญ all of a specified set of audited exceptions; or
+
+
+๏ญ actions associated with a specific SFR attribute.
+
+
+594 The distinction between audit reviews is based on functionality. Audit review
+(only) encompasses the ability to view audit data. Selectable review is more
+sophisticated, and requires the ability to select subsets of audit data based on
+a single criterion or multiple criteria with logical (i.e. and/or) relations, and
+order the audit data before it is reviewed.
+
+
+**FAU_SAR.1** **Audit review**
+
+
+Rationale
+
+
+595 This component will provide authorised users the capability to obtain and
+interpret the information. In case of human users this information needs to be
+in a human understandable presentation. In case of external IT entities the
+information needs to be unambiguously represented in an electronic fashion.
+
+
+April 2017 Version 3.1 Page 195 of 323
+
+
+**Class FAU: Security audit**
+
+
+User application notes
+
+
+596 This component is used to specify that users and/or authorised users can read
+the audit records. These audit records will be provided in a manner
+appropriate to the user. There are different types of users (human users,
+machine users) that might have different needs.
+
+
+597 The content of the audit records that can be viewed can be specified.
+
+
+Operations
+
+
+Assignment:
+
+
+598 In **FAU_SAR.1.1**, the PP/ST author should specify the authorised users
+that can use this capability. If appropriate the PP/ST author may
+include security roles (see FMT_SMR.1 Security roles).
+
+
+599 In **FAU_SAR.1.1**, the PP/ST author should specify the type of
+information the specified user is permitted to obtain from the audit
+records. Examples are โallโ, โsubject identityโ, โall information
+belonging to audit records referencing this userโ. When employing
+the SFR, FAU_SAR.1, it is not necessary to repeat, in full detail, the
+list of audit information first specified in FAU_GEN.1. Use of terms
+such as โallโ or โall audit informationโ assist in eliminating
+ambiguity and the further need for comparative analysis between the
+two security requirements.
+
+
+**FAU_SAR.2** **Restricted audit review**
+
+
+User application notes
+
+
+600 This component specifies that any users not identified in FAU_SAR.1 Audit
+review will not be able to read the audit records.
+
+
+**FAU_SAR.3** **Selectable audit review**
+
+
+User application notes
+
+
+601 This component is used to specify that it should be possible to perform
+selection of the audit data to be reviewed. If based on multiple criteria, those
+criteria should be related together with logical (i.e. โandโ or โorโ) relations,
+and the tools should provide the ability to manipulate audit data (e.g. sort,
+filter).
+
+
+Operations
+
+
+Assignment:
+
+
+602 In **FAU_SAR.3.1**, the PP/ST author should specify whether capabilities
+to select and/or order audit data is required from the TSF.
+
+
+Page 196 of 323 Version 3.1 April 2017
+
+
+**Class FAU: Security audit**
+
+
+603 In **FAU_SAR.3.1**, the PP/ST author should assign the criteria, possibly
+with logical relations, to be used to select the audit data for review.
+The logical relations are intended to specify whether the operation
+can be on an individual attribute or a collection of attributes. An
+example of this assignment could be: โapplication, user account
+and/or locationโ. In this case the operation could be specified using
+any combination of the three attributes: application, user account and
+location.
+
+## **C.6 Security audit event selection (FAU_SEL)**
+
+
+User notes
+
+
+604 The Security audit event selection family provides requirements related to
+the capabilities of identifying which of the possible auditable events are to be
+audited. The auditable events are defined in the Security audit data
+generation (FAU_GEN) family, but those events should be defined as being
+selectable in this component to be audited.
+
+
+605 This family ensures that it is possible to keep the audit trail from becoming
+so large that it becomes useless, by defining the appropriate granularity of
+the selected security audit events.
+
+
+**FAU_SEL.1** **Selective audit**
+
+
+User application notes
+
+
+606 This component defines the selection criteria used, and the resulting audited
+subsets of the set of all auditable events, based on user attributes, subject
+attributes, object attributes, or event types.
+
+
+607 The existence of individual user identities is not assumed for this component.
+This allows for TOEs such as routers that may not support the notion of users.
+
+
+608 For a distributed environment, the host identity could be used as a selection
+criteria for events to be audited.
+
+
+609 The management function FMT_MTD.1 Management of TSF data will
+handle the rights of authorised users to query or modify the selections.
+
+
+Operations
+
+
+Selection:
+
+
+610 In **FAU_SEL.1.1**, the PP/ST author should select whether the security
+attributes upon which audit selectivity is based, is related to object
+identity, user identity, subject identity, host identity, or event type.
+
+
+Assignment:
+
+
+611 In **FAU_SEL.1.1**, the PP/ST author should specify any additional
+attributes upon which audit selectivity is based. If there are no
+
+
+April 2017 Version 3.1 Page 197 of 323
+
+
+**Class FAU: Security audit**
+
+
+additional rules upon which audit selectivity is based, this assignment
+can be completed with โnoneโ.
+
+## **C.7 Security audit event storage (FAU_STG)**
+
+
+User notes
+
+
+612 The Security audit event storage family describes requirements for storing
+audit data for later use, including requirements controlling the loss of audit
+information due to TOE failure, attack and/or exhaustion of storage space.
+
+
+**FAU_STG.1** **Protected audit trail storage**
+
+
+User application notes
+
+
+613 In a distributed environment, as the location of the audit trail is in the TSF,
+but not necessarily co-located with the function generating the audit data, the
+PP/ST author could request authentication of the originator of the audit
+record, or non-repudiation of the origin of the record prior storing this record
+in the audit trail.
+
+
+614 The TSF will protect the stored audit records in the audit trail from
+unauthorised deletion and modification. It is noted that in some TOEs the
+auditor (role) might not be authorised to delete the audit records for a certain
+period of time.
+
+
+Operations
+
+
+Selection:
+
+
+615 In **FAU_STG.1.2**, the PP/ST author should specify whether the TSF
+shall prevent or only be able to detect modifications of the stored
+audit records in the audit trail. Only one of these options may be
+chosen.
+
+
+**FAU_STG.2** **Guarantees of audit data availability**
+
+
+User application notes
+
+
+616 This component allows the PP/ST author to specify to which metrics the
+audit trail should conform.
+
+
+617 In a distributed environment, as the location of the audit trail is in the TSF,
+but not necessarily co-located with the function generating the audit data, the
+PP/ST author could request authentication of the originator of the audit
+record, or non-repudiation of the origin of the record prior storing this record
+in the audit trail.
+
+
+Page 198 of 323 Version 3.1 April 2017
+
+
+**Class FAU: Security audit**
+
+
+Operations
+
+
+Selection:
+
+
+618 In **FAU_STG.2.2**, the PP/ST author should specify whether the TSF
+shall prevent or only be able to detect modifications of the stored
+audit records in the audit trail. Only one of these options may be
+chosen.
+
+
+Assignment:
+
+
+619 In **FAU_STG.2.3**, the PP/ST author should specify the metric that the
+TSF must ensure with respect to the stored audit records. This metric
+limits the data loss by enumerating the number of records that must
+be kept, or the time that records are guaranteed to be maintained. An
+example of the metric could be โ100,000โ indicating that 100,000
+audit records can be stored.
+
+
+Selection:
+
+
+620 In **FAU_STG.2.3**, the PP/ST author should specify the condition under
+which the TSF shall still be able to maintain a defined amount of
+audit data. This condition can be any of the following: audit storage
+exhaustion, failure, attack.
+
+
+**FAU_STG.3** **Action in case of possible audit data loss**
+
+
+User application notes
+
+
+621 This component requires that actions will be taken when the audit trail
+exceeds certain pre-defined limits.
+
+
+Operations
+
+
+Assignment:
+
+
+622 In **FAU_STG.3.1**, the PP/ST author should indicate the pre-defined limit.
+If the management functions indicate that this number might be
+changed by the authorised user, this value is the default value. The
+PP/ST author might choose to let the authorised user define this limit.
+In that case the assignment can be for example โan authorised user set
+limitโ.
+
+
+623 In **FAU_STG.3.1**, the PP/ST author should specify actions that should be
+taken in case of imminent audit storage failure indicated by
+exceeding the threshold. Actions might include informing an
+authorised user.
+
+
+April 2017 Version 3.1 Page 199 of 323
+
+
+**Class FAU: Security audit**
+
+
+**FAU_STG.4** **Prevention of audit data loss**
+
+
+User application notes
+
+
+624 This component specifies the behaviour of the TOE if the audit trail is full:
+either audit records are ignored, or the TOE is frozen such that no audited
+events can take place. The requirement also states that no matter how the
+requirement is instantiated, the authorised user with specific rights to this
+effect, can continue to generate audited events (actions). The reason is that
+otherwise the authorised user could not even reset the TOE. Consideration
+should be given to the choice of the action to be taken by the TSF in the case
+of audit storage exhaustion, as ignoring events, which provides better
+availability of the TOE, will also permit actions to be performed without
+being recorded and without the user being accountable.
+
+
+Operations
+
+
+Selection:
+
+
+625 In **FAU_STG.4.1**, the PP/ST author should select whether the TSF shall
+ignore audited actions, or whether it should prevent audited actions
+from happening, or whether the oldest audit records should be
+overwritten when the TSF can no longer store audit records. Only one
+of these options may be chosen.
+
+
+Assignment:
+
+
+626 In **FAU_STG.4.1**, the PP/ST author should specify other actions that
+should be taken in case of audit storage failure, such as informing the
+authorised user. If there is no other action to be taken in case of audit
+storage failure, this assignment can be completed with โnoneโ.
+
+
+Page 200 of 323 Version 3.1 April 2017
+
+
+**Class FCO: Communication**
+
+# **D Class FCO: Communication** **(normative)**
+
+
+627 This class describes requirements specifically of interest for TOEs that are
+used for the transport of information. Families within this class deal with
+non-repudiation.
+
+
+628 In this class the concept of โinformationโ is used. This information should be
+interpreted as the object being communicated, and could contain an
+electronic mail message, a file, or a set of predefined attribute types.
+
+
+629 In the literature, the terms โproof of receiptโ and โproof of originโ are
+commonly used terms. However it is recognised that the term โproofโ might
+be interpreted in a legal sense to imply a form of mathematical rationale. The
+components in this class interpret the de-facto use of the word โproofโ in the
+context of โevidenceโ that the TSF demonstrates the non-repudiated transport
+of types of information.
+
+
+630 Figure 22 shows the decomposition of this class into its constituent
+components.
+
+
+**Figure 22 - FCO: Communication class decomposition**
+
+## **D.1 Non-repudiation of origin (FCO_NRO)**
+
+
+User notes
+
+
+631 Non-repudiation of origin defines requirements to provide evidence to
+users/subjects about the identity of the originator of some information. The
+originator cannot successfully deny having sent the information because
+evidence of origin (e.g. digital signature) provides evidence of the binding
+between the originator and the information sent. The recipient or a third party
+can verify the evidence of origin. This evidence should not be forgeable.
+
+
+632 If the information or the associated attributes are altered in any way,
+validation of the evidence of origin might fail. Therefore a PP/ST author
+should consider including integrity requirements such as FDP_UIT.1 Data
+exchange integrity in the PP/ST.
+
+
+633 In non-repudiation there are several different roles involved, each of which
+could be combined in one or more subjects. The first role is a subject that
+requests evidence of origin (only in FCO_NRO.1 Selective proof of origin).
+
+
+April 2017 Version 3.1 Page 201 of 323
+
+
+**Class FCO: Communication**
+
+
+The second role is the recipient and/or other subjects to which the evidence is
+provided (e.g. a notary). The third role is a subject that requests verification
+of the evidence of origin, for example, a recipient or a third party such as an
+arbiter.
+
+
+634 The PP/ST author must specify the conditions that must be met to be able to
+verify the validity of the evidence. An example of a condition which could
+be specified is where the verification of evidence must occur within 24 hours.
+These conditions, therefore, allow the tailoring of the non-repudiation to
+legal requirements, such as being able to provide evidence for several years.
+
+
+635 In most cases, the identity of the recipient will be the identity of the user who
+received the transmission. In some instances, the PP/ST author does not want
+the user identity to be exported. In that case the PP/ST author must consider
+whether it is appropriate to include this class, or whether the identity of the
+transport service provider or the identity of the host should be used.
+
+
+636 In addition to (or instead of) the user identity, a PP/ST author might be more
+concerned about the time the information was transmitted. For example,
+requests for proposals must be transmitted before a certain date in order to be
+considered. In such instances, these requirements can be customised to
+provide a timestamp indication (time of origin).
+
+
+**FCO_NRO.1** **Selective proof of origin**
+
+
+Operations
+
+
+Assignment:
+
+
+637 In **FCO_NRO.1.1**, the PP/ST author should fill in the types of
+information subject to the evidence of origin function, for example,
+electronic mail messages.
+
+
+Selection:
+
+
+638 In **FCO_NRO.1.1**, the PP/ST author should specify the user/subject who
+can request evidence of origin.
+
+
+Assignment:
+
+
+639 In **FCO_NRO.1.1**, the PP/ST author, dependent on the selection, should
+specify the third parties that can request evidence of origin. A third
+party could be an arbiter, judge or legal body.
+
+
+640 In **FCO_NRO.1.2**, the PP/ST author should fill in the list of the attributes
+that shall be linked to the information; for example, originator
+identity, time of origin, and location of origin.
+
+
+641 In **FCO_NRO.1.2**, the PP/ST author should fill in the list of information
+fields within the information over which the attributes provide
+evidence of origin, such as the body of a message.
+
+
+Page 202 of 323 Version 3.1 April 2017
+
+
+**Class FCO: Communication**
+
+
+Selection:
+
+
+642 In **FCO_NRO.1.3**, the PP/ST author should specify the user/subject who
+can verify the evidence of origin.
+
+
+Assignment:
+
+
+643 In **FCO_NRO.1.3**, the PP/ST author should fill in the list of limitations
+under which the evidence can be verified. For example the evidence
+can only be verified within a 24 hour time interval. An assignment of
+โimmediateโ or โindefiniteโ is acceptable.
+
+
+644 In **FCO_NRO.1.3**, the PP/ST author, dependent on the selection, should
+specify the third parties that can verify the evidence of origin.
+
+
+**FCO_NRO.2** **Enforced proof of origin**
+
+
+Operations
+
+
+Assignment:
+
+
+645 In **FCO_NRO.2.1**, the PP/ST author should fill in the types of
+information subject to the evidence of origin function, for example,
+electronic mail messages.
+
+
+646 In **FCO_NRO.2.2**, the PP/ST author should fill in the list of the attributes
+that shall be linked to the information; for example, originator
+identity, time of origin, and location of origin.
+
+
+647 In **FCO_NRO.2.2**, the PP/ST author should fill in the list of information
+fields within the information over which the attributes provide
+evidence of origin, such as the body of a message.
+
+
+Selection:
+
+
+648 In **FCO_NRO.2.3**, the PP/ST author should specify the user/subject who
+can verify the evidence of origin.
+
+
+Assignment:
+
+
+649 In **FCO_NRO.2.3**, the PP/ST author should fill in the list of limitations
+under which the evidence can be verified. For example the evidence
+can only be verified within a 24 hour time interval. An assignment of
+โimmediateโ or โindefiniteโ is acceptable.
+
+
+650 In **FCO_NRO.2.3**, the PP/ST author, dependent on the selection, should
+specify the third parties that can verify the evidence of origin. A third
+party could be an arbiter, judge or legal body.
+
+
+April 2017 Version 3.1 Page 203 of 323
+
+
+**Class FCO: Communication**
+
+## **D.2 Non-repudiation of receipt (FCO_NRR)**
+
+
+User notes
+
+
+651 Non-repudiation of receipt defines requirements to provide evidence to other
+users/subjects that the information was received by the recipient. The
+recipient cannot successfully deny having received the information because
+evidence of receipt (e.g. digital signature) provides evidence of the binding
+between the recipient attributes and the information. The originator or a third
+party can verify the evidence of receipt. This evidence should not be
+forgeable.
+
+
+652 It should be noted that the provision of evidence that the information was
+received does not necessarily imply that the information was read or
+comprehended, but only delivered
+
+
+653 If the information or the associated attributes are altered in any way,
+validation of the evidence of receipt with respect to the original information
+might fail. Therefore a PP/ST author should consider including integrity
+requirements such as FDP_UIT.1 Data exchange integrity in the PP/ST.
+
+
+654 In non-repudiation, there are several different roles involved, each of which
+could be combined in one or more subjects. The first role is a subject that
+requests evidence of receipt (only in FCO_NRR.1 Selective proof of receipt).
+The second role is the recipient and/or other subjects to which the evidence is
+provided, (e.g. a notary). The third role is a subject that requests verification
+of the evidence of receipt, for example, an originator or a third party such as
+an arbiter.
+
+
+655 The PP/ST author must specify the conditions that must be met to be able to
+verify the validity of the evidence. An example of a condition which could
+be specified is where the verification of evidence must occur within 24 hours.
+These conditions, therefore, allow the tailoring of the non-repudiation to
+legal requirements, such as being able to provide evidence for several years.
+
+
+656 In most cases, the identity of the recipient will be the identity of the user who
+received the transmission. In some instances, the PP/ST author does not want
+the user identity to be exported. In that case, the PP/ST author must consider
+whether it is appropriate to include this class, or whether the identity of the
+transport service provider or the identity of the host should be used.
+
+
+657 In addition to (or instead of) the user identity, a PP/ST author might be more
+concerned about the time the information was received. For example, when
+an offer expires at a certain date, orders must be received before a certain
+date in order to be considered. In such instances, these requirements can be
+customised to provide a timestamp indication (time of receipt).
+
+
+Page 204 of 323 Version 3.1 April 2017
+
+
+**Class FCO: Communication**
+
+
+**FCO_NRR.1** **Selective proof of receipt**
+
+
+Operations
+
+
+Assignment:
+
+
+658 In **FCO_NRR.1.1**, the PP/ST author should fill in the types of
+information subject to the evidence of receipt function, for example,
+electronic mail messages.
+
+
+Selection:
+
+
+659 In **FCO_NRR.1.1**, the PP/ST author should specify the user/subject who
+can request evidence of receipt.
+
+
+Assignment:
+
+
+660 In **FCO_NRR.1.1**, the PP/ST author, dependent on the selection, should
+specify the third parties that can request evidence of receipt. A third
+party could be an arbiter, judge or legal body.
+
+
+661 In **FCO_NRR.1.2**, the PP/ST author should fill in the list of the attributes
+that shall be linked to the information; for example, recipient identity,
+time of receipt, and location of receipt.
+
+
+662 In **FCO_NRR.1.2**, the PP/ST author should fill in the list of information
+fields with the fields within the information over which the attributes
+provide evidence of receipt, such as the body a message.
+
+
+Selection:
+
+
+663 In **FCO_NRR.1.3**, the PP/ST author should specify the user/subjects
+who can verify the evidence of receipt.
+
+
+Assignment:
+
+
+664 In **FCO_NRR.1.3**, the PP/ST author should fill in the list of limitations
+under which the evidence can be verified. For example the evidence
+can only be verified within a 24 hour time interval. An assignment of
+โimmediateโ or โindefiniteโ is acceptable.
+
+
+665 In **FCO_NRR.1.3**, the PP/ST author, dependent on the selection, should
+specify the third parties that can verify the evidence of receipt.
+
+
+April 2017 Version 3.1 Page 205 of 323
+
+
+**Class FCO: Communication**
+
+
+**FCO_NRR.2** **Enforced proof of receipt**
+
+
+Operations
+
+
+Assignment:
+
+
+666 In **FCO_NRR.2.1**, the PP/ST author should fill in the types of
+information subject to the evidence of receipt function, for example
+electronic mail messages.
+
+
+667 In **FCO_NRR.2.2**, the PP/ST author should fill in the list of the attributes
+that shall be linked to the information; for example, recipient identity,
+time of receipt, and location of receipt.
+
+
+668 In **FCO_NRR.2.2**, the PP/ST author should fill in the list of information
+fields with the fields within the information over which the attributes
+provide evidence of receipt, such as the body of a message.
+
+
+Selection:
+
+
+669 In **FCO_NRR.2.3**, the PP/ST author should specify the user/subjects
+who can verify the evidence of receipt.
+
+
+Assignment:
+
+
+670 In **FCO_NRR.2.3**, the PP/ST author should fill in the list of limitations
+under which the evidence can be verified. For example the evidence
+can only be verified within a 24 hour time interval. An assignment of
+โimmediateโ or โindefiniteโ is acceptable.
+
+
+671 In **FCO_NRR.2.3**, the PP/ST author, dependent on the selection, should
+specify the third parties that can verify the evidence of receipt. A
+third party could be an arbiter, judge or legal body.
+
+
+Page 206 of 323 Version 3.1 April 2017
+
+
+**Class FCS: Cryptographic support**
+
+# **E Class FCS: Cryptographic support** **(normative)**
+
+
+672 The TSF may employ cryptographic functionality to help satisfy several
+high-level security objectives. These include (but are not limited to):
+identification and authentication, non-repudiation, trusted path, trusted
+channel and data separation. This class is used when the TOE implements
+cryptographic functions, the implementation of which could be in hardware,
+firmware and/or software.
+
+
+673 The FCS: Cryptographic support class is composed of two families:
+Cryptographic key management (FCS_CKM) and Cryptographic operation
+(FCS_COP). The Cryptographic key management (FCS_CKM) family
+addresses the management aspects of cryptographic keys, while the
+Cryptographic operation (FCS_COP) family is concerned with the
+operational use of those cryptographic keys.
+
+
+674 For each cryptographic key generation method implemented by the TOE, if
+any, the PP/ST author should select the FCS_CKM.1 Cryptographic key
+generation component.
+
+
+675 For each cryptographic key distribution method implemented by the TOE, if
+any, the PP/ST author should select the FCS_CKM.2 Cryptographic key
+distribution component.
+
+
+676 For each cryptographic key access method implemented by the TOE, if any,
+the PP/ST author should select the FCS_CKM.3 Cryptographic key access
+component.
+
+
+677 For each cryptographic key destruction method implemented by the TOE, if
+any, the PP/ST author should select the FCS_CKM.4 Cryptographic key
+destruction component.
+
+
+678 For each cryptographic operation (such as digital signature, data encryption,
+key agreement, secure hash, etc.) performed by the TOE, if any, the PP/ST
+author should select the FCS_COP.1 Cryptographic operation component.
+
+
+679 Cryptographic functionality may be used to meet objectives specified in class
+FCO: Communication, and in families Data authentication (FDP_DAU),
+Stored data integrity (FDP_SDI), Inter-TSF user data confidentiality transfer
+protection (FDP_UCT), Inter-TSF user data integrity transfer protection
+(FDP_UIT), Specification of secrets (FIA_SOS), User authentication
+(FIA_UAU), to meet a variety of objectives. In the cases where
+cryptographic functionality is used to meet objectives for other classes, the
+individual functional components specify the objectives that cryptographic
+functionality must satisfy. The objectives in class FCS: Cryptographic
+support should be used when cryptographic functionality of the TOE is
+sought by consumers.
+
+
+April 2017 Version 3.1 Page 207 of 323
+
+
+**Class FCS: Cryptographic support**
+
+
+680 Figure 23 shows the decomposition of this class into its constituent
+components.
+
+
+**Figure 23 - FCS: Cryptographic support class decomposition**
+
+## **E.1 Cryptographic key management (FCS_CKM)**
+
+
+User notes
+
+
+681 Cryptographic keys must be managed throughout their lifetime. The typical
+events in the lifecycle of a cryptographic key include (but are not limited to):
+generation, distribution, entry, storage, access (e.g. backup, escrow, archive,
+recovery) and destruction.
+
+
+682 The inclusion of other stages is dependent on the key management strategy
+being implemented, as the TOE need not be involved in all of the key lifecycle (e.g. the TOE may only generate and distribute cryptographic keys).
+
+
+683 This family is intended to support the cryptographic key lifecycle and
+consequently defines requirements for the following activities: cryptographic
+key generation, cryptographic key distribution, cryptographic key access and
+cryptographic key destruction. This family should be included whenever
+there are functional requirements for the management of cryptographic keys.
+
+
+684 If Security audit data generation (FAU_GEN) Security Audit Data
+Generation is included in the PP/ST then, in the context of the events being
+audited:
+
+
+a) The object attributes may include the assigned user for the
+cryptographic key, the user role, the cryptographic operation that the
+cryptographic key is to be used for, the cryptographic key identifier
+and the cryptographic key validity period.
+
+
+Page 208 of 323 Version 3.1 April 2017
+
+
+**Class FCS: Cryptographic support**
+
+
+b) The object value may include the values of cryptographic key(s) and
+parameters excluding any sensitive information (such as secret or
+private cryptographic keys).
+
+
+685 Typically, random numbers are used to generate cryptographic keys. If this is
+the case, then FCS_CKM.1 Cryptographic key generation should be used
+instead of the component FIA_SOS.2 TSF Generation of secrets. In cases
+where random number generation is required for purposes other than for the
+generation of cryptographic keys, the component FIA_SOS.2 TSF
+Generation of secrets should be used.
+
+
+**FCS_CKM.1** **Cryptographic key generation**
+
+
+User application notes
+
+
+686 This component requires the cryptographic key sizes and method used to
+generate cryptographic keys to be specified, this can be in accordance with
+an assigned standard. It should be used to specify the cryptographic key sizes
+and the method (e.g. algorithm) used to generate the cryptographic keys.
+Only one instance of the component is needed for the same method and
+multiple key sizes. The key size could be common or different for the
+various entities, and could be either the input to or the output from the
+method.
+
+
+Operations
+
+
+Assignment:
+
+
+687 In **FCS_CKM.1.1**, the PP/ST author should specify the cryptographic
+key generation algorithm to be used.
+
+
+688 In **FCS_CKM.1.1**, the PP/ST author should specify the cryptographic
+key sizes to be used. The key sizes specified should be appropriate
+for the algorithm and its intended use.
+
+
+689 In **FCS_CKM.1.1**, the PP/ST author should specify the assigned
+standard that documents the method used to generate cryptographic
+keys. The assigned standard may comprise none, one or more actual
+standards publications, for example, from international, national,
+industry or organisational standards.
+
+
+**FCS_CKM.2** **Cryptographic key distribution**
+
+
+User application notes
+
+
+690 This component requires the method used to distribute cryptographic keys to
+be specified, this can be in accordance with an assigned standard.
+
+
+April 2017 Version 3.1 Page 209 of 323
+
+
+**Class FCS: Cryptographic support**
+
+
+Operations
+
+
+Assignment:
+
+
+691 In **FCS_CKM.2.1**, the PP/ST author should specify the cryptographic
+key distribution method to be used.
+
+
+692 In **FCS_CKM.2.1**, the PP/ST author should specify the assigned
+standard that documents the method used to distribute cryptographic
+keys. The assigned standard may comprise none, one or more actual
+standards publications, for example, from international, national,
+industry or organisational standards.
+
+
+**FCS_CKM.3** **Cryptographic key access**
+
+
+User application notes
+
+
+693 This component requires the method used to access cryptographic keys be
+specified, this can be in accordance with an assigned standard.
+
+
+Operations
+
+
+Assignment:
+
+
+694 In **FCS_CKM.3.1**, the PP/ST author should specify the type of
+cryptographic key access being used. Examples of types of
+cryptographic key access include (but are not limited to)
+cryptographic key backup, cryptographic key archival, cryptographic
+key escrow and cryptographic key recovery.
+
+
+695 In **FCS_CKM.3.1**, the PP/ST author should specify the cryptographic
+key access method to be used.
+
+
+696 In **FCS_CKM.3.1**, the PP/ST author should specify the assigned
+standard that documents the method used to access cryptographic
+keys. The assigned standard may comprise none, one or more actual
+standards publications, for example, from international, national,
+industry or organisational standards.
+
+
+**FCS_CKM.4** **Cryptographic key destruction**
+
+
+User application notes
+
+
+697 This component requires the method used to destroy cryptographic keys be
+specified, this can be in accordance with an assigned standard.
+
+
+Operations
+
+
+Assignment:
+
+
+698 In **FCS_CKM.4.1**, the PP/ST author should specify the key destruction
+method to be used to destroy cryptographic keys.
+
+
+Page 210 of 323 Version 3.1 April 2017
+
+
+**Class FCS: Cryptographic support**
+
+
+699 In **FCS_CKM.4.1**, the PP/ST author should specify the assigned
+standard that documents the method used to destroy cryptographic
+keys. The assigned standard may comprise none, one or more actual
+standards publications, for example, from international, national,
+industry or organisational standards.
+
+## **E.2 Cryptographic operation (FCS_COP)**
+
+
+User notes
+
+
+700 A cryptographic operation may have cryptographic mode(s) of operation
+associated with it. If this is the case, then the cryptographic mode(s) must be
+specified. Examples of cryptographic modes of operation are cipher block
+chaining, output feedback mode, electronic code book mode, and cipher
+feedback mode.
+
+
+701 Cryptographic operations may be used to support one or more TOE security
+services. The Cryptographic operation (FCS_COP) component may need to
+be iterated more than once depending on:
+
+
+a) the user application for which the security service is being used.
+
+
+b) the use of different cryptographic algorithms and/or cryptographic
+key sizes.
+
+
+c) the type or sensitivity of the data being operated on.
+
+
+702 If Security audit data generation (FAU_GEN) Security audit data generation
+is included in the PP/ST then, in the context of the cryptographic operation
+events being audited:
+
+
+a) The types of cryptographic operation may include digital signature
+generation and/or verification, cryptographic checksum generation
+for integrity and/or for verification of checksum, secure hash
+(message digest) computation, data encryption and/or decryption,
+cryptographic key encryption and/or decryption, cryptographic key
+agreement and random number generation.
+
+
+b) The subject attributes may include subject role(s) and user(s)
+associated with the subject.
+
+
+c) The object attributes may include the assigned user for the
+cryptographic key, user role, cryptographic operation the
+cryptographic key is to be used for, cryptographic key identifier, and
+the cryptographic key validity period.
+
+
+April 2017 Version 3.1 Page 211 of 323
+
+
+**Class FCS: Cryptographic support**
+
+
+**FCS_COP.1** **Cryptographic operation**
+
+
+User application notes
+
+
+703 This component requires the cryptographic algorithm and key size used to
+perform specified cryptographic operation(s) which can be based on an
+assigned standard.
+
+
+Operations
+
+
+Assignment:
+
+
+704 In **FCS_COP.1.1**, the PP/ST author should specify the cryptographic
+operations being performed. Typical cryptographic operations include
+digital signature generation and/or verification, cryptographic
+checksum generation for integrity and/or for verification of checksum,
+secure hash (message digest) computation, data encryption and/or
+decryption, cryptographic key encryption and/or decryption,
+cryptographic key agreement and random number generation. The
+cryptographic operation may be performed on user data or TSF data.
+
+
+705 In **FCS_COP.1.1**, the PP/ST author should specify the cryptographic
+algorithm to be used. Typical cryptographic algorithms include, but
+are not limited to, DES, RSA and IDEA.
+
+
+706 In **FCS_COP.1.1**, the PP/ST author should specify the cryptographic key
+sizes to be used. The key sizes specified should be appropriate for the
+algorithm and its intended use.
+
+
+707 In **FCS_COP.1.1**, the PP/ST author should specify the assigned standard
+that documents how the identified cryptographic operation(s) are
+performed. The assigned standard may comprise none, one or more
+actual standards publications, for example, from international,
+national, industry or organisational standards.
+
+
+Page 212 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+# **F Class FDP: User data protection** **(normative)**
+
+
+708 This class contains families specifying requirements related to protecting
+user data. This class differs from FIA and FPT in that FDP: User data
+protection specifies components to protect user data, FIA specifies
+components to protect attributes associated with the user, and FPT specifies
+components to protect TSF information.
+
+
+709 The class does not contain explicit requirements for traditional Mandatory
+Access Controls (MAC) or traditional Discretionary Access Controls (DAC);
+however, such requirements may be constructed using components from this
+class.
+
+
+710 FDP: User data protection does not explicitly deal with confidentiality,
+integrity, or availability, as all three are most often intertwined in the policy
+and mechanisms. However, the TOE security policy must adequately cover
+these three objectives in the PP/ST.
+
+
+711 A final aspect of this class is that it specifies access control in terms of
+โoperationsโ. An operation is defined as a specific type of access on a
+specific object. It depends on the level of abstraction of the PP/ST author
+whether these operations are described as โreadโ and/or โwriteโ operations,
+or as more complex operations such as โupdate the databaseโ.
+
+
+712 The access control policies are policies that control access to the information
+container. The attributes represent attributes of the container. Once the
+information is out of the container, the accessor is free to modify that
+information, including writing the information into a different container with
+different attributes. By contrast, an information flow policies controls access
+to the information, independent of the container. The attributes of the
+information, which may be associated with the attributes of the container (or
+may not, as in the case of a multi-level database) stay with the information as
+it moves. The accessor does not have the ability, in the absence of an explicit
+authorisation, to change the attributes of the information.
+
+
+713 This class is not meant to be a complete taxonomy of IT access policies, as
+others can be imagined. Those policies included here are simply those for
+which current experience with actual systems provides a basis for specifying
+requirements. There may be other forms of intent that are not captured in the
+definitions here.
+
+
+714 For example, one could imagine a goal of having user-imposed (and userdefined) controls on information flow (e.g. an automated implementation of
+the NO FOREIGN handling caveat). Such concepts could be handled as
+refinements of, or extensions to the FDP: User data protection components.
+
+
+April 2017 Version 3.1 Page 213 of 323
+
+
+**Class FDP: User data protection**
+
+
+715 Finally, it is important when looking at the components in FDP: User data
+protection to remember that these components are requirements for functions
+that may be implemented by a mechanism that also serves or could serve
+another purpose. For example, it is possible to build an access control policy
+(Access control policy (FDP_ACC)) that uses labels (FDP_IFF.1 Simple
+security attributes) as the basis of the access control mechanism.
+
+
+716 A set of SFRs may encompass many security function policies (SFPs), each
+to be identified by the two policy oriented components Access control policy
+(FDP_ACC), and Information flow control policy (FDP_IFC). These policies
+will typically take confidentiality, integrity, and availability aspects into
+consideration as required, to satisfy the TOE requirements. Care should be
+taken to ensure that all objects are covered by at least one SFP and that there
+are no conflicts arising from implementing the multiple SFPs.
+
+
+717 When building a PP/ST using components from the FDP: User data
+protection class, the following information provides guidance on where to
+look and what to select from the class.
+
+
+718 The requirements in the FDP: User data protection class are defined in terms
+of a set of SFRs that will implement a SFP. Since a TOE may implement
+multiple SFPs simultaneously, the PP/ST author must specify the name for
+each SFP, so it can be referenced in other families. This name will then be
+used in each component selected to indicate that it is being used as part of the
+definition of requirements for that SFP. This allows the author to easily
+indicate the scope for operations such as objects covered, operations covered,
+authorised users, etc.
+
+
+719 Each instantiation of a component can apply to only one SFP. Therefore if an
+SFP is specified in a component then this SFP will apply to all the elements
+in this component. The components may be instantiated multiple times
+within a PP/ST to account for different policies if so desired.
+
+
+720 The key to selecting components from this family is to have a well defined
+set of TOE security objectives to enable proper selection of the components
+from the two policy components; Access control policy (FDP_ACC) and
+Information flow control policy (FDP_IFC). In Access control policy
+(FDP_ACC) and Information flow control policy (FDP_IFC) respectively,
+all access control policies and all information flow control policies are
+named. Furthermore the scope of control of these components in terms of the
+subjects, objects and operations covered by this security functionality. The
+names of these policies are meant to be used throughout the remainder of the
+functional components that have an operation that calls for an assignment or
+selection of an โaccess control SFPโ or an โinformation flow control SFPโ.
+The rules that define the functionality of the named access control and
+information flow control SFPs will be defined in the Access control
+functions (FDP_ACF) and Information flow control functions (FDP_IFF)
+families (respectively).
+
+
+721 The following steps are guidance on how this class is applied in the
+construction of a PP/ST:
+
+
+Page 214 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+
+a) Identify the policies to be enforced from the Access control policy
+(FDP_ACC), and Information flow control policy (FDP_IFC)
+families. These families define scope of control for the policy,
+granularity of control and may identify some rules to go with the
+policy.
+
+
+b) Identify the components and perform any applicable operations in the
+policy components. The assignment operations may be performed
+generally (such as with a statement โAll filesโ) or specifically (โThe
+files โAโ, โBโ, etc.) depending upon the level of detail known.
+
+
+c) Identify any applicable function components from the Access control
+functions (FDP_ACF) and Information flow control functions
+(FDP_IFF) families to address the named policy families from
+Access control policy (FDP_ACC) and Information flow control
+policy (FDP_IFC). Perform the operations to make the components
+define the rules to be enforced by the named policies. This should
+make the components fit the requirements of the selected function
+envisioned or to be built.
+
+
+d) Identify who will have the ability to control and change security
+attributes under the function, such as only a security administrator,
+only the owner of the object, etc. Select the appropriate components
+from FMT: Security management and perform the operations.
+Refinements may be useful here to identify missing features, such as
+that some or all changes must be done via trusted path.
+
+
+e) Identify any appropriate components from the FMT: Security
+management for initial values for new objects and subjects.
+
+
+f) Identify any applicable rollback components from the Rollback
+(FDP_ROL) family.
+
+
+g) Identify any applicable residual information protection requirements
+from the Residual information protection (FDP_RIP) family.
+
+
+h) Identify any applicable import or export components, and how
+security attributes should be handled during import and export, from
+the Import from outside of the TOE (FDP_ITC) and Export from the
+TOE (FDP_ETC) families.
+
+
+i) Identify any applicable internal TOE communication components
+from the Internal TOE transfer (FDP_ITT) family.
+
+
+j) Identify any requirements for integrity protection of stored
+information from the Stored data integrity (FDP_SDI).
+
+
+k) Identify any applicable inter-TSF communication components from
+the Inter-TSF user data confidentiality transfer protection
+(FDP_UCT) or Inter-TSF user data integrity transfer protection
+(FDP_UIT) families.
+
+
+April 2017 Version 3.1 Page 215 of 323
+
+
+**Class FDP: User data protection**
+
+
+722 Figure 24 shows the decomposition of this class into its constituent
+components.
+
+
+**Figure 24 - FDP: User data protection class decomposition**
+
+## **F.1 Access control policy (FDP_ACC)**
+
+
+User notes
+
+
+723 This family is based upon the concept of arbitrary controls on the interaction
+of subjects and objects. The scope and purpose of the controls is based upon
+the attributes of the accessor (subject), the attributes of the container being
+
+
+Page 216 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+
+accessed (object), the actions (operations) and any associated access control
+rules.
+
+
+724 The components in this family are capable of identifying the access control
+SFPs (by name) to be enforced by the traditional Discretionary Access
+Control (DAC) mechanisms. It further defines the subjects, objects and
+operations that are covered by identified access control SFPs. The rules that
+define the functionality of an access control SFP will be defined by other
+families, such as Access control functions (FDP_ACF) and Export from the
+TOE (FDP_ETC). The names of the access control SFPs defined in Access
+control policy (FDP_ACC) are meant to be used throughout the remainder of
+the functional components that have an operation that calls for an assignment
+or selection of an โaccess control SFP.โ
+
+
+725 The access control SFP covers a set of triplets: subject, object, and
+operations. Therefore a subject can be covered by multiple access control
+SFPs but only with respect to a different operation or a different object. Of
+course the same applies to objects and operations.
+
+
+726 A critical aspect of an access control function that enforces an access control
+SFP is the ability for users to modify the attributes involved in access control
+decisions. The Access control policy (FDP_ACC) family does not address
+these aspects. Some of these requirements are left undefined, but can be
+added as refinements, while others are covered elsewhere in other families
+and classes such as FMT: Security management.
+
+
+727 There are no audit requirements in Access control policy (FDP_ACC) as this
+family specifies access control SFP requirements. Audit requirements will be
+found in families specifying functions to satisfy the access control SFPs
+identified in this family.
+
+
+728 This family provides a PP/ST author the capability to specify several policies,
+for example, a fixed access control SFP to be applied to one scope of control,
+and a flexible access control SFP to be defined for a different scope of
+control. To specify more than one access control policy, the components
+from this family can be iterated multiple times in a PP/ST to different subsets
+of operations and objects. This will accommodate TOEs that contain multiple
+policies, each addressing a particular set of operations and objects. In other
+words, the PP/ST author should specify the required information in the ACC
+component for each of the access control SFPs that the TSF will enforce. For
+example, a TOE incorporating three access control SFPs, each covering only
+a subset of the objects, subjects, and operations within the TOE, will contain
+one FDP_ACC.1 Subset access control component for each of the three
+access control SFPs, necessitating a total of three FDP_ACC.1 Subset access
+control components.
+
+
+April 2017 Version 3.1 Page 217 of 323
+
+
+**Class FDP: User data protection**
+
+
+**FDP_ACC.1** **Subset access control**
+
+
+User application notes
+
+
+729 The terms object and subject refer to generic elements in the TOE. For a
+policy to be implementable, the entities must be clearly identified. For a PP,
+the objects and operations might be expressed as types such as: named
+objects, data repositories, observe accesses, etc. For a specific TOE these
+generic terms (subject, object) must be refined, e.g. files, registers, ports,
+daemons, open calls, etc.
+
+
+730 This component specifies that the policy cover some well-defined set of
+operations on some subset of the objects. It places no constraints on any
+operations outside the set - including operations on objects for which other
+operations are controlled.
+
+
+Operations
+
+
+Assignment:
+
+
+731 In **FDP_ACC.1.1**, the PP/ST author should specify a uniquely named
+access control SFP to be enforced by the TSF.
+
+
+732 In **FDP_ACC.1.1**, the PP/ST author should specify the list of subjects,
+objects, and operations among subjects and objects covered by the
+SFP.
+
+
+**FDP_ACC.2** **Complete access control**
+
+
+User application notes
+
+
+733 This component requires that all possible operations on objects, that are
+included in the SFP, are covered by an access control SFP.
+
+
+734 The PP/ST author must demonstrate that each combination of objects and
+subjects is covered by an access control SFP.
+
+
+Operations
+
+
+Assignment:
+
+
+735 In **FDP_ACC.2.1**, the PP/ST author should specify a uniquely named
+access control SFP to be enforced by the TSF.
+
+
+736 In **FDP_ACC.2.1**, the PP/ST author should specify the list of subjects
+and objects covered by the SFP. All operations among those subjects
+and objects will be covered by the SFP.
+
+
+Page 218 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+## **F.2 Access control functions (FDP_ACF)**
+
+
+User notes
+
+
+737 This family describes the rules for the specific functions that can implement
+an access control policy named in Access control policy (FDP_ACC) which
+also specifies the scope of control of the policy.
+
+
+738 This family provides a PP/ST author the capability to describe the rules for
+access control. This results in a TOE where the access to objects will not
+change. An example of such an object is โMessage of the Dayโ, which is
+readable by all, and changeable only by the authorised administrator. This
+family also provides the PP/ST author with the ability to describe rules that
+provide for exceptions to the general access control rules. Such exceptions
+would either explicitly allow or deny authorisation to access an object.
+
+
+739 There are no explicit components to specify other possible functions such as
+two-person control, sequence rules for operations, or exclusion controls.
+However, these mechanisms, as well as traditional DAC mechanisms, can be
+represented with the existing components, by careful drafting of the access
+control rules.
+
+
+740 A variety of acceptable access control functionality may be specified in this
+family such as:
+
+
+๏ญ Access control lists (ACLs)
+
+
+๏ญ Time-based access control specifications
+
+
+๏ญ Origin-based access control specifications
+
+
+๏ญ Owner-controlled access control attributes
+
+
+**FDP_ACF.1** **Security attribute based access control**
+
+
+User application notes
+
+
+741 This component provides requirements for a mechanism that mediates access
+control based on security attributes associated with subjects and objects.
+Each object and subject has a set of associated attributes, such as location,
+time of creation, access rights (e.g., Access Control Lists (ACLs)). This
+component allows the PP/ST author to specify the attributes that will be used
+for the access control mediation. This component allows access control rules,
+using these attributes, to be specified.
+
+
+742 Examples of the attributes that a PP/ST author might assign are presented in
+the following paragraphs.
+
+
+743 An identity attribute may be associated with users, subjects, or objects to be
+used for mediation. Examples of such attributes might be the name of the
+
+
+April 2017 Version 3.1 Page 219 of 323
+
+
+**Class FDP: User data protection**
+
+
+program image used in the creation of the subject, or a security attribute
+assigned to the program image.
+
+
+744 A time attribute can be used to specify that access will be authorised during
+certain times of the day, during certain days of the week, or during a certain
+calendar year.
+
+
+745 A location attribute could specify whether the location is the location of the
+request for the operation, the location where the operation will be carried out,
+or both. It could be based upon internal tables to translate the logical
+interfaces of the TSF into locations such as through terminal locations, CPU
+locations, etc.
+
+
+746 A grouping attribute allows a single group of users to be associated with an
+operation for the purposes of access control. If required, the refinement
+operation should be used to specify the maximum number of definable
+groups, the maximum membership of a group, and the maximum number of
+groups to which a user can concurrently be associated.
+
+
+747 This component also provides requirements for the access control security
+functions to be able to explicitly authorise or deny access to an object based
+upon security attributes. This could be used to provide privilege, access
+rights, or access authorisations within the TOE. Such privileges, rights, or
+authorisations could apply to users, subjects (representing users or
+applications), and objects.
+
+
+Operations
+
+
+Assignment:
+
+
+748 In **FDP_ACF.1.1**, the PP/ST author should specify an access control SFP
+name that the TSF is to enforce. The name of the access control SFP,
+and the scope of control for that policy are defined in components
+from Access control policy (FDP_ACC).
+
+
+749 In **FDP_ACF.1.1**, the PP/ST author should specify, for each controlled
+subject and object, the security attributes and/or named groups of
+security attributes that the function will use in the specification of the
+rules. For example, such attributes may be things such as the user
+identity, subject identity, role, time of day, location, ACLs, or any
+other attribute specified by the PP/ST author. Named groups of
+security attributes can be specified to provide a convenient means to
+refer to multiple security attributes. Named groups could provide a
+useful way to associate โrolesโ defined in Security management roles
+(FMT_SMR), and all of their relevant attributes, with subjects. In
+other words, each role could relate to a named group of attributes.
+
+
+750 In **FDP_ACF.1.2**, the PP/ST author should specify the SFP rules
+governing access among controlled subjects and controlled objects
+using controlled operations on controlled objects. These rules specify
+when access is granted or denied. It can specify general access
+
+
+Page 220 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+
+control functions (e.g. typical permission bits) or granular access
+control functions (e.g. ACLs).
+
+
+751 In **FDP_ACF.1.3**, the PP/ST author should specify the rules, based on
+security attributes, that explicitly authorise access of subjects to
+objects that will be used to explicitly authorise access. These rules are
+in addition to those specified in **FDP_ACF.1.1** . They are included in
+
+**FDP_ACF.1.3** as they are intended to contain exceptions to the rules in
+
+**FDP_ACF.1.1** . An example of rules to explicitly authorise access is
+based on a privilege vector associated with a subject that always
+grants access to objects covered by the access control SFP that has
+been specified. If such a capability is not desired, then the PP/ST
+author should specify โnoneโ.
+
+
+752 In **FDP_ACF.1.4**, the PP/ST author should specify the rules, based on
+security attributes, that explicitly deny access of subjects to objects.
+These rules are in addition to those specified in **FDP_ACF.1.1** . They are
+included in **FDP_ACF.1.4** as they are intended to contain exceptions to
+the rules in **FDP_ACF.1.1** . An example of rules to explicitly deny
+access is based on a privilege vector associated with a subject that
+always denies access to objects covered by the access control SFP
+that has been specified. If such a capability is not desired, then the
+PP/ST author should specify โnoneโ.
+
+## **F.3 Data authentication (FDP_DAU)**
+
+
+User notes
+
+
+753 This family describes specific functions that can be used to authenticate
+โstaticโ data.
+
+
+754 Components in this family are to be used when there is a requirement for
+โstaticโ data authentication, i.e. where data is to be signed but not transmitted.
+(Note that the Non-repudiation of origin (FCO_NRO) family provides for
+non-repudiation of origin of information received during a data exchange.)
+
+
+**FDP_DAU.1** **Basic Data Authentication**
+
+
+User application notes
+
+
+755 This component may be satisfied by one-way hash functions (cryptographic
+checksum, fingerprint, message digest), to generate a hash value for a
+definitive document that may be used as verification of the validity or
+authenticity of its information content.
+
+
+April 2017 Version 3.1 Page 221 of 323
+
+
+**Class FDP: User data protection**
+
+
+Operations
+
+
+Assignment:
+
+
+756 In **FDP_DAU.1.1**, the PP/ST author should specify the list of objects or
+information types for which the TSF shall be capable of generating
+data authentication evidence.
+
+
+757 In **FDP_DAU.1.2**, the PP/ST author should specify the list of subjects
+that will have the ability to verify data authentication evidence for the
+objects identified in the previous element. The list of subjects could
+be very specific, if the subjects are known, or it could be more
+generic and refer to a โtypeโ of subject such as an identified role.
+
+
+**FDP_DAU.2** **Data Authentication with Identity of Guarantor**
+
+
+User application notes
+
+
+758 This component additionally requires the ability to verify the identity of the
+user that provided the guarantee of authenticity (e.g. a trusted third party).
+
+
+Operations
+
+
+Assignment:
+
+
+759 In **FDP_DAU.2.1**, the PP/ST author should specify the list of objects or
+information types for which the TSF shall be capable of generating
+data authentication evidence.
+
+
+760 In **FDP_DAU.2.2**, the PP/ST author should specify the list of subjects
+that will have the ability to verify data authentication evidence for the
+objects identified in the previous element as well as the identity of the
+user that created the data authentication evidence.
+
+## **F.4 Export from the TOE (FDP_ETC)**
+
+
+User notes
+
+
+761 This family defines functions for TSF-mediated exporting of user data from
+the TOE such that its security attributes either can be explicitly preserved or
+can be ignored once it has been exported. Consistency of these security
+attributes are addressed by Inter-TSF TSF data consistency (FPT_TDC).
+
+
+762 Export from the TOE (FDP_ETC) is concerned with limitations on export
+and association of security attributes with the exported user data.
+
+
+763 This family, and the corresponding Import family Import from outside of the
+TOE (FDP_ITC), address how the TOE deals with user data transferred into
+and outside its control. In principle this family is concerned with the TSFmediated exporting of user data and its related security attributes.
+
+
+764 A variety of activities might be involved here:
+
+
+Page 222 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+
+a) exporting of user data without any security attributes;
+
+
+b) exporting user data including security attributes where the two are
+associated with one another and the security attributes
+unambiguously represent the exported user data.
+
+
+765 If there are multiple SFPs (access control and/or information flow control)
+then it may be appropriate to iterate these components once for each named
+SFP.
+
+
+**FDP_ETC.1** **Export of user data without security attributes**
+
+
+User application notes
+
+
+766 This component is used to specify the TSF-mediated exporting of user data
+without the export of its security attributes.
+
+
+Operations
+
+
+Assignment:
+
+
+767 In **FDP_ETC.1.1**, the PP/ST author should specify the access control
+SFP(s) and/or information flow control SFP(s) that will be enforced
+when exporting user data. The user data that this function exports is
+scoped by the assignment of these SFPs.
+
+
+**FDP_ETC.2** **Export of user data with security attributes**
+
+
+User application notes
+
+
+768 The user data is exported together with its security attributes. The security
+attributes are unambiguously associated with the user data. There are several
+ways of achieving this association. One way that this can be achieved is by
+physically collocating the user data and the security attributes (e.g. the same
+floppy), or by using cryptographic techniques such as secure signatures to
+associate the attributes and the user data. Inter-TSF trusted channel
+(FTP_ITC) could be used to assure that the attributes are correctly received
+at the other trusted IT product while Inter-TSF TSF data consistency
+(FPT_TDC) can be used to make sure that those attributes are properly
+interpreted. Furthermore, Trusted path (FTP_TRP) could be used to make
+sure that the export is being initiated by the proper user.
+
+
+Operations
+
+
+Assignment:
+
+
+769 In **FDP_ETC.2.1**, the PP/ST author should specify the access control
+SFP(s) and/or information flow control SFP(s) that will be enforced
+when exporting user data. The user data that this function exports is
+scoped by the assignment of these SFPs.
+
+
+April 2017 Version 3.1 Page 223 of 323
+
+
+**Class FDP: User data protection**
+
+
+770 In **FDP_ETC.2.4**, the PP/ST author should specify any additional
+exportation control rules or โnoneโ if there are no additional
+exportation control rules. These rules will be enforced by the TSF in
+addition to the access control SFPs and/or information flow control
+SFPs selected in **FDP_ETC.2.1** .
+
+## **F.5 Information flow control policy (FDP_IFC)**
+
+
+User notes
+
+
+771 This family covers the identification of information flow control SFPs; and,
+for each, specifies the scope of control of the SFP.
+
+
+772 The components in this family are capable of identifying the information
+flow control SFPs to be enforced by the traditional Mandatory Access
+Control mechanisms that would be found in a TOE. However, they go
+beyond just the traditional MAC mechanisms and can be used to identify and
+describe non-interference policies and state-transitions. It further defines the
+subjects under control of the policy, the information under control of the
+policy, and operations which cause controlled information to flow to and
+from controlled subjects for each information flow control SFP in the TOE.
+The information flow control SFP will be defined by other families such as
+Information flow control functions (FDP_IFF) and Export from the TOE
+(FDP_ETC). The information flow control SFPs named here in Information
+flow control policy (FDP_IFC) are meant to be used throughout the
+remainder of the functional components that have an operation that calls for
+an assignment or selection of an โinformation flow control SFP.โ
+
+
+773 These components are quite flexible. They allow the domain of flow control
+to be specified and there is no requirement that the mechanism be based upon
+labels. The different elements of the information flow control components
+also permit different degrees of exception to the policy.
+
+
+774 Each SFP covers a set of triplets: subject, information, and operations that
+cause information to flow to and from subjects. Some information flow
+control policies may be at a very low level of detail and explicitly describe
+subjects in terms of processes within an operating system. Other information
+flow control policies may be at a high level and describe subjects in the
+generic sense of users or input/output channels. If the information flow
+control policy is at too high a level of detail, it may not clearly define the
+desired IT security functions. In such cases, it is more appropriate to include
+such descriptions of information flow control policies as objectives. Then the
+desired IT security functions can be specified as supportive of those
+objectives.
+
+
+775 In the second component (FDP_IFC.2 Complete information flow control),
+each information flow control SFP will cover all possible operations that
+cause information covered by that SFP to flow to and from subjects covered
+by that SFP. Furthermore, all information flows will need to be covered by a
+SFP. Therefore for each action that causes information to flow, there will be
+a set of rules that define whether the action is allowed. If there are multiple
+
+
+Page 224 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+
+SFPs that are applicable for a given information flow, all involved SFPs
+must allow this flow before it is permitted to take place.
+
+
+776 An information flow control SFP covers a well-defined set of operations.
+The SFPs coverage may be โcompleteโ with respect to some information
+flows, or it may address only some of the operations that affect the
+information flow.
+
+
+777 An access control SFP controls access to the objects that contain information.
+An information flow control SFP controls access to the information,
+independent of its container. The attributes of the information, which may be
+associated with the attributes of the container (or may not, as in the case of a
+multi-level database) stay with the information as it flows. The accessor does
+not have the ability, in the absence of an explicit authorisation, to change the
+attributes of the information.
+
+
+778 Information flows and operations can be expressed at multiple levels. In the
+case of a ST, the information flows and operations might be specified at a
+system-specific level: TCP/IP packets flowing through a firewall based upon
+known IP addresses. For a PP, the information flows and operations might be
+expressed as types: email, data repositories, observe accesses, etc.
+
+
+779 The components in this family can be applied multiple times in a PP/ST to
+different subsets of operations and objects. This will accommodate TOEs
+that contain multiple policies, each addressing a particular set of objects,
+subjects, and operations.
+
+
+**FDP_IFC.1** **Subset information flow control**
+
+
+User application notes
+
+
+780 This component requires that an information flow control policy apply to a
+subset of the possible operations in the TOE.
+
+
+Operations
+
+
+Assignment:
+
+
+781 In **FDP_IFC.1.1**, the PP/ST author should specify a uniquely named
+information flow control SFP to be enforced by the TSF.
+
+
+782 In **FDP_IFC.1.1**, the PP/ST author should specify the list of subjects,
+information, and operations which cause controlled information to
+flow to and from controlled subjects covered by the SFP. As
+mentioned above, the list of subjects could be at various levels of
+detail depending on the needs of the PP/ST author. It could specify
+users, machines, or processes for example. Information could refer to
+data such as email or network protocols, or more specific objects
+similar to those specified under an access control policy. If the
+information that is specified is contained within an object that is
+subject to an access control policy, then both the access control
+
+
+April 2017 Version 3.1 Page 225 of 323
+
+
+**Class FDP: User data protection**
+
+
+policy and information flow control policy must be enforced before
+the specified information could flow to or from the object.
+
+
+**FDP_IFC.2** **Complete information flow control**
+
+
+User application notes
+
+
+783 This component requires that all possible operations that cause information
+to flow to and from subjects included in the SFP, are covered by an
+information flow control SFP.
+
+
+784 The PP/ST author must demonstrate that each combination of information
+flows and subjects is covered by an information flow control SFP.
+
+
+Operations
+
+
+Assignment:
+
+
+785 In **FDP_IFC.2.1**, the PP/ST author should specify a uniquely named
+information flow control SFP to be enforced by the TSF.
+
+
+786 In **FDP_IFC.2.1**, the PP/ST author should specify the list of subjects and
+information that will be covered by the SFP. All operations that cause
+that information to flow to and from subjects will be covered by the
+SFP. As mentioned above, the list of subjects could be at various
+levels of detail depending on the needs of the PP/ST author. It could
+specify users, machines, or processes for example. Information could
+refer to data such as email or network protocols, or more specific
+objects similar to those specified under an access control policy. If
+the information that is specified is contained within an object that is
+subject to an access control policy, then both the access control
+policy and information flow control policy must be enforced before
+the specified information could flow to or from the object.
+
+## **F.6 Information flow control functions (FDP_IFF)**
+
+
+User notes
+
+
+787 This family describes the rules for the specific functions that can implement
+the information flow control SFPs named in Information flow control policy
+(FDP_IFC), which also specifies the scope of control of the policies. It
+consists of two โtrees:โ one addressing the common information flow control
+function issues, and a second addressing illicit information flows (i.e. covert
+channels) with respect to one or more information flow control SFPs. This
+division arises because the issues concerning illicit information flows are, in
+some sense, orthogonal to the rest of an SFP. Illicit information flows are
+flows in violation of policy; thus they are not a policy issue.
+
+
+788 In order to implement strong protection against disclosure or modification in
+the face of untrusted software, controls on information flow are required.
+Access controls alone are not sufficient because they only control access to
+
+
+Page 226 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+
+containers, allowing the information they contain to flow, without controls,
+throughout a system.
+
+
+789 In this family, the phrase โtypes of illicit information flowsโ is used. This
+phrase may be used to refer to the categorisation of flows as โStorage
+Channelsโ or โTiming Channelsโ, or it can refer to improved categorisations
+reflective of the needs of a PP/ST author.
+
+
+790 The flexibility of these components allows the definition of a privilege policy
+within FDP_IFF.1 Simple security attributes and FDP_IFF.2 Hierarchical
+security attributes to allow the controlled bypass of all or part of a particular
+SFP. If there is a need for a predefined approach to SFP bypass, the PP/ST
+author should consider incorporating a privilege policy.
+
+
+**FDP_IFF.1** **Simple security attributes**
+
+
+User application notes
+
+
+791 This component requires security attributes on information, and on subjects
+that cause that information to flow and subjects that act as recipients of that
+information. The attributes of the containers of the information should also
+be considered if it is desired that they should play a part in information flow
+control decisions or if they are covered by an access control policy. This
+component specifies the key rules that are enforced, and describes how
+security attributes are derived.
+
+
+792 This component does not specify the details of how a security attribute is
+assigned (i.e. user versus process). Flexibility in policy is provided by having
+assignments that allow specification of additional policy and function
+requirements, as necessary.
+
+
+793 This component also provides requirements for the information flow control
+functions to be able to explicitly authorise and deny an information flow
+based upon security attributes. This could be used to implement a privilege
+policy that covers exceptions to the basic policy defined in this component.
+
+
+Operations
+
+
+Assignment:
+
+
+794 In **FDP_IFF.1.1**, the PP/ST author should specify the information flow
+control SFPs enforced by the TSF. The name of the information flow
+control SFP, and the scope of control for that policy are defined in
+components from Information flow control policy (FDP_IFC).
+
+
+795 In **FDP_IFF.1.1**, the PP/ST author should specify, for each type of
+controlled subject and information, the security attributes that are
+relevant to the specification of the SFP rules. For example, such
+security attributes may be things such the subject identifier, subject
+sensitivity label, subject clearance label, information sensitivity label,
+
+
+April 2017 Version 3.1 Page 227 of 323
+
+
+**Class FDP: User data protection**
+
+
+etc. The types of security attributes should be sufficient to support the
+environmental needs.
+
+
+796 In **FDP_IFF.1.2**, the PP/ST author should specify for each operation, the
+security attribute-based relationship that must hold between subject
+and information security attributes that the TSF will enforce.
+
+
+797 In **FDP_IFF.1.3**, the PP/ST author should specify any additional
+information flow control SFP rules that the TSF is to enforce. This
+includes all rules of the SFP that are either not based on the security
+attributes of the information and the subject or rules that
+automatically modify the security attributes of information or
+subjects as a result of an access operation. An example for the first
+case is a rule of the SFP controlling a threshold value for specific
+types of information. This would for example be the case when the
+information flow SFP contains rules on access to statistical data
+where a subject is only allowed to access this type of information up
+to a specific number of accesses. An example for the second case
+would be a rule stating under which conditions and how the security
+attributes of a subject or object change as the result of an access
+operation. Some information flow policies for example may limit the
+number of access operations to information with specific security
+attributes. If there are no additional rules then the PP/ST author
+should specify โnoneโ.
+
+
+798 In **FDP_IFF.1.4**, the PP/ST author should specify the rules, based on
+security attributes, that explicitly authorise information flows. These
+rules are in addition to those specified in the preceding elements.
+They are included in **FDP_IFF.1.4** as they are intended to contain
+exceptions to the rules in the preceding elements. An example of
+rules to explicitly authorise information flows is based on a privilege
+vector associated with a subject that always grants the subject the
+ability to cause an information flow for information that is covered by
+the SFP that has been specified. If such a capability is not desired,
+then the PP/ST author should specify โnoneโ.
+
+
+799 In **FDP_IFF.1.5**, the PP/ST author should specify the rules, based on
+security attributes, that explicitly deny information flows. These rules
+are in addition to those specified in the preceding elements. They are
+included in **FDP_IFF.1.5** as they are intended to contain exceptions to
+the rules in the preceding elements. An example of rules to explicitly
+deny information flows is based on a privilege vector associated with
+a subject that always denies the subject the ability to cause an
+information flow for information that is covered by the SFP that has
+been specified. If such a capability is not desired, then the PP/ST
+author should specify โnoneโ.
+
+
+Page 228 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+
+**FDP_IFF.2** **Hierarchical security attributes**
+
+
+User application notes
+
+
+800 This component requires that the named information flow control SFP uses
+hierarchical security attributes that form a lattice.
+
+
+801 It is important to note that the hierarchical relationship requirements
+identified in **FDP_IFF.2.4** need only apply to the information flow control
+security attributes for the information flow control SFPs that have been
+identified in **FDP_IFF.2.1** . This component is not meant to apply to other SFPs
+such as access control SFPs.
+
+
+802 **FDP_IFF.2.6** phrases the requirements for the set of security attributes to form a
+lattice. A number of information flow policies defined in the literature and
+implemented in IT products are based on a set of security attributes that form
+a lattice. **FDP_IFF.2.6** is specifically included to address this type of
+information flow policies.
+
+
+803 If it is the case that multiple information flow control SFPs are to be
+specified, and that each of these SFPs will have their own security attributes
+that are not related to one another, then the PP/ST author should iterate this
+component once for each of those SFPs. Otherwise a conflict might arise
+with the sub-items of **FDP_IFF.2.4** since the required relationships will not
+exist.
+
+
+Operations
+
+
+Assignment:
+
+
+804 In **FDP_IFF.2.1**, the PP/ST author should specify the information flow
+control SFPs enforced by the TSF. The name of the information flow
+control SFP, and the scope of control for that policy are defined in
+components from Information flow control policy (FDP_IFC).
+
+
+805 In **FDP_IFF.2.1**, the PP/ST author should specify, for each type of
+controlled subject and information, the security attributes that are
+relevant to the specification of the SFP rules. For example, such
+security attributes may be things such the subject identifier, subject
+sensitivity label, subject clearance label, information sensitivity label,
+etc. The types of security attributes should be sufficient to support the
+environmental needs.
+
+
+806 In **FDP_IFF.2.2**, the PP/ST author should specify for each operation, the
+security attribute-based relationship that must hold between subject
+and information security attributes that the TSF will enforce. These
+relationships should be based upon the ordering relationships
+between the security attributes.
+
+
+807 In **FDP_IFF.2.3**, the PP/ST author should specify any additional
+information flow control SFP rules that the TSF is to enforce. This
+
+
+April 2017 Version 3.1 Page 229 of 323
+
+
+**Class FDP: User data protection**
+
+
+includes all rules of the SFP that are either not based on the security
+attributes of the information and the subject or rules that
+automatically modify the security attributes of information or
+subjects as a result of an access operation. An example for the first
+case is a rule of the SFP controlling a threshold value for specific
+types of information. This would for example be the case when the
+information flow SFP contains rules on access to statistical data
+where a subject is only allowed to access this type of information up
+to a specific number of accesses. An example for the second case
+would be a rule stating under which conditions and how the security
+attributes of a subject or object change as the result of an access
+operation. Some information flow policies for example may limit the
+number of access operations to information with specific security
+attributes. If there are no additional rules then the PP/ST author
+should specify โnoneโ.
+
+
+808 In **FDP_IFF.2.4**, the PP/ST author should specify the rules, based on
+security attributes, that explicitly authorise information flows. These
+rules are in addition to those specified in the preceding elements.
+They are included in **FDP_IFF.2.4** as they are intended to contain
+exceptions to the rules in the preceding elements. An example of
+rules to explicitly authorise information flows is based on a privilege
+vector associated with a subject that always grants the subject the
+ability to cause an information flow for information that is covered by
+the SFP that has been specified. If such a capability is not desired,
+then the PP/ST author should specify โnoneโ.
+
+
+809 In **FDP_IFF.2.5**, the PP/ST author should specify the rules, based on
+security attributes, that explicitly deny information flows. These rules
+are in addition to those specified in the preceding elements. They are
+included in **FDP_IFF.2.5** as they are intended to contain exceptions to
+the rules in the preceding elements. An example of rules to explicitly
+deny information flows is based on a privilege vector associated with
+a subject that always denies the subject the ability to cause an
+information flow for information that is covered by the SFP that has
+been specified. If such a capability is not desired, then the PP/ST
+author should specify โnoneโ.
+
+
+**FDP_IFF.3** **Limited illicit information flows**
+
+
+User application notes
+
+
+810 This component should be used when at least one of the SFPs that requires
+control of illicit information flows does not require elimination of flows.
+
+
+811 For the specified illicit information flows, certain maximum capacities
+should be provided. In addition a PP/ST author has the ability to specify
+whether the illicit information flows must be audited.
+
+
+Page 230 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+
+Operations
+
+
+Assignment:
+
+
+812 In **FDP_IFF.3.1**, the PP/ST author should specify the information flow
+control SFPs enforced by the TSF. The name of the information flow
+control SFP, and the scope of control for that policy are defined in
+components from Information flow control policy (FDP_IFC).
+
+
+813 In **FDP_IFF.3.1**, the PP/ST author should specify the types of illicit
+information flows that are subject to a maximum capacity limitation.
+
+
+814 In **FDP_IFF.3.1**, the PP/ST author should specify the maximum capacity
+permitted for any identified illicit information flows.
+
+
+**FDP_IFF.4** **Partial elimination of illicit information flows**
+
+
+User application notes
+
+
+815 This component should be used when all the SFPs that requires control of
+illicit information flows require elimination of some (but not necessarily all)
+illicit information flows.
+
+
+Operations
+
+
+Assignment:
+
+
+816 In **FDP_IFF.4.1**, the PP/ST author should specify the information flow
+control SFPs enforced by the TSF. The name of the information flow
+control SFP, and the scope of control for that policy are defined in
+components from Information flow control policy (FDP_IFC).
+
+
+817 In **FDP_IFF.4.1**, the PP/ST author should specify the types of illicit
+information flows which are subject to a maximum capacity
+limitation.
+
+
+818 In **FDP_IFF.4.1**, the PP/ST author should specify the maximum capacity
+permitted for any identified illicit information flows.
+
+
+819 In **FDP_IFF.4.2**, the PP/ST author should specify the types of illicit
+information flows to be eliminated. This list may not be empty as this
+component requires that some illicit information flows are to be
+eliminated.
+
+
+**FDP_IFF.5** **No illicit information flows**
+
+
+User application notes
+
+
+820 This component should be used when the SFPs that require control of illicit
+information flows require elimination of all illicit information flows.
+However, the PP/ST author should carefully consider the potential impact
+that eliminating all illicit information flows might have on the normal
+
+
+April 2017 Version 3.1 Page 231 of 323
+
+
+**Class FDP: User data protection**
+
+
+functional operation of the TOE. Many practical applications have shown
+that there is an indirect relationship between illicit information flows and
+normal functionality within a TOE and eliminating all illicit information
+flows may result in less than desired functionality.
+
+
+Operations
+
+
+Assignment:
+
+
+821 In **FDP_IFF.5.1**, the PP/ST author should specify the information flow
+control SFP for which illicit information flows are to be eliminated.
+The name of the information flow control SFP, and the scope of
+control for that policy are defined in components from Information
+flow control policy (FDP_IFC).
+
+
+**FDP_IFF.6** **Illicit information flow monitoring**
+
+
+User application notes
+
+
+822 This component should be used when it is desired that the TSF provide the
+ability to monitor the use of illicit information flows that exceed a specified
+capacity. If it is desired that such flows be audited, then this component
+could serve as the source of audit events to be used by components from the
+Security audit data generation (FAU_GEN) family.
+
+
+Operations
+
+
+Assignment:
+
+
+823 In **FDP_IFF.6.1**, the PP/ST author should specify the information flow
+control SFPs enforced by the TSF. The name of the information flow
+control SFP, and the scope of control for that policy are defined in
+components from Information flow control policy (FDP_IFC).
+
+
+824 In **FDP_IFF.6.1**, the PP/ST author should specify the types of illicit
+information flows that will be monitored for exceeding a maximum
+capacity.
+
+
+825 In **FDP_IFF.6.1**, the PP/ST author should specify the maximum capacity
+above which illicit information flows will be monitored by the TSF.
+
+## **F.7 Import from outside of the TOE (FDP_ITC)**
+
+
+User notes
+
+
+826 This family defines mechanisms for TSF-mediated importing of user data
+from outside the TOE into the TOE such that the user data security attributes
+can be preserved. Consistency of these security attributes are addressed by
+Inter-TSF TSF data consistency (FPT_TDC).
+
+
+Page 232 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+
+827 Import from outside of the TOE (FDP_ITC) is concerned with limitations on
+import, user specification of security attributes, and association of security
+attributes with the user data.
+
+
+828 This family, and the corresponding export family Export from the TOE
+(FDP_ETC), address how the TOE deals with user data outside its control.
+This family is concerned with assigning and abstraction of the user data
+security attributes.
+
+
+829 A variety of activities might be involved here:
+
+
+a) importing user data from an unformatted medium (e.g. floppy disk,
+tape, scanner, video or audit signal), without including any security
+attributes, and physically marking the medium to indicate its
+contents;
+
+
+b) importing user data, including security attributes, from a medium and
+verifying that the object security attributes are appropriate;
+
+
+c) importing user data, including security attributes, from a medium
+using a cryptographic sealing technique to protect the association of
+user data and security attributes.
+
+
+830 This family is not concerned with the determination of whether the user data
+may be imported. It is concerned with the values of the security attributes to
+associate with the imported user data.
+
+
+831 There are two possibilities for the import of user data: either the user data is
+unambiguously associated with reliable object security attributes (values and
+meaning of the security attributes is not modified), or no reliable security
+attributes (or no security attributes at all) are available from the import
+source. This family addresses both cases.
+
+
+832 If there are reliable security attributes available, they may have been
+associated with the user data by physical means (the security attributes are on
+the same media), or by logical means (the security attributes are distributed
+differently, but include unique object identification, e.g. cryptographic
+checksum).
+
+
+833 This family is concerned with TSF-mediated importing of user data and
+maintaining the association of security attributes as required by the SFP.
+Other families are concerned with other import aspects such as consistency,
+trusted channels, and integrity that are beyond the scope of this family.
+Furthermore, Import from outside of the TOE (FDP_ITC) is only concerned
+with the interface to the import medium. Export from the TOE (FDP_ETC)
+is responsible for the other end point of the medium (the source).
+
+
+834 Some of the well known import requirements are:
+
+
+a) importing of user data without any security attributes;
+
+
+April 2017 Version 3.1 Page 233 of 323
+
+
+**Class FDP: User data protection**
+
+
+b) importing of user data including security attributes where the two are
+associated with one another and the security attributes
+unambiguously represent the information being imported.
+
+
+835 These import requirements may be handled by the TSF with or without
+human intervention, depending on the IT limitations and the organisational
+security policy. For example, if user data is received on a โconfidentialโ
+channel, the security attributes of the objects will be set to โconfidentialโ.
+
+
+836 If there are multiple SFPs (access control and/or information flow control)
+then it may be appropriate to iterate these components once for each named
+SFP.
+
+
+**FDP_ITC.1** **Import of user data without security attributes**
+
+
+User application notes
+
+
+837 This component is used to specify the import of user data that does not have
+reliable (or any) security attributes associated with it. This function requires
+that the security attributes for the imported user data be initialised within the
+TSF. It could also be the case that the PP/ST author specifies the rules for
+import. It may be appropriate, in some environments, to require that these
+attributes be supplied via a trusted path or a trusted channel mechanism.
+
+
+Operations
+
+
+Assignment:
+
+
+838 In **FDP_ITC.1.1**, the PP/ST author should specify the access control
+SFP(s) and/or information flow control SFP(s) that will be enforced
+when importing user data from outside of the TOE. The user data that
+this function imports is scoped by the assignment of these SFPs.
+
+
+839 In **FDP_ITC.1.3**, the PP/ST author should specify any additional
+importation control rules or โnoneโ if there are no additional
+importation control rules. These rules will be enforced by the TSF in
+addition to the access control SFPs and/or information flow control
+SFPs selected in **FDP_ITC.1.1** .
+
+
+**FDP_ITC.2** **Import of user data with security attributes**
+
+
+User application notes
+
+
+840 This component is used to specify the import of user data that has reliable
+security attributes associated with it. This function relies upon the security
+attributes that are accurately and unambiguously associated with the objects
+on the import medium. Once imported, those objects will have those same
+attributes. This requires Inter-TSF TSF data consistency (FPT_TDC) to
+ensure the consistency of the data. It could also be the case that the PP/ST
+author specifies the rules for import.
+
+
+Page 234 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+
+Operations
+
+
+Assignment:
+
+
+841 In **FDP_ITC.2.1**, the PP/ST author should specify the access control
+SFP(s) and/or information flow control SFP(s) that will be enforced
+when importing user data from outside of the TOE. The user data that
+this function imports is scoped by the assignment of these SFPs.
+
+
+842 In **FDP_ITC.2.5**, the PP/ST author should specify any additional
+importation control rules or โnoneโ if there are no additional
+importation control rules. These rules will be enforced by the TSF in
+addition to the access control SFPs and/or information flow control
+SFPs selected in **FDP_ITC.2.1** .
+
+## **F.8 Internal TOE transfer (FDP_ITT)**
+
+
+User notes
+
+
+843 This family provides requirements that address protection of user data when
+it is transferred between parts of a TOE across an internal channel. This may
+be contrasted with the Inter-TSF user data confidentiality transfer protection
+(FDP_UCT) and Inter-TSF user data integrity transfer protection (FDP_UIT)
+family, which provide protection for user data when it is transferred between
+distinct TSFs across an external channel, and Export from the TOE
+(FDP_ETC) and Import from outside of the TOE (FDP_ITC), which address
+TSF-mediated transfer of data to or from outside the TOE.
+
+
+844 The requirements in this family allow a PP/ST author to specify the desired
+security for user data while in transit within the TOE. This security could be
+protection against disclosure, modification, or loss of availability.
+
+
+845 The determination of the degree of physical separation above which this
+family should apply depends on the intended environment of use. In a hostile
+environment, there may be risks arising from transfers between parts of the
+TOE separated by only a system bus. In more benign environments, the
+transfers may be across more traditional network media.
+
+
+846 If there are multiple SFPs (access control and/or information flow control)
+then it may be appropriate to iterate these components once for each named
+SFP.
+
+
+**FDP_ITT.1** **Basic internal transfer protection**
+
+
+Operations
+
+
+Assignment:
+
+
+847 In **FDP_ITT.1.1**, the PP/ST author should specify the access control
+SFP(s) and/or information flow control SFP(s) covering the
+information being transferred.
+
+
+April 2017 Version 3.1 Page 235 of 323
+
+
+**Class FDP: User data protection**
+
+
+Selection:
+
+
+848 In **FDP_ITT.1.1**, the PP/ST author should specify the types of
+transmission errors that the TSF should prevent occurring for user
+data while in transport. The options are disclosure, modification, loss
+of use.
+
+
+**FDP_ITT.2** **Transmission separation by attribute**
+
+
+User application notes
+
+
+849 This component could, for example, be used to provide different forms of
+protection to information with different clearance levels.
+
+
+850 One of the ways to achieve separation of data when it is transmitted is
+through the use of separate logical or physical channels.
+
+
+Operations
+
+
+Assignment:
+
+
+851 In **FDP_ITT.2.1**, the PP/ST author should specify the access control
+SFP(s) and/or information flow control SFP(s) covering the
+information being transferred.
+
+
+Selection:
+
+
+852 In **FDP_ITT.2.1**, the PP/ST author should specify the types of
+transmission errors that the TSF should prevent occurring for user
+data while in transport. The options are disclosure, modification, loss
+of use.
+
+
+Assignment:
+
+
+853 In **FDP_ITT.2.2**, the PP/ST author should specify the security attributes,
+the values of which the TSF will use to determine when to separate
+data that is being transmitted between physically-separated parts of
+the TOE. An example is that user data associated with the identity of
+one owner is transmitted separately from the user data associated
+with the identify of a different owner. In this case, the value of the
+identity of the owner of the data is what is used to determine when to
+separate the data for transmission.
+
+
+**FDP_ITT.3** **Integrity monitoring**
+
+
+User application notes
+
+
+854 This component is used in combination with either FDP_ITT.1 Basic internal
+transfer protection or FDP_ITT.2 Transmission separation by attribute. It
+ensures that the TSF checks received user data (and their attributes) for
+integrity. FDP_ITT.1 Basic internal transfer protection or FDP_ITT.2
+Transmission separation by attribute will provide the data in a manner such
+
+
+Page 236 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+
+that it is protected from modification (so that FDP_ITT.3 Integrity
+monitoring can detect any modifications).
+
+
+855 The PP/ST author has to specify the types of errors that must be detected.
+The PP/ST author should consider: modification of data, substitution of data,
+unrecoverable ordering change of data, replay of data, incomplete data, in
+addition to other integrity errors.
+
+
+856 The PP/ST author must specify the actions that the TSF should take on
+detection of a failure. For example: ignore the user data, request the data
+again, inform the authorised administrator, reroute traffic for other lines.
+
+
+Operations
+
+
+Assignment:
+
+
+857 In **FDP_ITT.3.1**, the PP/ST author should specify the access control
+SFP(s) and/or information flow control SFP(s) covering the
+information being transferred and monitored for integrity errors.
+
+
+858 In **FDP_ITT.3.1**, the PP/ST author should specify the type of possible
+integrity errors to be monitored during transmission of the user data.
+
+
+859 In **FDP_ITT.3.2**, the PP/ST author should specify the action to be taken
+by the TSF when an integrity error is encountered. An example might
+be that the TSF should request the resubmission of the user data. The
+SFP(s) specified in **FDP_ITT.3.1** will be enforced as the actions are
+taken by the TSF.
+
+
+**FDP_ITT.4** **Attribute-based integrity monitoring**
+
+
+User application notes
+
+
+860 This component is used in combination with FDP_ITT.2 Transmission
+separation by attribute. It ensures that the TSF checks received user data, that
+has been transmitted by separate channels (based on values of specified
+security attributes), for integrity. It allows the PP/ST author to specify
+actions to be taken upon detection of an integrity error.
+
+
+861 For example, this component could be used to provide different integrity
+error detection and action for information at different integrity levels.
+
+
+862 The PP/ST author has to specify the types of errors that must be detected.
+The PP/ST author should consider: modification of data, substitution of data,
+unrecoverable ordering change of data, replay of data, incomplete data, in
+addition to other integrity errors.
+
+
+863 The PP/ST author should specify the attributes (and associated transmission
+channels) that necessitate integrity error monitoring
+
+
+April 2017 Version 3.1 Page 237 of 323
+
+
+**Class FDP: User data protection**
+
+
+864 The PP/ST author must specify the actions that the TSF should take on
+detection of a failure. For example: ignore the user data, request the data
+again, inform the authorised administrator, reroute traffic for other lines.
+
+
+Operations
+
+
+Assignment:
+
+
+865 In **FDP_ITT.4.1**, the PP/ST author should specify the access control
+SFP(s) and/or information flow control SFP(s) covering the
+information being transferred and monitored for integrity errors.
+
+
+866 In **FDP_ITT.4.1**, the PP/ST author should specify the type of possible
+integrity errors to be monitored during transmission of the user data.
+
+
+867 In **FDP_ITT.4.1**, the PP/ST author should specify a list of security
+attributes that require separate transmission channels. This list is used
+to determine which user data to monitor for integrity errors., based on
+its security attributes and its transmission channel. This element is
+directly related to FDP_ITT.2 Transmission separation by attribute.
+
+
+868 In **FDP_ITT.4.2**, the PP/ST author should specify the action to be taken
+by the TSF when an integrity error is encountered. An example might
+be that the TSF should request the resubmission of the user data. The
+SFP(s) specified in **FDP_ITT.4.1** will be enforced as the actions are
+taken by the TSF.
+
+## **F.9 Residual information protection (FDP_RIP)**
+
+
+User notes
+
+
+869 Residual information protection ensures that TSF-controlled resources when
+de-allocated from an object and before they are reallocated to another object
+are treated by the TSF in a way that it is not possible to reconstruct all or part
+of the data contained in the resource before it was de-allocated.
+
+
+870 A TOE usually has a number of functions that potentially de-allocate
+resources from an object and potentially re-allocate those resources to
+objects. Some, but not all of those resources may have been used to store
+critical data from the previous use of the resource and for those resources
+FDP_RIP requires that they are prepared for reuse. Object reuse applies to
+explicit requests of a subject or user to release resources as well as implicit
+actions of the TSF that result in the de-allocation and subsequent reallocation of resources to different objects. Examples of explicit requests are
+the deletion or truncation of a file or the release of an area of main memory.
+Examples of implicit actions of the TSF are the de-allocation and reallocation of cache regions.
+
+
+871 The requirement for object reuse is related to the content of the resource
+belonging to an object, not all information about the resource or object that
+may be stored elsewhere in the TSF. As an example to satisfy the FDP_RIP
+
+
+Page 238 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+
+requirement for files as objects requires that all sectors that make up the file
+need to be prepared for re-use.
+
+
+872 It also applies to resources that are serially reused by different subjects
+within the system. For example, most operating systems typically rely upon
+hardware registers (resources) to support processes within the system. As
+processes are swapped from a โrunโ state to a โsleepโ state (and vice versa),
+these registers are serially reused by different subjects. While this
+โswappingโ action may not be considered an allocation or deallocation of a
+resource, Residual information protection (FDP_RIP) could apply to such
+events and resources.
+
+
+873 Residual information protection (FDP_RIP) typically controls access to
+information that is not part of any currently defined or accessible object;
+however, in certain cases this may not be true. For example, object โAโ is a
+file and object โBโ is the disk upon which that file resides. If object โAโ is
+deleted, the information from object โAโ is under the control of Residual
+information protection (FDP_RIP) even though it is still part of object โBโ.
+
+
+874 It is important to note that Residual information protection (FDP_RIP)
+applies only to on-line objects and not off-line objects such as those backedup on tapes. For example, if a file is deleted in the TOE, Residual
+information protection (FDP_RIP) can be instantiated to require that no
+residual information exists upon deallocation; however, the TSF cannot
+extend this enforcement to that same file that exists on the off-line back-up.
+Therefore that same file is still available. If this is a concern, then the PP/ST
+author should make sure that the proper environmental objectives are in
+place to support operational user guidance to address off-line objects.
+
+
+875 Residual information protection (FDP_RIP) and Rollback (FDP_ROL) can
+conflict when Residual information protection (FDP_RIP) is instantiated to
+require that residual information be cleared at the time the application
+releases the object to the TSF (i.e. upon deallocation). Therefore, the
+Residual information protection (FDP_RIP) selection of โdeallocationโ
+should not be used with Rollback (FDP_ROL) since there would be no
+information to roll back. The other selection, โunavailability upon allocationโ,
+may be used with Rollback (FDP_ROL), but there is the risk that the
+resource which held the information has been allocated to a new object
+before the roll back took place. If that were to occur, then the roll back would
+not be possible.
+
+
+876 There are no audit requirements in Residual information protection
+(FDP_RIP) because this is not a user-invokable function. Auditing of
+allocated or deallocated resources would be auditable as part of the access
+control SFP or the information flow control SFP operations.
+
+
+877 This family should apply to the objects specified in the access control SFP(s)
+or the information flow control SFP(s) as specified by the PP/ST author.
+
+
+April 2017 Version 3.1 Page 239 of 323
+
+
+**Class FDP: User data protection**
+
+
+**FDP_RIP.1** **Subset residual information protection**
+
+
+User application notes
+
+
+878 This component requires that, for a subset of the objects in the TOE, the TSF
+will ensure that there is no available residual information contained in a
+resource allocated to those objects or deallocated from those objects.
+
+
+Operations
+
+
+Selection:
+
+
+879 In **FDP_RIP.1.1**, the PP/ST author should specify the event, allocation
+of the resource to or deallocation of the resource from, that invokes
+the residual information protection function.
+
+
+Assignment:
+
+
+880 In **FDP_RIP.1.1**, the PP/ST author should specify the list of objects
+subject to residual information protection.
+
+
+**FDP_RIP.2** **Full residual information protection**
+
+
+User application notes
+
+
+881 This component requires that for all objects in the TOE, the TSF will ensure
+that there is no available residual information contained in a resource
+allocated to those objects or deallocated from those objects.
+
+
+Operations
+
+
+Selection:
+
+
+882 In **FDP_RIP.2.1**, the PP/ST author should specify the event, allocation
+of the resource to or deallocation of the resource from, that invokes
+the residual information protection function.
+
+## **F.10 Rollback (FDP_ROL)**
+
+
+User notes
+
+
+883 This family addresses the need to return to a well defined valid state, such as
+the need of a user to undo modifications to a file or to undo transactions in
+case of an incomplete series of transaction as in the case of databases.
+
+
+884 This family is intended to assist a user in returning to a well defined valid
+state after the user undoes the last set of actions, or, in distributed databases,
+the return of all of the distributed copies of the databases to the state before
+an operation failed.
+
+
+885 Residual information protection (FDP_RIP) and Rollback (FDP_ROL)
+conflict when Residual information protection (FDP_RIP) enforces that the
+
+
+Page 240 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+
+contents will be made unavailable at the time that a resource is deallocated
+from an object. Therefore, this use of Residual information protection
+(FDP_RIP) cannot be combined with Rollback (FDP_ROL) as there would
+be no information to roll back. Residual information protection (FDP_RIP)
+can be used only with Rollback (FDP_ROL) when it enforces that the
+contents will be unavailable at the time that a resource is allocated to an
+object. This is because the Rollback (FDP_ROL) mechanism will have an
+opportunity to access the previous information that may still be present in the
+TOE in order to successfully roll back the operation.
+
+
+886 The rollback requirement is bounded by certain limits. For example a text
+editor typically only allows you roll back up to a certain number of
+commands. Another example would be backups. If backup tapes are rotated,
+after a tape is reused, the information can no longer be retrieved. This also
+poses a bound on the rollback requirement.
+
+
+**FDP_ROL.1** **Basic rollback**
+
+
+User application notes
+
+
+887 This component allows a user or subject to undo a set of operations on a
+predefined set of objects. The undo is only possible within certain limits, for
+example up to a number of characters or up to a time limit.
+
+
+Operations
+
+
+Assignment:
+
+
+888 In **FDP_ROL.1.1**, the PP/ST author should specify the access control
+SFP(s) and/or information flow control SFP(s) that will be enforced
+when performing rollback operations. This is necessary to make sure
+that roll back is not used to circumvent the specified SFPs.
+
+
+889 In **FDP_ROL.1.1**, the PP/ST author should specify the list of operations
+that can be rolled back.
+
+
+890 In **FDP_ROL.1.1**, the PP/ST author should specify the information
+and/or list of objects that are subjected to the rollback policy.
+
+
+891 In **FDP_ROL.1.2**, the PP/ST author should specify the boundary limit to
+which rollback operations may be performed. The boundary may be
+specified as a predefined period of time, for example, operations may
+be undone which were performed within the past two minutes. Other
+possible boundaries may be defined as the maximum number of
+operations allowable or the size of a buffer.
+
+
+**FDP_ROL.2** **Advanced rollback**
+
+
+User application notes
+
+
+892 This component enforces that the TSF provide the capability to rollback all
+operations; however, the user can choose to rollback only a part of them.
+
+
+April 2017 Version 3.1 Page 241 of 323
+
+
+**Class FDP: User data protection**
+
+
+Operations
+
+
+Assignment:
+
+
+893 In **FDP_ROL.2.1**, the PP/ST author should specify the access control
+SFP(s) and/or information flow control SFP(s) that will be enforced
+when performing rollback operations. This is necessary to make sure
+that roll back is not used to circumvent the specified SFPs.
+
+
+894 In **FDP_ROL.2.1**, the PP/ST author should specify the list of objects that
+are subjected to the rollback policy.
+
+
+895 In **FDP_ROL.2.2**, the PP/ST author should specify the boundary limit to
+which rollback operations may be performed. The boundary may be
+specified as a predefined period of time, for example, operations may
+be undone which were performed within the past two minutes. Other
+possible boundaries may be defined as the maximum number of
+operations allowable or the size of a buffer.
+
+## **F.11 Stored data integrity (FDP_SDI)**
+
+
+User notes
+
+
+896 This family provides requirements that address protection of user data while
+it is stored within containers controlled by the TSF.
+
+
+897 Hardware glitches or errors may affect data stored in memory. This family
+provides requirements to detect these unintentional errors. The integrity of
+user data while stored on storage devices controlled by the TSF are also
+addressed by this family.
+
+
+898 To prevent a subject from modifying the data, the Information flow control
+functions (FDP_IFF) or Access control functions (FDP_ACF) families are
+required (rather than this family).
+
+
+899 This family differs from Internal TOE transfer (FDP_ITT) that protects the
+user data from integrity errors while being transferred within the TOE.
+
+
+**FDP_SDI.1** **Stored data integrity monitoring**
+
+
+User application notes
+
+
+900 This component monitors data stored on media for integrity errors. The
+PP/ST author can specify different kinds of user data attributes that will be
+used as the basis for monitoring.
+
+
+Operations
+
+
+Assignment:
+
+
+901 In **FDP_SDI.1.1**, the PP/ST author should specify the integrity errors
+that the TSF will detect.
+
+
+Page 242 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+
+902 In **FDP_SDI.1.1**, the PP/ST author should specify the user data attributes
+that will be used as the basis for the monitoring.
+
+
+**FDP_SDI.2** **Stored data integrity monitoring and action**
+
+
+User application notes
+
+
+903 This component monitors data stored on media for integrity errors. The
+PP/ST author can specify which action should be taken in case an integrity
+error is detected.
+
+
+Operations
+
+
+Assignment:
+
+
+904 In **FDP_SDI.2.1**, the PP/ST author should specify the integrity errors
+that the TSF will detect.
+
+
+905 In **FDP_SDI.2.1**, the PP/ST author should specify the user data attributes
+that will be used as the basis for the monitoring.
+
+
+906 In **FDP_SDI.2.2**, the PP/ST author should specify the actions to be taken
+in case an integrity error is detected.
+
+## **F.12 Inter-TSF user data confidentiality transfer protection** **(FDP_UCT)**
+
+
+User notes
+
+
+907 This family defines the requirements for ensuring the confidentiality of user
+data when it is transferred using an external channel between the TOE and
+another trusted IT product. Confidentiality is enforced by preventing
+unauthorised disclosure of user data in transit between the two end points.
+The end points may be a TSF or a user.
+
+
+908 This family provides a requirement for the protection of user data during
+transit. In contrast, Confidentiality of exported TSF data (FPT_ITC) handles
+TSF data.
+
+
+**FDP_UCT.1** **Basic data exchange confidentiality**
+
+
+User application notes
+
+
+909 Depending on the access control or information flow policies the TSF is
+required to send or receive user data in a manner such that the confidentiality
+of the user data is protected.
+
+
+April 2017 Version 3.1 Page 243 of 323
+
+
+**Class FDP: User data protection**
+
+
+Operations
+
+
+Assignment:
+
+
+910 In **FDP_UCT.1.1**, the PP/ST author should specify the access control
+SFP(s) and/or information flow control SFP(s) that will be enforced
+when exchanging user data. The specified policies will be enforced to
+make decisions about who can exchange data and which data can be
+exchanged.
+
+
+Selection:
+
+
+911 In **FDP_UCT.1.1**, the PP/ST author should specify whether this element
+applies to a mechanism that transmits or receives user data.
+
+## **F.13 Inter-TSF user data integrity transfer protection** **(FDP_UIT)**
+
+
+User notes
+
+
+912 This family defines the requirements for providing integrity for user data in
+transit between the TSF and another trusted IT product and recovering from
+detectable errors. At a minimum, this family monitors the integrity of user
+data for modifications. Furthermore, this family supports different ways of
+correcting detected integrity errors.
+
+
+913 This family defines the requirements for providing integrity for user data in
+transit; while Integrity of exported TSF data (FPT_ITI) handles TSF data.
+
+
+914 Inter-TSF user data integrity transfer protection (FDP_UIT) and Inter-TSF
+user data confidentiality transfer protection (FDP_UCT) are duals of each
+other, as Inter-TSF user data confidentiality transfer protection (FDP_UCT)
+addresses user data confidentiality. Therefore, the same mechanism that
+implements Inter-TSF user data integrity transfer protection (FDP_UIT)
+could possibly be used to implement other families such as Inter-TSF user
+data confidentiality transfer protection (FDP_UCT) and Import from outside
+of the TOE (FDP_ITC).
+
+
+**FDP_UIT.1** **Data exchange integrity**
+
+
+User application notes
+
+
+915 Depending on the access control or information flow policies the TSF is
+required to send or receive user data in a manner such that modification of
+the user data is detected. There is no requirement for a TSF mechanism to
+attempt to recover from the modification.
+
+
+Page 244 of 323 Version 3.1 April 2017
+
+
+**Class FDP: User data protection**
+
+
+Operations
+
+
+Assignment:
+
+
+916 In **FDP_UIT.1.1**, the PP/ST author should specify the access control
+SFP(s) and/or information flow control SFP(s) that will be enforced
+on the transmitted data or on the received data. The specified policies
+will be enforced to make decisions about who can transmit or who
+can receive data, and which data can be transmitted or received.
+
+
+Selection:
+
+
+917 In **FDP_UIT.1.1**, the PP/ST author should specify whether this element
+applies to a TSF that is transmitting or receiving objects.
+
+
+918 In **FDP_UIT.1.1**, the PP/ST author should specify whether the data
+should be protected from modification, deletion, insertion or replay.
+
+
+919 In **FDP_UIT.1.2**, the PP/ST author should specify whether the errors of
+the type: modification, deletion, insertion or replay are detected.
+
+
+**FDP_UIT.2** **Source data exchange recovery**
+
+
+User application notes
+
+
+920 This component provides the ability to recover from a set of identified
+transmission errors, if required, with the help of the other trusted IT product.
+As the other trusted IT product is outside the TOE, the TSF cannot control its
+behaviour. However, it can provide functions that have the ability to
+cooperate with the other trusted IT product for the purposes of recovery. For
+example, the TSF could include functions that depend upon the source
+trusted IT product to re-send the data in the event that an error is detected.
+This component deals with the ability of the TSF to handle such an error
+recovery.
+
+
+Operations
+
+
+Assignment:
+
+
+921 In **FDP_UIT.2.1**, the PP/ST author should specify the access control
+SFP(s) and/or information flow control SFP(s) that will be enforced
+when recovering user data. The specified policies will be enforced to
+make decisions about which data can be recovered and how it can be
+recovered.
+
+
+922 In **FDP_UIT.2.1**, the PP/ST author should specify the list of integrity
+errors from which the TSF, with the help of the source trusted IT
+product, is be able to recover the original user data.
+
+
+April 2017 Version 3.1 Page 245 of 323
+
+
+**Class FDP: User data protection**
+
+
+**FDP_UIT.3** **Destination data exchange recovery**
+
+
+User application notes
+
+
+923 This component provides the ability to recover from a set of identified
+transmission errors. It accomplishes this task without help from the source
+trusted IT product. For example, if certain errors are detected, the
+transmission protocol must be robust enough to allow the TSF to recover
+from the error based on checksums and other information available within
+that protocol.
+
+
+Operations
+
+
+Assignment:
+
+
+924 In **FDP_UIT.3.1**, the PP/ST author should specify the access control
+SFP(s) and/or information flow control SFP(s) that will be enforced
+when recovering user data. The specified policies will be enforced to
+make decisions about which data can be recovered and how it can be
+recovered.
+
+
+925 In **FDP_UIT.3.1**, the PP/ST author should specify the list of integrity
+errors from which the receiving TSF, alone, is able to recover the
+original user data.
+
+
+Page 246 of 323 Version 3.1 April 2017
+
+
+**Class FIA: Identification and authentication**
+
+# **G Class FIA: Identification and authentication** **(normative)**
+
+
+926 A common security requirement is to unambiguously identify the person
+and/or entity performing functions in a TOE. This involves not only
+establishing the claimed identity of each user, but also verifying that each
+user is indeed who he/she claims to be. This is achieved by requiring users to
+provide the TSF with some information that is known by the TSF to be
+associated with the user in question.
+
+
+927 Families in this class address the requirements for functions to establish and
+verify a claimed user identity. Identification and Authentication is required to
+ensure that users are associated with the proper security attributes (e.g.
+identity, groups, roles, security or integrity levels).
+
+
+928 The unambiguous identification of authorised users and the correct
+association of security attributes with users and subjects is critical to the
+enforcement of the security policies.
+
+
+929 The User identification (FIA_UID) family addresses determining the identity
+of a user.
+
+
+930 The User authentication (FIA_UAU) family addresses verifying the identity
+of a user.
+
+
+931 The Authentication failures (FIA_AFL) family addresses defining limits on
+repeated unsuccessful authentication attempts.
+
+
+932 The User attribute definition (FIA_ATD) family address the definition of
+user attributes that are used in the enforcement of the SFRs.
+
+
+933 The User-subject binding (FIA_USB) family addresses the correct
+association of security attributes for each authorised user.
+
+
+934 The Specification of secrets (FIA_SOS) family addresses the generation and
+verification of secrets that satisfy a defined metric.
+
+
+935 Figure 25 shows the decomposition of this class into its constituent
+components.
+
+
+April 2017 Version 3.1 Page 247 of 323
+
+
+**Class FIA: Identification and authentication**
+
+
+**Figure 25 - FIA: Identification and authentication class decomposition**
+
+## **G.1 Authentication failures (FIA_AFL)**
+
+
+User notes
+
+
+936 This family addresses requirements for defining values for authentication
+attempts and TSF actions in cases of authentication attempt failure.
+Parameters include, but are not limited to, the number of attempts and time
+thresholds.
+
+
+937 The session establishment process is the interaction with the user to perform
+the session establishment independent of the actual implementation. If the
+number of unsuccessful authentication attempts exceeds the indicated
+
+
+Page 248 of 323 Version 3.1 April 2017
+
+
+**Class FIA: Identification and authentication**
+
+
+threshold, either the user account or the terminal (or both) will be locked. If
+the user account is disabled, the user cannot log-on to the system. If the
+terminal is disabled, the terminal (or the address that the terminal has) cannot
+be used for any log-on. Both of these situations continue until the condition
+for re-establishment is satisfied.
+
+
+**FIA_AFL.1** **Authentication failure handling**
+
+
+User application notes
+
+
+938 The PP/ST author may define the number of unsuccessful authentication
+attempts or may choose to let the TOE developer or the authorised user to
+define this number. The unsuccessful authentication attempts need not be
+consecutive, but rather related to an authentication event. Such an
+authentication event could be the count from the last successful session
+establishment at a given terminal.
+
+
+939 The PP/ST author could specify a list of actions that the TSF shall take in the
+case of authentication failure. An authorised administrator could also be
+allowed to manage the events, if deemed opportune by the PP/ST author.
+These actions could be, among other things, terminal deactivation, user
+account deactivation, or administrator alarm. The conditions under which the
+situation will be restored to normal must be specified on the action.
+
+
+940 In order to prevent denial of service, TOEs usually ensure that there is at
+least one user account that cannot be disabled.
+
+
+941 Further actions for the TSF can be stated by the PP/ST author, including
+rules for re-enabling the user session establishment process, or sending an
+alarm to the administrator. Examples of these actions are: until a specified
+time has lapsed, until the authorised administrator re-enables the
+terminal/account, a time related to failed previous attempts (every time the
+attempt fails, the disabling time is doubled).
+
+
+Operations
+
+
+Selection:
+
+
+942 In **FIA_AFL.1.1**, the PP/ST author should select either the assignment of
+a positive integer, or the phrase โan administrator configurable
+positive integerโ specifying the range of acceptable values.
+
+
+Assignment:
+
+
+943 In **FIA_AFL.1.1**, the PP/ST author should specify the authentication
+events. Examples of these authentication events are: the unsuccessful
+authentication attempts since the last successful authentication for the
+indicated user identity, the unsuccessful authentication attempts since
+the last successful authentication for the current terminal, the number
+of unsuccessful authentication attempts in the last 10 minutes. At
+least one authentication event must be specified.
+
+
+April 2017 Version 3.1 Page 249 of 323
+
+
+**Class FIA: Identification and authentication**
+
+
+944 In **FIA_AFL.1.1**, if the assignment of a positive integer is selected, the
+PP/ST author should specify the default number (positive integer) of
+unsuccessful authentication attempts that, when met or surpassed,
+will trigger the events.
+
+
+945 In **FIA_AFL.1.1**, if an administrator configurable positive integer is
+selected, the PP/ST author should specify the range of acceptable
+values from which the administrator of the TOE may configure the
+number of unsuccessful authentication attempts. The number of
+authentication attempts should be less than or equal to the upper
+bound and greater or equal to the lower bound values.
+
+
+Selection:
+
+
+946 In **FIA_AFL.1.2**, the PP/ST author should select whether the event of
+meeting or surpassing the defined number of unsuccessful
+authentication attemps shall trigger an action by the TSF.
+
+
+Assignment:
+
+
+947 In **FIA_AFL.1.2**, the PP/ST author should specify the actions to be taken
+in case the threshold is met or surpassed, as selected. These actions
+could be disabling of an account for 5 minutes, disabling the terminal
+for an increasing amount of time (2 to the power of the number of
+unsuccessful attempts in seconds), or disabling of the account until
+unlocked by the administrator and simultaneously informing the
+administrator. The actions should specify the measures and if
+applicable the duration of the measure (or the conditions under which
+the measure will be ended).
+
+## **G.2 User attribute definition (FIA_ATD)**
+
+
+User notes
+
+
+948 All authorised users may have a set of security attributes, other than the
+user's identity, that are used to enforce the SFRs. This family defines the
+requirements for associating user security attributes with users as needed to
+support the TSF in making security decisions.
+
+
+949 There are dependencies on the individual security policy (SFP) definitions.
+These individual definitions should contain the listing of attributes that are
+necessary for policy enforcement.
+
+
+**FIA_ATD.1** **User attribute definition**
+
+
+User application notes
+
+
+950 This component specifies the security attributes that should be maintained at
+the level of the user. This means that the security attributes listed are
+assigned to and can be changed at the level of the user. In other words,
+
+
+Page 250 of 323 Version 3.1 April 2017
+
+
+**Class FIA: Identification and authentication**
+
+
+changing a security attribute in this list associated with a user should have no
+impact on the security attributes of any other user.
+
+
+951 In case security attributes belong to a group of users (such as Capability List
+for a group), the user will need to have a reference (as security attribute) to
+the relevant group.
+
+
+Operations
+
+
+Assignment:
+
+
+952 In **FIA_ATD.1.1**, the PP/ST author should specify the security attributes
+that are associated to an individual user. An example of such a list is
+{โclearanceโ, โgroup identifierโ, โrightsโ}.
+
+## **G.3 Specification of secrets (FIA_SOS)**
+
+
+User notes
+
+
+953 This family defines requirements for mechanisms that enforce defined
+quality metrics on provided secrets, and generate secrets to satisfy the
+defined metric. Examples of such mechanisms may include automated
+checking of user supplied passwords, or automated password generation.
+
+
+954 A secret can be generated outside the TOE (e.g. selected by the user and
+introduced in the TOE). In such cases, the FIA_SOS.1 Verification of secrets
+component can be used to ensure that the external generated secret adheres to
+certain standards, for example a minimum size, not present in a dictionary,
+and/or not previously used.
+
+
+955 Secrets can also be generated by the TOE. In those cases, the FIA_SOS.2
+TSF Generation of secrets component can be used to require the TOE to
+ensure that the secrets that will adhere to some specified metrics.
+
+
+956 Secrets contain the authentication data provided by the user for an
+authentication mechanism that is based on knowledge the user possesses.
+When cryptographic keys are employed, the class FCS: Cryptographic
+support should be used instead of this family.
+
+
+**FIA_SOS.1** **Verification of secrets**
+
+
+User application notes
+
+
+957 Secrets can be generated by the user. This component ensures that those user
+generated secrets can be verified to meet a certain quality metric.
+
+
+Operations
+
+
+Assignment:
+
+
+958 In **FIA_SOS.1.1**, the PP/ST author should provide a defined quality
+metric. The quality metric specification can be as simple as a
+
+
+April 2017 Version 3.1 Page 251 of 323
+
+
+**Class FIA: Identification and authentication**
+
+
+description of the quality checks to be performed, or as formal as a
+reference to a government published standard that defines the quality
+metrics that secrets must meet. Examples of quality metrics could
+include a description of the alphanumeric structure of acceptable
+secrets and/or the space size that acceptable secrets must meet.
+
+
+**FIA_SOS.2** **TSF Generation of secrets**
+
+
+User application notes
+
+
+959 This component allows the TSF to generate secrets for specific functions
+such as authentication by means of passwords.
+
+
+960 When a pseudo-random number generator is used in a secret generation
+algorithm, it should accept as input random data that would provide output
+that has a high degree of unpredictability. This random data (seed) can be
+derived from a number of available parameters such as a system clock,
+system registers, date, time, etc. The parameters should be selected to ensure
+that the number of unique seeds that can be generated from these inputs
+should be at least equal to the minimum number of secrets that must be
+generated.
+
+
+Operations
+
+
+Assignment:
+
+
+961 In **FIA_SOS.2.1**, the PP/ST author should provide a defined quality
+metric. The quality metric specification can be as simple as a
+description of the quality checks to be performed or as formal as a
+reference to a government published standard that defines the quality
+metrics that secrets must meet. Examples of quality metrics could
+include a description of the alphanumeric structure of acceptable
+secrets and/or the space size that acceptable secrets must meet.
+
+
+962 In **FIA_SOS.2.2**, the PP/ST author should provide a list of TSF
+functions for which the TSF generated secrets must be used. An
+example of such a function could include a password based
+authentication mechanism.
+
+## **G.4 User authentication (FIA_UAU)**
+
+
+User notes
+
+
+963 This family defines the types of user authentication mechanisms supported
+by the TSF. This family defines the required attributes on which the user
+authentication mechanisms must be based.
+
+
+Page 252 of 323 Version 3.1 April 2017
+
+
+**Class FIA: Identification and authentication**
+
+
+**FIA_UAU.1** **Timing of authentication**
+
+
+User application notes
+
+
+964 This component requires that the PP/ST author define the TSF-mediated
+actions that can be performed by the TSF on behalf of the user before the
+claimed identity of the user is authenticated. The TSF-mediated actions
+should have no security concerns with users incorrectly identifying
+themselves prior to being authenticated. For all other TSF-mediated actions
+not in the list, the user must be authenticated before the action can be
+performed by the TSF on behalf of the user.
+
+
+965 This component cannot control whether the actions can also be performed
+before the identification took place. This requires the use of either
+FIA_UID.1 Timing of identification or FIA_UID.2 User identification before
+any action with the appropriate assignments.
+
+
+Operations
+
+
+Assignment:
+
+
+966 In **FIA_UAU.1.1**, the PP/ST author should specify a list of TSFmediated actions that can be performed by the TSF on behalf of a
+user before the claimed identity of the user is authenticated. This list
+cannot be empty. If no actions are appropriate, component
+FIA_UAU.2 User authentication before any action should be used
+instead. An example of such an action might include the request for
+help on the login procedure.
+
+
+**FIA_UAU.2** **User authentication before any action**
+
+
+User application notes
+
+
+967 This component requires that a user is authenticated before any other TSFmediated action can take place on behalf of that user.
+
+
+**FIA_UAU.3** **Unforgeable authentication**
+
+
+User application notes
+
+
+968 This component addresses requirements for mechanisms that provide
+protection of authentication data. Authentication data that is copied from
+another user, or is in some way constructed should be detected and/or
+rejected. These mechanisms provide confidence that users authenticated by
+the TSF are actually who they claim to be.
+
+
+969 This component may be useful only with authentication mechanisms that are
+based on authentication data that cannot be shared (e.g. biometrics). It is
+impossible for a TSF to detect or prevent the sharing of passwords outside
+the control of the TSF.
+
+
+April 2017 Version 3.1 Page 253 of 323
+
+
+**Class FIA: Identification and authentication**
+
+
+Operations
+
+
+Selection:
+
+
+970 In **FIA_UAU.3.1**, the PP/ST author should specify whether the TSF will
+detect, prevent, or detect and prevent forging of authentication data.
+
+
+971 In **FIA_UAU.3.2**, the PP/ST author should specify whether the TSF will
+detect, prevent, or detect and prevent copying of authentication data.
+
+
+**FIA_UAU.4** **Single-use authentication mechanisms**
+
+
+User application notes
+
+
+972 This component addresses requirements for authentication mechanisms
+based on single-use authentication data. Single-use authentication data can
+be something the user has or knows, but not something the user is. Examples
+of single-use authentication data include single-use passwords, encrypted
+time-stamps, and/or random numbers from a secret lookup table.
+
+
+973 The PP/ST author can specify to which authentication mechanism(s) this
+requirement applies.
+
+
+Operations
+
+
+Assignment:
+
+
+974 In **FIA_UAU.4.1**, the PP/ST author should specify the list of
+authentication mechanisms to which this requirement applies. This
+assignment can be โall authentication mechanismsโ. An example of
+this assignment could be โthe authentication mechanism employed to
+authenticate people on the external networkโ.
+
+
+**FIA_UAU.5** **Multiple authentication mechanisms**
+
+
+User application notes
+
+
+975 The use of this component allows specification of requirements for more
+than one authentication mechanism to be used within a TOE. For each
+distinct mechanism, applicable requirements must be chosen from the FIA:
+Identification and authentication class to be applied to each mechanism. It is
+possible that the same component could be selected multiple times in order
+to reflect different requirements for the different use of the authentication
+mechanism.
+
+
+976 The management functions in the class FMT may provide maintenance
+capabilities for the set of authentication mechanisms, as well as the rules that
+determine whether the authentication was successful.
+
+
+977 To allow anonymous users to interact with the TOE, a โnoneโ authentication
+mechanism can be incorporated. The use of such access should be clearly
+explained in the rules of **FIA_UAU.5.2** .
+
+
+Page 254 of 323 Version 3.1 April 2017
+
+
+**Class FIA: Identification and authentication**
+
+
+Operations
+
+
+Assignment:
+
+
+978 In **FIA_UAU.5.1**, the PP/ST author should define the available
+authentication mechanisms. An example of such a list could be:
+โnone, password mechanism, biometric (retinal scan), S/key
+mechanismโ.
+
+
+979 In **FIA_UAU.5.2**, the PP/ST author should specify the rules that describe
+how the authentication mechanisms provide authentication and when
+each is to be used. This means that for each situation the set of
+mechanisms that might be used for authenticating the user must be
+described. An example of a list of such rules is: โif the user has
+special privileges a password mechanism and a biometric mechanism
+both shall be used, with success only if both succeed; for all other
+users a password mechanism shall be used.โ
+
+
+980 The PP/ST author might give the boundaries within which the authorised
+administrator may specify specific rules. An example of a rule is: โthe user
+shall always be authenticated by means of a token; the administrator might
+specify additional authentication mechanisms that also must be used.โ The
+PP/ST author also might choose not to specify any boundaries but leave the
+authentication mechanisms and their rules completely up to the authorised
+administrator.
+
+
+**FIA_UAU.6** **Re-authenticating**
+
+
+User application notes
+
+
+981 This component addresses potential needs to re-authenticate users at defined
+points in time. These may include user requests for the TSF to perform
+security relevant actions, as well as requests from non-TSF entities for reauthentication (e.g. a server application requesting that the TSF reauthenticate the client it is serving).
+
+
+Operations
+
+
+Assignment:
+
+
+982 In **FIA_UAU.6.1**, the PP/ST author should specify the list of conditions
+requiring re-authentication. This list could include a specified user
+inactivity period that has elapsed, the user requesting a change in
+active security attributes, or the user requesting the TSF to perform
+some security critical function.
+
+
+983 The PP/ST author might give the boundaries within which the
+reauthentication should occur and leave the specifics to the authorised
+administrator. An example of such a rule is: โthe user shall always be reauthenticated at least once a day; the administrator might specify that the re
+
+April 2017 Version 3.1 Page 255 of 323
+
+
+**Class FIA: Identification and authentication**
+
+
+authentication should happen more often but not more often than once every
+10 minutes.โ
+
+
+**FIA_UAU.7** **Protected authentication feedback**
+
+
+User application notes
+
+
+984 This component addresses the feedback on the authentication process that
+will be provided to the user. In some systems the feedback consists of
+indicating how many characters have been typed but not showing the
+characters themselves, in other systems even this information might not be
+appropriate.
+
+
+985 This component requires that the authentication data is not provided as-is
+back to the user. In a workstation environment, it could display a โdummyโ
+(e.g. star) for each password character provided, and not the original
+character.
+
+
+Operations
+
+
+Assignment:
+
+
+986 In **FIA_UAU.7.1**, the PP/ST author should specify the feedback related
+to the authentication process that will be provided to the user. An
+example of a feedback assignment is โthe number of characters
+typedโ, another type of feedback is โthe authentication mechanism
+that failed the authenticationโ.
+
+## **G.5 User identification (FIA_UID)**
+
+
+User notes
+
+
+987 This family defines the conditions under which users are required to identify
+themselves before performing any other actions that are to be mediated by
+the TSF and that require user identification.
+
+
+**FIA_UID.1** **Timing of identification**
+
+
+User application notes
+
+
+988 This component poses requirements for the user to be identified. The PP/ST
+author can indicate specific actions that can be performed before the
+identification takes place.
+
+
+989 If FIA_UID.1 Timing of identification is used, the TSF-mediated actions
+mentioned in FIA_UID.1 Timing of identification should also appear in this
+FIA_UAU.1 Timing of authentication.
+
+
+Page 256 of 323 Version 3.1 April 2017
+
+
+**Class FIA: Identification and authentication**
+
+
+Operations
+
+
+Assignment:
+
+
+990 In **FIA_UID.1.1**, the PP/ST author should specify a list of TSF-mediated
+actions that can be performed by the TSF on behalf of a user before
+the user has to identify itself. If no actions are appropriate,
+component FIA_UID.2 User identification before any action should
+be used instead. An example of such an action might include the
+request for help on the login procedure.
+
+
+**FIA_UID.2** **User identification before any action**
+
+
+User application notes
+
+
+991 In this component users will be identified. A user is not allowed by the TSF
+to perform any action before being identified.
+
+## **G.6 User-subject binding (FIA_USB)**
+
+
+User notes
+
+
+992 An authenticated user, in order to use the TOE, typically activates a subject.
+The user's security attributes are associated (totally or partially) with this
+subject. This family defines requirements to create and maintain the
+association of the user's security attributes to a subject acting on the user's
+behalf.
+
+
+**FIA_USB.1** **User-subject binding**
+
+
+User application notes
+
+
+993 It is intended that a subject is acting on behalf of the user who caused the
+subject to come into being or to be activated to perform a certain task.
+
+
+994 Therefore, when a subject is created, that subject is acting on behalf of the
+user who initiated the creation. In cases where anonymity is used, the subject
+is still acting on behalf of a user, but the identity of that user is unknown. A
+special category of subjects are those subjects that serve multiple users (e.g.
+a server process). In such cases the user that created this subject is assumed
+to be the โownerโ.
+
+
+Operations
+
+
+Assignment:
+
+
+995 In **FIA_USB.1.1**, the PP/ST author should specify a list of the user
+security attributes that are to be bound to subjects.
+
+
+996 In **FIA_USB.1.2**, the PP/ST author should specify any rules that are to
+apply upon initial association of attributes with subjects, or โnoneโ.
+
+
+April 2017 Version 3.1 Page 257 of 323
+
+
+**Class FIA: Identification and authentication**
+
+
+997 In **FIA_USB.1.3**, the PP/ST author should specify any rules that are to
+apply when changes are made to the user security attributes
+associated with subjects acting on behalf of users, or โnoneโ.
+
+
+Page 258 of 323 Version 3.1 April 2017
+
+
+**Class FMT: Security management**
+
+# **H Class FMT: Security management** **(normative)**
+
+
+998 This class specifies the management of several aspects of the TSF: security
+attributes, TSF data and functions in the TSF. The different management
+roles and their interaction, such as separation of capability, can also be
+specified
+
+
+999 In an environment where the TOE is made up of multiple physically
+separated parts, the timing issues with respect to propagation of security
+attributes, TSF data, and function modification become very complex,
+especially if the information is required to be replicated across the parts of
+the TOE. This should be considered when selecting components such as
+FMT_REV.1 Revocation, or FMT_SAE.1 Time-limited authorisation, where
+the behaviour might be impaired. In such situations, use of components from
+Internal TOE TSF data replication consistency (FPT_TRC) is advisable.
+
+
+1000 Figure 26 shows the decomposition of this class into its constituent
+components.
+
+
+April 2017 Version 3.1 Page 259 of 323
+
+
+**Class FMT: Security management**
+
+
+**Figure 26 - FMT: Security management class decomposition**
+
+## **H.1 Management of functions in TSF (FMT_MOF)**
+
+
+User notes
+
+
+1001 The TSF management functions enable authorised users to set up and control
+the secure operation of the TOE. These administrative functions typically fall
+into a number of different categories:
+
+
+Page 260 of 323 Version 3.1 April 2017
+
+
+**Class FMT: Security management**
+
+
+a) Management functions that relate to access control, accountability
+and authentication controls enforced by the TOE. For example,
+definition and update of user security characteristics (e.g. unique
+identifiers associated with user names, user accounts, system entry
+parameters) or definition and update of auditing system controls (e.g.
+selection of audit events, management of audit trails, audit trail
+analysis, and audit report generation), definition and update of peruser policy attributes (such as user clearance), definition of known
+system access control labels, and control and management of user
+groups.
+
+
+b) Management functions that relate to controls over availability. For
+example, definition and update of availability parameters or resource
+quotas.
+
+
+c) Management functions that relate to general installation and
+configuration. For example, TOE configuration, manual recovery,
+installation of TOE security fixes (if any), repair and reinstallation of
+hardware.
+
+
+d) Management functions that relate to routine control and maintenance
+of TOE resources. For example, enabling and disabling peripheral
+devices, mounting of removable storage media, backup and recovery.
+
+
+1002 Note that these functions need to be present in a TOE based on the families
+included in the PP or ST. It is the responsibility of the PP/ST author to
+ensure that adequate functions will be provided to manage the TOE in a
+secure fashion.
+
+
+1003 The TSF might contain functions that can be controlled by an administrator.
+For example, the auditing functions could be switched off, the time
+synchronisation could be switchable, and/or the authentication mechanism
+could be modifiable.
+
+
+**FMT_MOF.1** **Management of security functions behaviour**
+
+
+User application notes
+
+
+1004 This component allows identified roles to manage the security functions of
+the TSF. This might entail obtaining the current status of a security function,
+disabling or enabling the security function, or modifying the behaviour of the
+security function. An example of modifying the behaviour of the security
+functions is changing of authentication mechanisms.
+
+
+Operations
+
+
+Selection:
+
+
+1005 In **FMT_MOF.1.1**, the PP/ST author should select whether the role can
+determine the behaviour of, disable, enable, and/or modify the
+behaviour of the security functions.
+
+
+April 2017 Version 3.1 Page 261 of 323
+
+
+**Class FMT: Security management**
+
+
+Assignment:
+
+
+1006 In **FMT_MOF.1.1**, the PP/ST author should specify the functions that
+can be modified by the identified roles. Examples include auditing
+and time determination.
+
+
+1007 In **FMT_MOF.1.1**, the PP/ST author should specify the roles that are
+allowed to modify the functions in the TSF. The possible roles are
+specified in FMT_SMR.1 Security roles.
+
+## **H.2 Management of security attributes (FMT_MSA)**
+
+
+User notes
+
+
+1008 This family defines the requirements on the management of security
+attributes.
+
+
+1009 Security attributes affect the behaviour of the TSF. Examples of security
+attributes are the groups to which a user belongs, the roles he/she might
+assume, the priority of a process (subject), and the rights belonging to a role
+or a user. These security attributes might need to be managed by the user, a
+subject, a specific authorised user (a user with explicitly given rights for this
+management) or inherit values according to a given policy/set of rules.
+
+
+1010 It is noted that the right to assign rights to users is itself a security attribute
+and/or potentially subject to management by FMT_MSA.1 Management of
+security attributes.
+
+
+1011 FMT_MSA.2 Secure security attributes can be used to ensure that any
+accepted combination of security attributes is within a secure state. The
+definition of what โsecureโ means is left to the TOE guidance.
+
+
+1012 In some instances subjects, objects or user accounts are created. If no explicit
+values for the related security attributes are given, default values need to be
+used. FMT_MSA.1 Management of security attributes can be used to specify
+that these default values can be managed.
+
+
+**FMT_MSA.1** **Management of security attributes**
+
+
+User application notes
+
+
+1013 This component allows users acting in certain roles to manage identified
+security attributes. The users are assigned to a role within the component
+FMT_SMR.1 Security roles.
+
+
+1014 The default value of a parameter is the value the parameter takes when it is
+instantiated without specifically assigned values. An initial value is provided
+during the instantiation (creation) of a parameter, and overrides the default
+value.
+
+
+Page 262 of 323 Version 3.1 April 2017
+
+
+**Class FMT: Security management**
+
+
+Operations
+
+
+Assignment:
+
+
+1015 In **FMT_MSA.1.1**, the PP/ST author should list the access control SFP(s)
+or the information flow control SFP(s) for which the security
+attributes are applicable.
+
+
+Selection:
+
+
+1016 In **FMT_MSA.1.1**, the PP/ST author should specify the operations that
+can be applied to the identified security attributes. The PP/ST author
+can specify that the role can modify the default value
+(change_default), query, modify the security attribute, delete the
+security attributes entirely or define their own operation.
+
+
+Assignment:
+
+
+1017 In **FMT_MSA.1.1**, the PP/ST author should specify the security
+attributes that can be operated on by the identified roles. It is possible
+for the PP/ST author to specify that the default value such as default
+access-rights can be managed. Examples of these security attributes
+are user-clearance, priority of service level, access control list, default
+access rights.
+
+
+1018 In **FMT_MSA.1.1**, the PP/ST author should specify the roles that are
+allowed to operate on the security attributes. The possible roles are
+specified in FMT_SMR.1 Security roles.
+
+
+1019 In **FMT_MSA.1.1**, if selected, the PP/ST author should specify which
+other operations the role could perform. An example of such an
+operation could be โcreateโ.
+
+
+**FMT_MSA.2** **Secure security attributes**
+
+
+User application notes
+
+
+1020 This component contains requirements on the values that can be assigned to
+security attributes. The assigned values should be such that the TOE will
+remain in a secure state.
+
+
+1021 The definition of what โsecureโ means is not answered in this component but
+is left to the development of the TOE and the resulting information in the
+guidance. An example could be that if a user account is created, it should
+have a non-trivial password.
+
+
+Operations
+
+
+Assignment:
+
+
+1022 In **FMT_MSA.2.1**, the PP/ST author should specify the list of security
+attributes that require only secure values to be provided.
+
+
+April 2017 Version 3.1 Page 263 of 323
+
+
+**Class FMT: Security management**
+
+
+**FMT_MSA.3** **Static attribute initialisation**
+
+
+User application notes
+
+
+1023 This component requires that the TSF provide default values for relevant
+object security attributes, which can be overridden by an initial value. It may
+still be possible for a new object to have different security attributes at
+creation, if a mechanism exists to specify the permissions at time of creation.
+
+
+Operations
+
+
+Assignment:
+
+
+1024 In **FMT_MSA.3.1**, the PP/ST author should list the access control SFP or
+the information flow control SFP for which the security attributes are
+applicable.
+
+
+Selection:
+
+
+1025 In **FMT_MSA.3.1**, the PP/ST author should select whether the default
+property of the access control attribute will be restrictive, permissive,
+or another property. Only one of these options may be chosen.
+
+
+Assignment:
+
+
+1026 In **FMT_MSA.3.1**, if the PP/ST author selects another property, the
+PP/ST author should specify the desired characteristics of the default
+values.
+
+
+1027 In **FMT_MSA.3.2**, the PP/ST author should specify the roles that are
+allowed to modify the values of the security attributes. The possible
+roles are specified in FMT_SMR.1 Security roles.
+
+
+**FMT_MSA.4** **Security attribute value inheritance**
+
+
+User application notes
+
+
+1028 This component requires specification of the set of rules through which the
+security attribute inherits values and the conditions to be met for these rules
+to be applied.
+
+
+Operations
+
+
+Assignment:
+
+
+1029 In **FMT_MSA.4.1**, the PP/ST author specifies the rules governing the
+value that will be inherited by the specified security attribute,
+including the conditions that are to be met for the rules to be applied.
+For example, if a new file or directory is created (in a multilevel
+filesystem), its label is the label at which the user is logged in at the
+time it is created.
+
+
+Page 264 of 323 Version 3.1 April 2017
+
+
+**Class FMT: Security management**
+
+## **H.3 Management of TSF data (FMT_MTD)**
+
+
+User notes
+
+
+1030 This component imposes requirements on the management of TSF data.
+Examples of TSF data are the current time and the audit trail. So, for
+example, this family allows the specification of whom can read, delete or
+create the audit trail.
+
+
+**FMT_MTD.1** **Management of TSF data**
+
+
+User application notes
+
+
+1031 This component allows users with a certain role to manage values of TSF
+data. The users are assigned to a role within the component FMT_SMR.1
+Security roles.
+
+
+1032 The default value of a parameter is the values the parameter takes when it is
+instantiated without specifically assigned values. An initial value is provided
+during the instantiation (creation) of a parameter and overrides the default
+value.
+
+
+Operations
+
+
+Selection:
+
+
+1033 In **FMT_MTD.1.1**, the PP/ST author should specify the operations that
+can be applied to the identified TSF data. The PP/ST author can
+specify that the role can modify the default value (change_default),
+clear, query or modify the TSF data, or delete the TSF data entirely.
+If so desired the PP/ST author could specify any type of operation.
+To clarify โclear TSF dataโ means that the content of the TSF data is
+removed, but that the entity that stores the TSF data remains in the
+TOE.
+
+
+Assignment:
+
+
+1034 In **FMT_MTD.1.1**, the PP/ST author should specify the TSF data that
+can be operated on by the identified roles. It is possible for the PP/ST
+author to specify that the default value can be managed.
+
+
+1035 In **FMT_MTD.1.1**, the PP/ST author should specify the roles that are
+allowed to operate on the TSF data. The possible roles are specified
+in FMT_SMR.1 Security roles.
+
+
+1036 In **FMT_MTD.1.1**, if selected, the PP/ST author should specify which
+other operations the role could perform. An example could be
+โcreateโ.
+
+
+April 2017 Version 3.1 Page 265 of 323
+
+
+**Class FMT: Security management**
+
+
+**FMT_MTD.2** **Management of limits on TSF data**
+
+
+User application notes
+
+
+1037 This component specifies limits on TSF data, and actions to be taken if these
+limits are exceeded. This component, for example, will allow limits on the
+size of the audit trail to be defined, and specification of the actions to be
+taken when these limits are exceeded.
+
+
+Operations
+
+
+Assignment:
+
+
+1038 In **FMT_MTD.2.1**, the PP/ST author should specify the TSF data that
+can have limits, and the value of those limits. An example of such
+TSF data is the number of users logged-in.
+
+
+1039 In **FMT_MTD.2.1**, the PP/ST author should specify the roles that are
+allowed to modify the limits on the TSF data and the actions to be
+taken. The possible roles are specified in FMT_SMR.1 Security roles.
+
+
+1040 In **FMT_MTD.2.2**, the PP/ST author should specify the actions to be
+taken if the specified limit on the specified TSF data is exceeded. An
+example of such TSF action is that the authorised user is informed
+and an audit record is generated.
+
+
+**FMT_MTD.3** **Secure TSF data**
+
+
+User application notes
+
+
+1041 This component covers requirements on the values that can be assigned to
+TSF data. The assigned values should be such that the TOE will remain in a
+secure state.
+
+
+1042 The definition of what โsecureโ means is not answered in this component but
+is left to the development of the TOE and the resulting information in the
+guidance.
+
+
+Operations
+
+
+Assignment:
+
+
+1043 In **FMT_MTD.3.1**, the PP/ST author should specify what TSF data
+require only secure values to be accepted.
+
+## **H.4 Revocation (FMT_REV)**
+
+
+User notes
+
+
+1044 This family addresses revocation of security attributes for a variety of entities
+within a TOE.
+
+
+Page 266 of 323 Version 3.1 April 2017
+
+
+**Class FMT: Security management**
+
+
+**FMT_REV.1** **Revocation**
+
+
+User application notes
+
+
+1045 This component specifies requirements on the revocation of rights. It
+requires the specification of the revocation rules. Examples are:
+
+
+a) Revocation will take place on the next login of the user;
+
+
+b) Revocation will take place on the next attempt to open the file;
+
+
+c) Revocation will take place within a fixed time. This might mean that
+all open connections are re-evaluated every x minutes.
+
+
+Operations
+
+
+Assignment:
+
+
+1046 In **FMT_REV.1.1**, the PP/ST author should specify which security
+attributes are to be revoked when a change is made to the associated
+object/subject/user/other resource.
+
+
+Selection:
+
+
+1047 In **FMT_REV.1.1**, the PP/ST author should specify whether the ability to
+revoke security attributes from users, subjects, objects, or any
+additional resources shall be provided by the TSF.
+
+
+Assignment:
+
+
+1048 In **FMT_REV.1.1**, the PP/ST author should specify the roles that are
+allowed to modify the functions in the TSF. The possible roles are
+specified in FMT_SMR.1 Security roles.
+
+
+1049 In **FMT_REV.1.1**, the PP/ST author should, if additional resources is
+selected, specify whether the ability to revoke their security attributes
+shall be provided by the TSF.
+
+
+1050 In **FMT_REV.1.2**, the PP/ST author should specify the revocation rules.
+Examples of these rules could include: โprior to the next operation on
+the associated resourceโ, or โfor all new subject creationsโ.
+
+## **H.5 Security attribute expiration (FMT_SAE)**
+
+
+User notes
+
+
+1051 This family addresses the capability to enforce time limits for the validity of
+security attributes. This family can be applied to specify expiration
+requirements for access control attributes, identification and authentication
+attributes, certificates (key certificates such as ANSI X509 for example),
+audit attributes, etc.
+
+
+April 2017 Version 3.1 Page 267 of 323
+
+
+**Class FMT: Security management**
+
+
+**FMT_SAE.1** **Time-limited authorisation**
+
+
+Operations
+
+
+Assignment:
+
+
+1052 In **FMT_SAE.1.1**, the PP/ST author should provide the list of security
+attributes for which expiration is to be supported. An example of such
+an attribute might be a user's security clearance.
+
+
+1053 In **FMT_SAE.1.1**, the PP/ST author should specify the roles that are
+allowed to modify the security attributes in the TSF. The possible
+roles are specified in FMT_SMR.1 Security roles.
+
+
+1054 In **FMT_SAE.1.2**, the PP/ST author should provide a list of actions to be
+taken for each security attribute when it expires. An example might
+be that the user's security clearance, when it expires, is set to the
+lowest allowable clearance on the TOE. If immediate revocation is
+desired by the PP/ST, the action โimmediate revocationโ should be
+specified.
+
+## **H.6 Specification of Management Functions (FMT_SMF)**
+
+
+User notes
+
+
+1055 This family allows the specification of the management functions to be
+provided by the TOE. Each security management function that is listed in
+fulfilling the assignment is either security attribute management, TSF data
+management, or security function management.
+
+
+**FMT_SMF.1** **Specification of Management Functions**
+
+
+User application notes
+
+
+1056 This component specifies the management functions to be provided.
+
+
+1057 PP/ST authors should consult the โManagementโ sections for components
+included in their PP/ST to provide a basis for the management functions to
+be listed via this component.
+
+
+Operations
+
+
+Assignment:
+
+
+1058 In **FMT_SMF.1.1**, the PP/ST author should specify the management
+functions to be provided by the TSF, either security attribute
+management, TSF data management, or security function
+management.
+
+
+Page 268 of 323 Version 3.1 April 2017
+
+
+**Class FMT: Security management**
+
+## **H.7 Security management roles (FMT_SMR)**
+
+
+User notes
+
+
+1059 This family reduces the likelihood of damage resulting from users abusing
+their authority by taking actions outside their assigned functional
+responsibilities. It also addresses the threat that inadequate mechanisms have
+been provided to securely administer the TSF.
+
+
+1060 This family requires that information be maintained to identify whether a
+user is authorised to use a particular security-relevant administrative function.
+
+
+1061 Some management actions can be performed by users, others only by
+designated people within the organisation. This family allows the definition
+of different roles, such as owner, auditor, administrator, daily-management.
+
+
+1062 The roles as used in this family are security related roles. Each role can
+encompass an extensive set of capabilities (e.g. root in UNIX), or can be a
+single right (e.g. right to read a single object such as the helpfile). This
+family defines the roles. The capabilities of the role are defined in
+Management of functions in TSF (FMT_MOF), Management of security
+attributes (FMT_MSA) and Management of TSF data (FMT_MTD).
+
+
+1063 Some type of roles might be mutually exclusive. For example the dailymanagement might be able to define and activate users, but might not be able
+to remove users (which is reserved for the administrator (role)). This class
+will allow policies such as two-person control to be specified.
+
+
+**FMT_SMR.1** **Security roles**
+
+
+User application notes
+
+
+1064 This component specifies the different roles that the TSF should recognise.
+Often the system distinguishes between the owner of an entity, an
+administrator and other users.
+
+
+Operations
+
+
+Assignment:
+
+
+1065 In **FMT_SMR.1.1**, the PP/ST author should specify the roles that are
+recognised by the system. These are the roles that users could occupy
+with respect to security. Examples are: owner, auditor and
+administrator.
+
+
+**FMT_SMR.2** **Restrictions on security roles**
+
+
+User application notes
+
+
+1066 This component specifies the different roles that the TSF should recognise,
+and conditions on how those roles could be managed. Often the system
+
+
+April 2017 Version 3.1 Page 269 of 323
+
+
+**Class FMT: Security management**
+
+
+distinguishes between the owner of an entity, an administrator and other
+users.
+
+
+1067 The conditions on those roles specify the interrelationship between the
+different roles, as well as restrictions on when the role can be assumed by a
+user.
+
+
+Operations
+
+
+Assignment:
+
+
+1068 In **FMT_SMR.2.1**, the PP/ST author should specify the roles that are
+recognised by the system. These are the roles that users could occupy
+with respect to security. Examples are: owner, auditor, administrator.
+
+
+1069 In **FMT_SMR.2.3**, the PP/ST author should specify the conditions that
+govern role assignment. Examples of these conditions are: โan
+account cannot have both the auditor and administrator roleโ or โa
+user with the assistant role must also have the owner roleโ.
+
+
+**FMT_SMR.3** **Assuming roles**
+
+
+User application notes
+
+
+1070 This component specifies that an explicit request must be given to assume
+the specific role.
+
+
+Operations
+
+
+Assignment:
+
+
+1071 In **FMT_SMR.3.1**, the PP/ST author should specify the roles that require
+an explicit request to be assumed. Examples are: auditor and
+administrator.
+
+
+Page 270 of 323 Version 3.1 April 2017
+
+
+**Class FPR: Privacy**
+
+# **I Class FPR: Privacy** **(normative)**
+
+
+1072 This class describes the requirements that could be levied to satisfy the users'
+privacy needs, while still allowing the system flexibility as far as possible to
+maintain sufficient control over the operation of the system.
+
+
+1073 In the components of this class there is flexibility as to whether or not
+authorised users are covered by the required security functionality. For
+example, a PP/ST author might consider it appropriate not to require
+protection of the privacy of users against a suitably authorised user.
+
+
+1074 This class, together with other classes (such as those concerned with audit,
+access control, trusted path, and non-repudiation) provides the flexibility to
+specify the desired privacy behaviour. On the other hand, the requirements in
+this class might impose limitations on the use of the components of other
+classes, such as FIA: Identification and authentication or FAU: Security audit.
+For example, if authorised users are not allowed to see the user identity (e.g.
+Anonymity or Pseudonymity), it will obviously not be possible to hold
+individual users accountable for any security relevant actions they perform
+that are covered by the privacy requirements. However, it may still be
+possible to include audit requirements in a PP/ST, where the fact that a
+particular security relevant event has occurred is more important than
+knowing who was responsible for it.
+
+
+1075 Additional information is provided in the application notes for class FAU:
+Security audit, where it is explained that the definition of โidentityโ in the
+context of auditing can also be an alias or other information that could
+identify a user.
+
+
+1076 This class describes four families: Anonymity, Pseudonymity, Unlinkability
+and Unobservability. Anonymity, Pseudonymity and Unlinkability have a
+complex interrelationship. When choosing a family, the choice should
+depend on the threats identified. For some types of privacy threats,
+pseudonymity will be more appropriate than anonymity (e.g. if there is a
+requirement for auditing). In addition, some types of privacy threats are best
+countered by a combination of components from several families.
+
+
+1077 All families assume that a user does not explicitly perform an action that
+discloses the user's own identity. For example, the TSF is not expected to
+screen the user name in electronic messages or databases.
+
+
+1078 All families in this class have components that can be scoped through
+operations. These operations allow the PP/ST author to state the cooperating
+users/subjects to which the TSF must be resistant. An example of an
+instantiation of anonymity could be: โ The TSF shall ensure that the users
+and/or subjects are unable to determine the user identity bound to the
+teleconsulting applicationโ.
+
+
+April 2017 Version 3.1 Page 271 of 323
+
+
+**Class FPR: Privacy**
+
+
+1079 It is noted that the TSF should not only provide this protection against
+individual users, but also against users cooperating to obtain the information.
+
+
+1080 Figure 27 shows the decomposition of this class into its constituent
+components.
+
+
+**Figure 27 - FPR: Privacy class decomposition**
+
+## **I.1 Anonymity (FPR_ANO)**
+
+
+User notes
+
+
+1081 Anonymity ensures that a subject may use a resource or service without
+disclosing its user identity.
+
+
+1082 The intention of this family is to specify that a user or subject might take
+action without releasing its user identity to others such as users, subjects, or
+objects. The family provides the PP/ST author with a means to identify the
+set of users that cannot see the identity of someone performing certain
+actions.
+
+
+1083 Therefore if a subject, using anonymity, performs an action, another subject
+will not be able to determine either the identity or even a reference to the
+identity of the user employing the subject. The focus of the anonymity is on
+the protection of the users identity, not on the protection of the subject
+identity; hence, the identity of the subject is not protected from disclosure.
+
+
+1084 Although the identity of the subject is not released to other subjects or users,
+the TSF is not explicitly prohibited from obtaining the users identity. In case
+the TSF is not allowed to know the identity of the user, FPR_ANO.2
+
+
+Page 272 of 323 Version 3.1 April 2017
+
+
+**Class FPR: Privacy**
+
+
+Anonymity without soliciting information could be invoked. In that case the
+TSF should not request the user information.
+
+
+1085 The interpretation of โdetermineโ should be taken in the broadest sense of
+the word.
+
+
+1086 The component levelling distinguishes between the users and an authorised
+user. An authorised user is often excluded from the component, and therefore
+allowed to retrieve a user's identity. However, there is no specific
+requirement that an authorised user must be able to have the capability to
+determine the user's identity. For ultimate privacy the components would be
+used to say that no user or authorised user can see the identity of anyone
+performing any action.
+
+
+1087 Although some systems will provide anonymity for all services that are
+provided, other systems provide anonymity for certain subjects/operations.
+To provide this flexibility, an operation is included where the scope of the
+requirement is defined. If the PP/ST author wants to address all
+subjects/operations, the words โall subjects and all operationsโ could be
+provided.
+
+
+1088 Possible applications include the ability to make enquiries of a confidential
+nature to public databases, respond to electronic polls, or make anonymous
+payments or donations.
+
+
+1089 Examples of potential hostile users or subjects are providers, system
+operators, communication partners and users, who smuggle malicious parts
+(e.g. Trojan Horses) into systems. All of these users can investigate usage
+patterns (e.g. which users used which services) and misuse this information.
+
+
+**FPR_ANO.1** **Anonymity**
+
+
+User application notes
+
+
+1090 This component ensures that the identity of a user is protected from
+disclosure. There may be instances, however, that a given authorised user
+can determine who performed certain actions. This component gives the
+flexibility to capture either a limited or total privacy policy.
+
+
+Operations
+
+
+Assignment:
+
+
+1091 In **FPR_ANO.1.1**, the PP/ST author should specify the set of users
+and/or subjects against which the TSF must provide protection. For
+example, even if the PP/ST author specifies a single user or subject
+role, the TSF must not only provide protection against each
+individual user or subject, but must protect with respect to
+cooperating users and/or subjects. A set of users, for example, could
+be a group of users which can operate under the same role or can all
+use the same process(es).
+
+
+April 2017 Version 3.1 Page 273 of 323
+
+
+**Class FPR: Privacy**
+
+
+1092 In **FPR_ANO.1.1**, the PP/ST author should identify the list of subjects
+and/or operations and/or objects where the real user name of the
+subject should be protected, for example, โthe voting applicationโ.
+
+
+**FPR_ANO.2** **Anonymity without soliciting information**
+
+
+User application notes
+
+
+1093 This component is used to ensure that the TSF is not allowed to know the
+identity of the user.
+
+
+Operations
+
+
+Assignment:
+
+
+1094 In **FPR_ANO.2.1**, the PP/ST author should specify the set of users
+and/or subjects against which the TSF must provide protection. For
+example, even if the PP/ST author specifies a single user or subject
+role, the TSF must not only provide protection against each
+individual user or subject, but must protect with respect to
+cooperating users and/or subjects. A set of users, for example, could
+be a group of users which can operate under the same role or can all
+use the same process(es).
+
+
+1095 In **FPR_ANO.2.1**, the PP/ST author should identify the list of subjects
+and/or operations and/or objects where the real user name of the
+subject should be protected, for example, โthe voting applicationโ.
+
+
+1096 In **FPR_ANO.2.2**, the PP/ST author should identify the list of services
+which are subject to the anonymity requirement, for example, โthe
+accessing of job descriptionsโ.
+
+
+1097 In **FPR_ANO.2.2**, the PP/ST author should identify the list of subjects
+from which the real user name of the subject should be protected
+when the specified services are provided.
+
+## **I.2 Pseudonymity (FPR_PSE)**
+
+
+User notes
+
+
+1098 Pseudonymity ensures that a user may use a resource or service without
+disclosing its identity, but can still be accountable for that use. The user can
+be accountable by directly being related to a reference (alias) held by the
+TSF, or by providing an alias that will be used for processing purposes, such
+as an account number.
+
+
+1099 In several respects, pseudonymity resembles anonymity. Both pseudonymity
+and anonymity protect the identity of the user, but in pseudonymity a
+reference to the user's identity is maintained for accountability or other
+purposes.
+
+
+Page 274 of 323 Version 3.1 April 2017
+
+
+**Class FPR: Privacy**
+
+
+1100 The component FPR_PSE.1 Pseudonymity does not specify the requirements
+on the reference to the user's identity. For the purpose of specifying
+requirements on this reference two sets of requirements are presented:
+FPR_PSE.2 Reversible pseudonymity and FPR_PSE.3 Alias pseudonymity.
+
+
+1101 A way to use the reference is by being able to obtain the original user
+identity. For example, in a digital cash environment it would be
+advantageous to be able to trace the user's identity when a check has been
+issued multiple times (i.e. fraud). In general, the user's identity needs to be
+retrieved under specific conditions. The PP/ST author might want to
+incorporate FPR_PSE.2 Reversible pseudonymity to describe those services.
+
+
+1102 Another usage of the reference is as an alias for a user. For example, a user
+who does not wish to be identified, can provide an account to which the
+resource utilisation should be charged. In such cases, the reference to the
+user identity is an alias for the user, where other users or subjects can use the
+alias for performing their functions without ever obtaining the user's identity
+(for example, statistical operations on use of the system). In this case, the
+PP/ST author might wish to incorporate FPR_PSE.3 Alias pseudonymity to
+specify the rules to which the reference must conform.
+
+
+1103 Using these constructs above, digital money can be created using
+FPR_PSE.2 Reversible pseudonymity specifying that the user identity will
+be protected and, if so specified in the condition, that there be a requirement
+to trace the user identity if the digital money is spent twice. When the user is
+honest, the user identity is protected; if the user tries to cheat, the user
+identity can be traced.
+
+
+1104 A different kind of system could be a digital credit card, where the user will
+provide a pseudonym that indicates an account from which the cash can be
+subtracted. In such cases, for example, FPR_PSE.3 Alias pseudonymity
+could be used. This component would specify that the user identity will be
+protected and, furthermore, that the same user will only get assigned values
+for which he/she has provided money (if so specified in the conditions).
+
+
+1105 It should be realised that the more stringent components potentially cannot
+be combined with other requirements, such as identification and
+authentication or audit. The interpretation of โdetermine the identityโ should
+be taken in the broadest sense of the word. The information is not provided
+by the TSF during the operation, nor can the entity determine the subject or
+the owner of the subject that invoked the operation, nor will the TSF record
+information, available to the users or subjects, which might release the user
+identity in the future.
+
+
+1106 The intent is that the TSF not reveal any information that would compromise
+the identity of the user, e.g. the identity of subjects acting on the user's behalf.
+The information that is considered to be sensitive depends on the effort an
+attacker is capable of spending.
+
+
+April 2017 Version 3.1 Page 275 of 323
+
+
+**Class FPR: Privacy**
+
+
+1107 Possible applications include the ability to charge a caller for premium rate
+telephone services without disclosing his or her identity, or to be charged for
+the anonymous use of an electronic payment system.
+
+
+1108 Examples of potential hostile users are providers, system operators,
+communication partners and users, who smuggle malicious parts (e.g. Trojan
+Horses) into systems. All of these attackers can investigate which users used
+which services and misuse this information. Additionally to Anonymity
+services, Pseudonymity Services contains methods for authorisation without
+identification, especially for anonymous payment (โDigital Cashโ). This
+helps providers to obtain their payment in a secure way while maintaining
+customer anonymity.
+
+
+**FPR_PSE.1** **Pseudonymity**
+
+
+User application notes
+
+
+1109 This component provides the user protection against disclosure of identity to
+other users. The user will remain accountable for its actions.
+
+
+Operations
+
+
+Assignment:
+
+
+1110 In **FPR_PSE.1.1**, the PP/ST author should specify the set of users and/or
+subjects against which the TSF must provide protection. For example,
+even if the PP/ST author specifies a single user or subject role, the
+TSF must not only provide protection against each individual user or
+subject, but must protect with respect to cooperating users and/or
+subjects. A set of users, for example, could be a group of users which
+can operate under the same role or can all use the same process(es).
+
+
+1111 In **FPR_PSE.1.1**, the PP/ST author should identify the list of subjects
+and/or operations and/or objects where the real user name of the
+subject should be protected, for example, โthe accessing of job
+offersโ. Note that โobjectsโ includes any other attributes that might
+enable another user or subject to derive the actual identity of the user.
+
+
+1112 In **FPR_PSE.1.2**, the PP/ST author should identify the (one or more)
+number of aliases the TSF is able to provide.
+
+
+1113 In **FPR_PSE.1.2**, the PP/ST author should identify the list of subjects to
+whom the TSF is able to provide an alias.
+
+
+Selection:
+
+
+1114 In **FPR_PSE.1.3**, the PP/ST author should specify whether the user alias
+is generated by the TSF, or supplied by the user. Only one of these
+options may be chosen.
+
+
+Page 276 of 323 Version 3.1 April 2017
+
+
+**Class FPR: Privacy**
+
+
+Assignment:
+
+
+1115 In **FPR_PSE.1.3**, the PP/ST author should identify the metric to which
+the TSF-generated or user-generated alias should conform.
+
+
+**FPR_PSE.2** **Reversible pseudonymity**
+
+
+User application notes
+
+
+1116 In this component, the TSF shall ensure that under specified conditions the
+user identity related to a provided reference can be determined.
+
+
+1117 In FPR_PSE.1 Pseudonymity the TSF shall provide an alias instead of the
+user identity. When the specified conditions are satisfied, the user identity to
+which the alias belong can be determined. An example of such a condition in
+an electronic cash environment is: โ The TSF shall provide the notary a
+capability to determine the user identity based on the provided alias only
+under the conditions that a check has been issued twice.โ.
+
+
+Operations
+
+
+Assignment:
+
+
+1118 In **FPR_PSE.2.1**, the PP/ST author should specify the set of users and/or
+subjects against which the TSF must provide protection. For example,
+even if the PP/ST author specifies a single user or subject role, the
+TSF must not only provide protection against each individual user or
+subject, but must protect with respect to cooperating users and/or
+subjects. A set of users, for example, could be a group of users which
+can operate under the same role or can all use the same process(es).
+
+
+1119 In **FPR_PSE.2.1**, the PP/ST author should identify the list of subjects
+and/or operations and/or objects where the real user name of the
+subject should be protected, for example, โthe accessing of job
+offersโ. Note that โobjectsโ includes any other attributes that might
+enable another user or subject to derive the actual identity of the user.
+
+
+1120 In **FPR_PSE.2.2**, the PP/ST author should identify the (one or more)
+number of aliases the TSF, is able to provide.
+
+
+1121 In **FPR_PSE.2.2**, the PP/ST author should identify the list of subjects to
+whom the TSF is able to provide an alias.
+
+
+Selection:
+
+
+1122 In **FPR_PSE.2.3**, the PP/ST author should specify whether the user alias
+is generated by the TSF or supplied by the user. Only one of these
+options may be chosen.
+
+
+April 2017 Version 3.1 Page 277 of 323
+
+
+**Class FPR: Privacy**
+
+
+Assignment:
+
+
+1123 In **FPR_PSE.2.3**, the PP/ST author should identify the metric to which
+the TSF-generated or user-generated alias should conform.
+
+
+Selection:
+
+
+1124 In **FPR_PSE.2.4**, the PP/ST author should select whether the authorised
+user and/or trusted subjects can determine the real user name.
+
+
+Assignment:
+
+
+1125 In **FPR_PSE.2.4**, the PP/ST author should identify the list of conditions
+under which the trusted subjects and authorised user can determine
+the real user name based on the provided reference. These conditions
+can be conditions such as time of day, or they can be administrative
+such as on a court order.
+
+
+1126 In **FPR_PSE.2.4**, the PP/ST author should identify the list of trusted
+subjects that can obtain the real user name under a specified condition,
+for example, a notary or special authorised user.
+
+
+**FPR_PSE.3** **Alias pseudonymity**
+
+
+User application notes
+
+
+1127 In this component, the TSF shall ensure that the provided reference meets
+certain construction rules, and thereby can be used in a secure way by
+potentially insecure subjects.
+
+
+1128 If a user wants to use disk resources without disclosing its identity,
+pseudonymity can be used. However, every time the user accesses the system,
+the same alias must be used. Such conditions can be specified in this
+component.
+
+
+Operations
+
+
+Assignment:
+
+
+1129 In **FPR_PSE.3.1**, the PP/ST author should specify the set of users and/or
+subjects against which the TSF must provide protection. For example,
+even if the PP/ST author specifies a single user or subject role, the
+TSF must not only provide protection against each individual user or
+subject, but must protect with respect to cooperating users and/or
+subjects. A set of users, for example, could be a group of users which
+can operate under the same role or can all use the same process(es).
+
+
+1130 In **FPR_PSE.3.1**, the PP/ST author should identify the list of subjects
+and/or operations and/or objects where the real user name of the
+subject should be protected, for example, โthe accessing of job
+offersโ. Note that โobjectsโ includes any other attributes which might
+enable another user or subject to derive the actual identity of the user.
+
+
+Page 278 of 323 Version 3.1 April 2017
+
+
+**Class FPR: Privacy**
+
+
+1131 In **FPR_PSE.3.2**, the PP/ST author should identify the (one or more)
+number of aliases the TSF is able to provide.
+
+
+1132 In **FPR_PSE.3.2**, the PP/ST author should identify the list of subjects to
+whom the TSF is able to provide an alias.
+
+
+Selection:
+
+
+1133 In **FPR_PSE.3.3**, the PP/ST author should specify whether the user alias
+is generated by the TSF, or supplied by the user. Only one of these
+options may be chosen.
+
+
+Assignment:
+
+
+1134 In **FPR_PSE.3.3**, the PP/ST author should identify the metric to which
+the TSF-generated or user-generated alias should conform.
+
+
+1135 In **FPR_PSE.3.4**, the PP/ST author should identify the list of conditions
+that indicate when the used reference for the real user name shall be
+identical and when it shall be different, for example, โwhen the user
+logs on to the same hostโ it will use a unique alias.
+
+## **I.3 Unlinkability (FPR_UNL)**
+
+
+User notes
+
+
+1136 Unlinkability ensures that a user may make multiple uses of resources or
+services without others being able to link these uses together. Unlinkability
+differs from pseudonymity that, although in pseudonymity the user is also
+not known, relations between different actions can be provided.
+
+
+1137 The requirements for unlinkability are intended to protect the user identity
+against the use of profiling of the operations. For example, when a telephone
+smart card is employed with a unique number, the telephone company can
+determine the behaviour of the user of this telephone card. When a telephone
+profile of the users is known, the card can be linked to a specific user. Hiding
+the relationship between different invocations of a service or access of a
+resource will prevent this kind of information gathering.
+
+
+1138 As a result, a requirement for unlinkability could imply that the subject and
+user identity of an operation must be protected. Otherwise this information
+might be used to link operations together.
+
+
+1139 Unlinkability requires that different operations cannot be related. This
+relationship can take several forms. For example, the user associated with the
+operation, or the terminal which initiated the action, or the time the action
+was executed. The PP/ST author can specify what kind of relationships are
+present that must be countered.
+
+
+1140 Possible applications include the ability to make multiple use of a
+pseudonym without creating a usage pattern that might disclose the user's
+identity.
+
+
+April 2017 Version 3.1 Page 279 of 323
+
+
+**Class FPR: Privacy**
+
+
+1141 Examples for potential hostile subjects and users are providers, system
+operators, communication partners and users, who smuggle malicious parts,
+(e.g. Trojan Horses) into systems, they do not operate but want to get
+information about. All of these attackers can investigate (e.g. which users
+used which services) and misuse this information. Unlinkability protects
+users from linkages, which could be drawn between several actions of a
+customer. An example is a series of phone calls made by an anonymous
+customer to different partners, where the combination of the partner's
+identities might disclose the identity of the customer.
+
+
+**FPR_UNL.1** **Unlinkability**
+
+
+User application notes
+
+
+1142 This component ensures that users cannot link different operations in the
+system and thereby obtain information.
+
+
+Operations
+
+
+Assignment:
+
+
+1143 In **FPR_UNL.1.1**, the PP/ST author should specify the set of users
+and/or subjects against which the TSF must provide protection. For
+example, even if the PP/ST author specifies a single user or subject
+role, the TSF must not only provide protection against each
+individual user or subject, but must protect with respect to
+cooperating users and/or subjects. A set of users, for example, could
+be a group of users which can operate under the same role or can all
+use the same process(es).
+
+
+1144 In **FPR_UNL.1.1**, the PP/ST author should identify the list of operations
+which should be subjected to the unlinkability requirement, for
+example, โsending emailโ.
+
+
+Selection:
+
+
+1145 In **FPR_UNL.1.1**, the PP/ST author should select the relationships that
+should be obscured. The selection allows either the user identity or an
+assignment of relations to be specified.
+
+
+Assignment:
+
+
+1146 In **FPR_UNL.1.1**, the PP/ST author should identify the list of relations
+which should be protected against, for example, โoriginate from the
+same terminalโ.
+
+
+Page 280 of 323 Version 3.1 April 2017
+
+
+**Class FPR: Privacy**
+
+## **I.4 Unobservability (FPR_UNO)**
+
+
+User notes
+
+
+1147 Unobservability ensures that a user may use a resource or service without
+others, especially third parties, being able to observe that the resource or
+service is being used.
+
+
+1148 Unobservability approaches the user identity from a different direction than
+the previous families Anonymity, Pseudonymity and Unlinkability. In this
+case, the intent is to hide the use of a resource or service, rather than to hide
+the user's identity.
+
+
+1149 A number of techniques can be applied to implement unobservability.
+Examples of techniques to provide unobservability are:
+
+
+a) Allocation of information impacting unobservability: Unobservability
+relevant information (e.g. information that describes that an operation
+occurred) can be allocated in several locations within the TOE. The
+information might be allocated to a single randomly chosen part of
+the TOE such that an attacker does not know which part of the TOE
+should be attacked. An alternative system might distribute the
+information such that no single part of the TOE has sufficient
+information that, if circumvented, the privacy of the user would be
+compromised. This technique is explicitly addressed in FPR_UNO.2
+Allocation of information impacting unobservability.
+
+
+b) Broadcast: When information is broadcast (e.g. ethernet, radio), users
+cannot determine who actually received and used that information.
+This technique is especially useful when information should reach
+receivers which have to fear a stigma for being interested in that
+information (e.g. sensitive medical information).
+
+
+c) Cryptographic protection and message padding: People observing a
+message stream might obtain information from the fact that a
+message is transferred and from attributes on that message. By traffic
+padding, message padding and encrypting the message stream, the
+transmission of a message and its attributes can be protected.
+
+
+1150 Sometimes, users should not see the use of a resource, but an authorised user
+must be allowed to see the use of the resource in order to perform his duties.
+In such cases, the FPR_UNO.4 Authorised user observability could be used,
+which provides the capability for one or more authorised users to see the
+usage.
+
+
+1151 This family makes use of the concept โparts of the TOEโ. This is considered
+any part of the TOE that is either physically or logically separated from other
+parts of the TOE.
+
+
+April 2017 Version 3.1 Page 281 of 323
+
+
+**Class FPR: Privacy**
+
+
+1152 Unobservability of communications may be an important factor in many
+areas, such as the enforcement of constitutional rights, organisational policies,
+or in defence related applications.
+
+
+**FPR_UNO.1** **Unobservability**
+
+
+User application notes
+
+
+1153 This component requires that the use of a function or resource cannot be
+observed by unauthorised users.
+
+
+Operations
+
+
+Assignment:
+
+
+1154 In **FPR_UNO.1.1**, the PP/ST author should specify the list of users
+and/or subjects against which the TSF must provide protection. For
+example, even if the PP/ST author specifies a single user or subject
+role, the TSF must not only provide protection against each
+individual user or subject, but must protect with respect to
+cooperating users and/or subjects. A set of users, for example, could
+be a group of users which can operate under the same role or can all
+use the same process(es).
+
+
+1155 In **FPR_UNO.1.1**, the PP/ST author should identify the list of operations
+that are subjected to the unobservability requirement. Other
+users/subjects will then not be able to observe the operations on a
+covered object in the specified list (e.g. reading and writing to the
+object).
+
+
+1156 In **FPR_UNO.1.1**, the PP/ST author should identify the list of objects
+which are covered by the unobservability requirement. An example
+could be a specific mail server or ftp site.
+
+
+1157 In **FPR_UNO.1.1**, the PP/ST author should specify the set of protected
+users and/or subjects whose unobservability information will be
+protected. An example could be: โusers accessing the system through
+the internetโ.
+
+
+**FPR_UNO.2** **Allocation of information impacting unobservability**
+
+
+User application notes
+
+
+1158 This component requires that the use of a function or resource cannot be
+observed by specified users or subjects. Furthermore this component
+specifies that information related to the privacy of the user is distributed
+within the TOE such that attackers might not know which part of the TOE to
+target, or they need to attack multiple parts of the TOE.
+
+
+1159 An example of the use of this component is the use of a randomly allocated
+node to provide a function. In such a case the component might require that
+
+
+Page 282 of 323 Version 3.1 April 2017
+
+
+**Class FPR: Privacy**
+
+
+the privacy related information shall only be available to one identified part
+of the TOE, and will not be communicated outside this part of the TOE.
+
+
+1160 A more complex example can be found in some โvoting algorithmsโ. Several
+parts of the TOE will be involved in the service, but no individual part of the
+TOE will be able to violate the policy. So a person may cast a vote (or not)
+without the TOE being able to determine whether a vote has been cast and
+what the vote happened to be (unless the vote was unanimous).
+
+
+Operations
+
+
+Assignment:
+
+
+1161 In **FPR_UNO.2.1**, the PP/ST author should specify the list of users
+and/or subjects against which the TSF must provide protection. For
+example, even if the PP/ST author specifies a single user or subject
+role, the TSF must not only provide protection against each
+individual user or subject, but must protect with respect to
+cooperating users and/or subjects. A set of users, for example, could
+be a group of users which can operate under the same role or can all
+use the same process(es).
+
+
+1162 In **FPR_UNO.2.1**, the PP/ST author should identify the list of operations
+that are subjected to the unobservability requirement. Other
+users/subjects will then not be able to observe the operations on a
+covered object in the specified list (e.g. reading and writing to the
+object).
+
+
+1163 In **FPR_UNO.2.1**, the PP/ST author should identify the list of objects
+which are covered by the unobservability requirement. An example
+could be a specific mail server or ftp site.
+
+
+1164 In **FPR_UNO.2.1**, the PP/ST author should specify the set of protected
+users and/or subjects whose unobservability information will be
+protected. An example could be: โusers accessing the system through
+the internetโ.
+
+
+1165 In **FPR_UNO.2.2**, the PP/ST author should identify which privacy
+related information should be distributed in a controlled manner.
+Examples of this information could be: IP address of subject, IP
+address of object, time, used encryption keys.
+
+
+1166 In **FPR_UNO.2.2**, the PP/ST author should specify the conditions to
+which the dissemination of the information should adhere. These
+conditions should be maintained throughout the lifetime of the
+privacy related information of each instance. Examples of these
+conditions could be: โthe information shall only be present at a single
+separated part of the TOE and shall not be communicated outside this
+part of the TOE.โ, โthe information shall only reside in a single
+separated part of the TOE, but shall be moved to another part of the
+TOE periodicallyโ, โthe information shall be distributed between the
+
+
+April 2017 Version 3.1 Page 283 of 323
+
+
+**Class FPR: Privacy**
+
+
+different parts of the TOE such that compromise of any 5 separated
+parts of the TOE will not compromise the security policyโ.
+
+
+**FPR_UNO.3** **Unobservability without soliciting information**
+
+
+User application notes
+
+
+1167 This component is used to require that the TSF does not try to obtain
+information that might compromise unobservability when provided specific
+services. Therefore the TSF will not solicit (i.e. try to obtain from other
+entities) any information that might be used to compromise unobservability.
+
+
+Operations
+
+
+Assignment:
+
+
+1168 In **FPR_UNO.3.1**, the PP/ST author should identify the list of services
+which are subject to the unobservability requirement, for example,
+โthe accessing of job descriptionsโ.
+
+
+1169 In **FPR_UNO.3.1**, the PP/ST author should identify the list of subjects
+from which privacy related information should be protected when the
+specified services are provided.
+
+
+1170 In **FPR_UNO.3.1**, the PP/ST author should specify the privacy related
+information that will be protected from the specified subjects.
+Examples include the identity of the subject that used a service and
+the quantity of a service that has been used such as memory resource
+utilisation.
+
+
+**FPR_UNO.4** **Authorised user observability**
+
+
+User application notes
+
+
+1171 This component is used to require that there will be one or more authorised
+users with the rights to view the resource utilisation. Without this component,
+this review is allowed, but not mandated.
+
+
+Operations
+
+
+Assignment:
+
+
+1172 In **FPR_UNO.4.1**, the PP/ST author should specify the set of authorised
+users for which the TSF must provide the capability to observe the
+resource utilisation. A set of authorised users, for example, could be a
+group of authorised users which can operate under the same role or
+can all use the same process(es).
+
+
+1173 In **FPR_UNO.4.1**, the PP/ST author should specify the set of resources
+and/or services that the authorised user must be able to observe.
+
+
+Page 284 of 323 Version 3.1 April 2017
+
+
+**Class FPT: Protection of the TSF**
+
+# **J Class FPT: Protection of the TSF** **(normative)**
+
+
+1174 This class contains families of functional requirements that relate to the
+integrity and management of the mechanisms that constitute the TSF and to
+the integrity of TSF data. In some sense, families in this class may appear to
+duplicate components in the FDP: User data protection class; they may even
+be implemented using the same mechanisms. However, FDP: User data
+protection focuses on user data protection, while FPT: Protection of the TSF
+focuses on TSF data protection. In fact, components from the FPT:
+Protection of the TSF class are necessary to provide requirements that the
+SFPs in the TOE cannot be tampered with or bypassed.
+
+
+1175 From the point of view of this class, regarding to the TSF there are three
+significant elements:
+
+
+a) The TSF's implementation, which executes and implements the
+mechanisms that enforce the SFRs.
+
+
+b) The TSF's data, which are the administrative databases that guide the
+enforcement of the SFRs.
+
+
+c) The external entities that the TSF may interact with in order to
+enforce the SFRs.
+
+
+1176 All of the families in the FPT: Protection of the TSF class can be related to
+these areas, and fall into the following groupings:
+
+
+a) TSF physical protection (FPT_PHP), which provides an authorised
+user with the ability to detect external attacks on the parts of the TOE
+that comprise the TSF.
+
+
+b) Testing of external entities (FPT_TEE) and TSF self test (FPT_TST),
+which provide an authorised user with the ability to verify the correct
+operation of the external entities interacting with the TSF to enforce
+the SFRs, and the integrity of the TSF data and TSF itself.
+
+
+c) Trusted recovery (FPT_RCV), Fail secure (FPT_FLS), and Internal
+TOE TSF data replication consistency (FPT_TRC), which address
+the behaviour of the TSF when failure occurs and immediately after.
+
+
+d) Availability of exported TSF data (FPT_ITA), Confidentiality of
+exported TSF data (FPT_ITC), Integrity of exported TSF data
+(FPT_ITI), which address the protection and availability of TSF data
+between the TSF and another trusted IT product.
+
+
+e) Internal TOE TSF data transfer (FPT_ITT), which addresses
+protection of TSF data when it is transmitted between physicallyseparated parts of the TOE.
+
+
+April 2017 Version 3.1 Page 285 of 323
+
+
+**Class FPT: Protection of the TSF**
+
+
+f) Replay detection (FPT_RPL), which addresses the replay of various
+types of information and/or operations.
+
+
+g) State synchrony protocol (FPT_SSP), which addresses the
+synchronisation of states, based upon TSF data, between different
+parts of a distributed TSF.
+
+
+h) Time stamps (FPT_STM), which addresses reliable timing.
+
+
+i) Inter-TSF TSF data consistency (FPT_TDC), which addresses the
+consistency of TSF data shared between the TSF and another trusted
+IT product.
+
+
+1177 Figure 28 shows the decomposition of this class into its constituent
+components.
+
+
+Page 286 of 323 Version 3.1 April 2017
+
+
+**Class FPT: Protection of the TSF**
+
+
+**Figure 28 - FPT: Protection of the TSF class decomposition**
+
+## **J.1 Fail secure (FPT_FLS)**
+
+
+User notes
+
+
+1178 The requirements of this family ensure that the TOE will always enforce its
+SFRs in the event of certain types of failures in the TSF.
+
+
+April 2017 Version 3.1 Page 287 of 323
+
+
+**Class FPT: Protection of the TSF**
+
+
+**FPT_FLS.1** **Failure with preservation of secure state**
+
+
+User application notes
+
+
+1179 The term โsecure stateโ refers to a state in which the TSF data are consistent
+and the TSF continues correct enforcement of the SFRs.
+
+
+1180 Although it is desirable to audit situations in which failure with preservation
+of secure state occurs, it is not possible in all situations. The PP/ST author
+should specify those situations in which audit is desired and feasible.
+
+
+1181 Failures in the TSF may include โhardโ failures, which indicate an
+equipment malfunction and which may require maintenance, service or
+repair of the TSF. Failures in the TSF may also include recoverable โsoftโ
+failures, which may only require initialisation or resetting of the TSF.
+
+
+Operations
+
+
+Assignment:
+
+
+1182 In **FPT_FLS.1.1**, the PP/ST author should list the types of failures in the
+TSF for which the TSF should โfail secure,โ that is, should preserve a
+secure state and continue to correctly enforce the SFRs.
+
+## **J.2 Availability of exported TSF data (FPT_ITA)**
+
+
+User notes
+
+
+1183 This family defines the rules for the prevention of loss of availability of TSF
+data moving between the TSF and another trusted IT product. This data
+could be TSF critical data such as passwords, keys, audit data, or TSF
+executable code.
+
+
+1184 This family is used in a distributed context where the TSF is providing TSF
+data to another trusted IT product. The TSF can only take the measures at its
+site and cannot be held responsible for the TSF at the other trusted IT
+product.
+
+
+1185 If there are different availability metrics for different types of TSF data, then
+this component should be iterated for each unique pairing of metrics and
+types of TSF data.
+
+
+**FPT_ITA.1** **Inter-TSF availability within a defined availability metric**
+
+
+Operations
+
+
+Assignment:
+
+
+1186 In **FPT_ITA.1.1**, the PP/ST author should specify the types of TSF data
+that are subject to the availability metric.
+
+
+Page 288 of 323 Version 3.1 April 2017
+
+
+**Class FPT: Protection of the TSF**
+
+
+1187 In **FPT_ITA.1.1**, the PP/ST should specify the availability metric for the
+applicable TSF data.
+
+
+1188 In **FPT_ITA.1.1**, the PP/ST author should specify the conditions under
+which availability must be ensured. For example: there must be a
+connection between the TOE and another trusted IT product.
+
+## **J.3 Confidentiality of exported TSF data (FPT_ITC)**
+
+
+User notes
+
+
+1189 This family defines the rules for the protection from unauthorised disclosure
+of TSF data moving between the TSF and another trusted IT product.
+Examples of this data are TSF critical data such as passwords, keys, audit
+data, or TSF executable code.
+
+
+1190 This family is used in a distributed context where the TSF is providing TSF
+data to another trusted IT product. The TSF can only take the measures at its
+site and cannot be held responsible for the behaviour of the other trusted IT
+product.
+
+
+**FPT_ITC.1** **Inter-TSF confidentiality during transmission**
+
+
+Evaluator notes
+
+
+1191 Confidentiality of TSF Data during transmission is necessary to protect such
+information from disclosure. Some possible implementations that could
+provide confidentiality include the use of cryptographic algorithms as well as
+spread spectrum techniques.
+
+## **J.4 Integrity of exported TSF data (FPT_ITI)**
+
+
+User notes
+
+
+1192 This family defines the rules for the protection, from unauthorised
+modification, of TSF data during transmission between the TSF and another
+trusted IT product. Examples of this data are TSF critical data such as
+passwords, keys, audit data, or TSF executable code.
+
+
+1193 This family is used in a distributed context where the TSF is exchanging TSF
+data with another trusted IT product. Note that a requirement that addresses
+modification, detection, or recovery at another trusted IT product cannot be
+specified, as the mechanisms that another trusted IT product will use to
+protect its data cannot be determined in advance. For this reason, these
+requirements are expressed in terms of the โTSF providing a capabilityโ
+which another trusted IT product can use.
+
+
+April 2017 Version 3.1 Page 289 of 323
+
+
+**Class FPT: Protection of the TSF**
+
+
+**FPT_ITI.1** **Inter-TSF detection of modification**
+
+
+User application notes
+
+
+1194 This component should be used in situations where it is sufficient to detect
+when data have been modified. An example of such a situation is one in
+which another trusted IT product can request the TOE's TSF to retransmit
+data when modification has been detected, or respond to such types of
+request.
+
+
+1195 The desired strength of modification detection is based upon a specified
+modification metric that is a function of the algorithm used, which may range
+from a weak checksum and parity mechanisms that may fail to detect
+multiple bit changes, to more complicated cryptographic checksum
+approaches.
+
+
+Operations
+
+
+Assignment:
+
+
+1196 In **FPT_ITI.1.1**, the PP/ST should specify the modification metric that
+the detection mechanism must satisfy. This modification metric shall
+specify the desired strength of the modification detection.
+
+
+1197 In **FPT_ITI.1.2**, the PP/ST should specify the actions to be taken if a
+modification of TSF data has been detected. An example of an action
+is: โignore the TSF data, and request the originating trusted product
+to send the TSF data againโ.
+
+
+**FPT_ITI.2** **Inter-TSF detection and correction of modification**
+
+
+User application notes
+
+
+1198 This component should be used in situations where it is necessary to detect
+or correct modifications of TSF critical data.
+
+
+1199 The desired strength of modification detection is based upon a specified
+modification metric that is a function of the algorithm used, which may range
+from a checksum and parity mechanisms that may fail to detect multiple bit
+changes, to more complicated cryptographic checksum approaches. The
+metric that needs to be defined can either refer to the attacks it will resist (e.g.
+only 1 in a 1000 random messages will be accepted), or to mechanisms that
+are well known in the public literature (e.g. the strength must be conformant
+to the strength offered by Secure Hash Algorithm).
+
+
+1200 The approach taken to correct modification might be done through some
+form of error correcting checksum.
+
+
+Evaluator notes
+
+
+1201 Some possible means of satisfying this requirement involves the use of
+cryptographic functions or some form of checksum.
+
+
+Page 290 of 323 Version 3.1 April 2017
+
+
+**Class FPT: Protection of the TSF**
+
+
+Operations
+
+
+Assignment:
+
+
+1202 In **FPT_ITI.2.1**, the PP/ST should specify the modification metric that
+the detection mechanism must satisfy. This modification metric shall
+specify the desired strength of the modification detection.
+
+
+1203 In **FPT_ITI.2.2**, the PP/ST should specify the actions to be taken if a
+modification of TSF data has been detected. An example of an action
+is: โignore the TSF data, and request the originating trusted product
+to send the TSF data againโ.
+
+
+1204 In **FPT_ITI.2.3**, the PP/ST author should define the types of
+modification from which the TSF should be capable of recovering.
+
+## **J.5 Internal TOE TSF data transfer (FPT_ITT)**
+
+
+User notes
+
+
+1205 This family provides requirements that address protection of TSF data when
+it is transferred between separate parts of a TOE across an internal channel.
+
+
+1206 The determination of the degree of separation (i.e., physical or logical) that
+would make application of this family useful depends on the intended
+environment of use. In a hostile environment, there may be risks arising from
+transfers between parts of the TOE separated by only a system bus or an
+inter-process communications channel. In more benign environments, the
+transfers may be across more traditional network media.
+
+
+Evaluator notes
+
+
+1207 One practical mechanism available to a TSF to provide this protection is
+cryptographically-based.
+
+
+**FPT_ITT.1** **Basic internal TSF data transfer protection**
+
+
+Operations
+
+
+Selection:
+
+
+1208 In **FPT_ITT.1.1**, the PP/ST author should specify the desired type of
+protection to be provided from the choices: disclosure, modification.
+
+
+**FPT_ITT.2** **TSF data transfer separation**
+
+
+User application notes
+
+
+1209 One of the ways to achieve separation of TSF data based on SFP-relevant
+attributes is through the use of separate logical or physical channels.
+
+
+April 2017 Version 3.1 Page 291 of 323
+
+
+**Class FPT: Protection of the TSF**
+
+
+Operations
+
+
+Selection:
+
+
+1210 In **FPT_ITT.2.1**, the PP/ST author should specify the desired type of
+protection to be provided from the choices: disclosure, modification.
+
+
+**FPT_ITT.3** **TSF data integrity monitoring**
+
+
+Operations
+
+
+Selection:
+
+
+1211 In **FPT_ITT.3.1**, the PP/ST author should specify the desired type of
+modification that the TSF shall be able to detect. The PP/ST author
+should select from: modification of data, substitution of data, reordering of data, deletion of data, or any other integrity errors.
+
+
+Assignment:
+
+
+1212 In **FPT_ITT.3.1**, if the PP/ST author chooses the latter selection noted in
+the preceding paragraph, then the author should also specify what
+those other integrity errors are that the TSF should be capable of
+detecting.
+
+
+1213 In **FPT_ITT.3.2**, the PP/ST author should specify the action to be taken
+when an integrity error is identified.
+
+## **J.6 TSF physical protection (FPT_PHP)**
+
+
+User notes
+
+
+1214 TSF physical protection components refer to restrictions on unauthorised
+physical access to the TSF, and to the deterrence of, and resistance to,
+unauthorised physical modification, or substitution of the TSF.
+
+
+1215 The requirements in this family ensure that the TSF is protected from
+physical tampering and interference. Satisfying the requirements of these
+components results in the TSF being packaged and used in such a manner
+that physical tampering is detectable, or resistance to physical tampering is
+measurable based on defined work factors. Without these components, the
+protection functions of a TSF lose their effectiveness in environments where
+physical damage cannot be prevented. This component also provides
+requirements regarding how the TSF must respond to physical tampering
+attempts.
+
+
+1216 Examples of physical tampering scenarios include mechanical attack,
+radiation, changing the temperature.
+
+
+1217 It is acceptable for the functions that are available to an authorised user for
+detecting physical tampering to be available only in an off-line or
+maintenance mode. Controls should be in place to limit access during such
+
+
+Page 292 of 323 Version 3.1 April 2017
+
+
+**Class FPT: Protection of the TSF**
+
+
+modes to authorised users. As the TSF may not be โoperationalโ during those
+modes, it may not be able to provide normal enforcement for authorised user
+access. The physical implementation of a TOE might consist of several
+structures: for example an outer shielding, cards, and chips. This set of
+โelementsโ as a whole must protect (protect, notify and resist) the TSF from
+physical tampering. This does not mean that all devices must provide these
+features, but the complete physical construct as a whole should.
+
+
+1218 Although there is only minimal auditing associating with these components,
+this is solely because there is the potential that the detection and alarm
+mechanisms may be implemented completely in hardware, below the level of
+interaction with an audit subsystem (for example, a hardware-based detection
+system based on breaking a circuit and lighting a light emitting diode (LED)
+if the circuit is broken when a button is pressed by the authorised user).
+Nevertheless, a PP/ST author may determine that for a particular anticipated
+threat environment, there is a need to audit physical tampering. If this is the
+case, the PP/ST author should include appropriate requirements in the list of
+audit events. Note that inclusion of these requirements may have
+implications on the hardware design and its interface to the software.
+
+
+**FPT_PHP.1** **Passive detection of physical attack**
+
+
+User application notes
+
+
+1219 FPT_PHP.1 Passive detection of physical attack should be used when threats
+from unauthorised physical tampering with parts of the TOE are not
+countered by procedural methods. It addresses the threat of undetected
+physical tampering with the TSF. Typically, an authorised user would be
+given the function to verify whether tampering took place. As written, this
+component simply provides a TSF capability to detect tampering.
+Specification of management functions in FMT_MOF.1 Management of
+security functions behaviour should be considered to specify who can make
+use of that capability, and how they can make use of that capability. If this is
+done by non-IT mechanisms (e.g. physical inspection) management
+functions are not required.
+
+
+**FPT_PHP.2** **Notification of physical attack**
+
+
+User application notes
+
+
+1220 FPT_PHP.2 Notification of physical attack should be used when threats from
+unauthorised physical tampering with parts of the TOE are not countered by
+procedural methods, and it is required that designated individuals be notified
+of physical tampering. It addresses the threat that physical tampering with
+TSF elements, although detected, may not be noticed. Specification of
+management functions in FMT_MOF.1 Management of security functions
+behaviour should be considered to specify who can make use of that
+capability, and how they can make use of that capability.
+
+
+April 2017 Version 3.1 Page 293 of 323
+
+
+**Class FPT: Protection of the TSF**
+
+
+Operations
+
+
+Assignment:
+
+
+1221 In **FPT_PHP.2.3**, the PP/ST author should provide a list of TSF
+devices/elements for which active detection of physical tampering is
+required.
+
+
+1222 In **FPT_PHP.2.3**, the PP/ST author should designate a user or role that is
+to be notified when tampering is detected. The type of user or role
+may vary depending on the particular security administration
+component (from the FMT_MOF.1 Management of security
+functions behaviour family) included in the PP/ST.
+
+
+**FPT_PHP.3** **Resistance to physical attack**
+
+
+User application notes
+
+
+1223 For some forms of tampering, it is necessary that the TSF not only detects
+the tampering, but actually resists it or delays the attacker.
+
+
+1224 This component should be used when TSF devices and TSF elements are
+expected to operate in an environment where a physical tampering (e.g.
+observation, analysis, or modification) of the internals of a TSF device or
+TSF element itself is a threat.
+
+
+Operations
+
+
+Assignment:
+
+
+1225 In **FPT_PHP.3.1**, the PP/ST author should specify tampering scenarios
+to a list of TSF devices/elements for which the TSF should resist
+physical tampering. This list may be applied to a defined subset of
+the TSF physical devices and elements based on considerations such
+as technology limitations and relative physical exposure of the device.
+Such subsetting should be clearly defined and justified. Furthermore,
+the TSF should automatically respond to physical tampering. The
+automatic response should be such that the policy of the device is
+preserved; for example, with a confidentiality policy, it would be
+acceptable to physically disable the device so that the protected
+information may not be retrieved.
+
+
+1226 In **FPT_PHP.3.1**, the PP/ST author should specify the list of TSF
+devices/elements for which the TSF should resist physical tampering
+in the scenarios that have been identified.
+
+## **J.7 Trusted recovery (FPT_RCV)**
+
+
+User notes
+
+
+1227 The requirements of this family ensure that the TSF can determine that the
+TOE is started-up without protection compromise and can recover without
+
+
+Page 294 of 323 Version 3.1 April 2017
+
+
+**Class FPT: Protection of the TSF**
+
+
+protection compromise after discontinuity of operations. This family is
+important because the start-up state of the TSF determines the protection of
+subsequent states.
+
+
+1228 Recovery components reconstruct the TSF secure states, or prevent
+transitions to insecure states, as a direct response to occurrences of expected
+failures, discontinuity of operation or start-up. Failures that must be
+generally anticipated include the following:
+
+
+a) Unmaskable action failures that always result in a system crash (e.g.
+persistent inconsistency of critical system tables, uncontrolled
+transfers within the TSF code caused by transient failures of
+hardware or firmware, power failures, processor failures,
+communication failures).
+
+
+b) Media failures causing part or all of the media representing the TSF
+objects to become inaccessible or corrupt (e.g. parity errors, disk head
+crash, persistent read/write failure caused by misaligned disk heads,
+worn-out magnetic coating, dust on the disk surface).
+
+
+c) Discontinuity of operation caused by erroneous administrative action
+or lack of timely administrative action (e.g. unexpected shutdowns by
+turning off power, ignoring the exhaustion of critical resources,
+inadequate installed configuration).
+
+
+1229 Note that recovery may be from either a complete or partial failure scenario.
+Although a complete failure might occur in a monolithic operating system, it
+is less likely to occur in a distributed environment. In such environments,
+subsystems may fail, but other portions remain operational. Further, critical
+components may be redundant (disk mirroring, alternative routes), and
+checkpoints may be available. Thus, recovery is expressed in terms of
+recovery to a secure state.
+
+
+1230 There are different interactions between Trusted recovery (FPT_RCV) and
+TSF self test (FPT_TST) components to be considered when selecting
+Trusted recovery (FPT_RCV):
+
+
+a) The need for trusted recovery may be indicated through the results of
+TSF self-testing, where the results of the self-tests indicate that the
+TSF is in an insecure state and return to a secure state or entrance in
+maintenance mode is required.
+
+
+b) A failure, as discussed above, may be identified by an administrator.
+Either the administrator may perform the actions to return the TOE to
+a secure state and then invoke TSF self-tests to confirm that the
+secure state has been achieved. Or, the TSF self-tests may be invoked
+to complete the recovery process.
+
+
+c) A combination of a. and b. above, where the need for trusted recovery
+is indicated through the results of TSF self-testing, the administrator
+performs the actions to return the TOE to a secure state and then
+
+
+April 2017 Version 3.1 Page 295 of 323
+
+
+**Class FPT: Protection of the TSF**
+
+
+invokes TSF self-tests to confirm that the secure state has been
+achieved.
+
+
+d) Self tests detect a failure/service discontinuity, then either automated
+recovery or entrance to a maintenance mode.
+
+
+1231 This family identifies a maintenance mode. In this maintenance mode normal
+operation might be impossible or severely restricted, as otherwise insecure
+situations might occur. Typically, only authorised users should be allowed
+access to this mode but the real details of who can access this mode is a
+function of FMT: Security management. If FMT: Security management does
+not put any controls on who can access this mode, then it may be acceptable
+to allow any user to restore the system if the TOE enters such a state.
+However, in practice, this is probably not desirable as the user restoring the
+system has an opportunity to configure the TOE in such a way as to violate
+the SFRs.
+
+
+1232 Mechanisms designed to detect exceptional conditions during operation fall
+under TSF self test (FPT_TST), Fail secure (FPT_FLS), and other areas that
+address the concept of โSoftware Safety.โ It is likely that the use of one of
+these families will be required to support the adoption of Trusted recovery
+(FPT_RCV). This is to ensure that the TOE will be able to detect when
+recovery is required.
+
+
+1233 Throughout this family, the phrase โsecure stateโ is used. This refers to some
+state in which the TOE has consistent TSF data and a TSF that can correctly
+enforce the policy. This state may be the initial โbootโ of a clean system, or it
+might be some checkpointed state.
+
+
+1234 Following recovery, it may be necessary to confirm that the secure state has
+been achieved through self-testing of the TSF. However, if the recovery is
+performed in a manner such that only a secure state can be achieved, else
+recovery fails, then the dependency to the FPT_TST.1 TSF testing TSF selftest component may be argued away.
+
+
+**FPT_RCV.1** **Manual recovery**
+
+
+User application notes
+
+
+1235 In the hierarchy of the trusted recovery family, recovery that requires only
+manual intervention is the least desirable, for it precludes the use of the
+system in an unattended fashion.
+
+
+1236 This component is intended for use in TOEs that do not require unattended
+recovery to a secure state. The requirements of this component reduce the
+threat of protection compromise resulting from an attended TOE returning to
+an insecure state after recovery from a failure or other discontinuity.
+
+
+Page 296 of 323 Version 3.1 April 2017
+
+
+**Class FPT: Protection of the TSF**
+
+
+Evaluator notes
+
+
+1237 It is acceptable for the functions that are available to an authorised user for
+trusted recovery to be available only in a maintenance mode. Controls should
+be in place to limit access during maintenance to authorised users.
+
+
+Operations
+
+
+Assignment:
+
+
+1238 In **FPT_RCV.1.1**, the PP/ST author should specify the list of failures or
+service discontinuities (e.g. power failure, audit storage exhaustion,
+any failure or discontinuity) following which the TOE will enter a
+maintenance mode.
+
+
+**FPT_RCV.2** **Automated recovery**
+
+
+User application notes
+
+
+1239 Automated recovery is considered to be more useful than manual recovery,
+as it allows the machine to operate in an unattended fashion.
+
+
+1240 The component FPT_RCV.2 Automated recovery extends the feature
+coverage of FPT_RCV.1 Manual recovery by requiring that there be at least
+one automated method of recovery from failure or service discontinuity. It
+addresses the threat of protection compromise resulting from an unattended
+TOE returning to an insecure state after recovery from a failure or other
+discontinuity.
+
+
+Evaluator notes
+
+
+1241 It is acceptable for the functions that are available to an authorised user for
+trusted recovery to be available only in a maintenance mode. Controls should
+be in place to limit access during maintenance to authorised users.
+
+
+1242 For **FPT_RCV.2.1**, it is the responsibility of the developer of the TSF to
+determine the set of recoverable failures and service discontinuities.
+
+
+1243 It is assumed that the robustness of the automated recovery mechanisms will
+be verified.
+
+
+Operations
+
+
+Assignment:
+
+
+1244 In **FPT_RCV.2.1**, the PP/ST author should specify the list of failures or
+service discontinuities (e.g. power failure, audit storage exhaustion)
+following which the TOE will need to enter a maintenance mode.
+
+
+1245 In **FPT_RCV.2.2**, the PP/ST author should specify the list of failures or
+other discontinuities for which automated recovery must be possible.
+
+
+April 2017 Version 3.1 Page 297 of 323
+
+
+**Class FPT: Protection of the TSF**
+
+
+**FPT_RCV.3** **Automated recovery without undue loss**
+
+
+User application notes
+
+
+1246 Automated recovery is considered to be more useful than manual recovery,
+but it runs the risk of losing a substantial number of objects. Preventing
+undue loss of objects provides additional utility to the recovery effort.
+
+
+1247 The component FPT_RCV.3 Automated recovery without undue loss
+extends the feature coverage of FPT_RCV.2 Automated recovery by
+requiring that there not be undue loss of TSF data or objects under the
+control of the TSF. At FPT_RCV.2 Automated recovery, the automated
+recovery mechanisms could conceivably recover by deleting all objects and
+returning the TSF to a known secure state. This type of drastic automated
+recovery is precluded in FPT_RCV.3 Automated recovery without undue
+loss.
+
+
+1248 This component addresses the threat of protection compromise resulting
+from an unattended TOE returning to an insecure state after recovery from a
+failure or other discontinuity with a large loss of TSF data or objects under
+the control of the TSF.
+
+
+Evaluator notes
+
+
+1249 It is acceptable for the functions that are available to an authorised user for
+trusted recovery to be available only in a maintenance mode. Controls should
+be in place to limit access during maintenance to authorised users.
+
+
+1250 It is assumed that the evaluators will verify the robustness of the automated
+recovery mechanisms.
+
+
+Operations
+
+
+Assignment:
+
+
+1251 In **FPT_RCV.3.1**, the PP/ST author should specify the list of failures or
+service discontinuities (e.g. power failure, audit storage exhaustion)
+following which the TOE will need to enter a maintenance mode.
+
+
+1252 In **FPT_RCV.3.2**, the PP/ST author should specify the list of failures or
+other discontinuities for which automated recovery must be possible.
+
+
+1253 In **FPT_RCV.3.3**, the PP/ST author should provide a quantification for
+the amount of loss of TSF data or objects that is acceptable.
+
+
+**FPT_RCV.4** **Function recovery**
+
+
+User application notes
+
+
+1254 Function recovery requires that if there should be some failure in the TSF,
+that certain functions in the TSF should either complete successfully or
+recover to a secure state.
+
+
+Page 298 of 323 Version 3.1 April 2017
+
+
+**Class FPT: Protection of the TSF**
+
+
+Operations
+
+
+Assignment:
+
+
+1255 In **FPT_RCV.4.1**, the PP/ST author should specify a list the functions
+and failure scenarios. In the event that any of the identified failure
+scenarios happen, the functions that have been specified must either
+complete successfully or recover to a consistent and secure state.
+
+## **J.8 Replay detection (FPT_RPL)**
+
+
+User notes
+
+
+1256 This family addresses detection of replay for various types of entities and
+subsequent actions to correct.
+
+
+**FPT_RPL.1** **Replay detection**
+
+
+User application notes
+
+
+1257 The entities included here are, for example, messages, service requests,
+service responses, or sessions.
+
+
+Operations
+
+
+Assignment:
+
+
+1258 In **FPT_RPL.1.1**, the PP/ST author should provide a list of identified
+entities for which detection of replay should be possible. Examples of
+such entities might include: messages, service requests, service
+responses, and user sessions.
+
+
+1259 In **FPT_RPL.1.2**, the PP/ST author should specify the list of actions to
+be taken by the TSF when replay is detected. The potential set of
+actions that can be taken includes: ignoring the replayed entity,
+requesting confirmation of the entity from the identified source, and
+terminating the subject from which the re-played entity originated.
+
+## **J.9 State synchrony protocol (FPT_SSP)**
+
+
+User notes
+
+
+1260 Distributed TOEs may give rise to greater complexity than monolithic TOEs
+through the potential for differences in state between parts of the TOE, and
+through delays in communication. In most cases, synchronisation of state
+between distributed functions involves an exchange protocol, not a simple
+action. When malice exists in the distributed environment of these protocols,
+more complex defensive protocols are required.
+
+
+1261 State synchrony protocol (FPT_SSP) establishes the requirement for certain
+critical functions of the TSF to use a trusted protocol. State synchrony
+
+
+April 2017 Version 3.1 Page 299 of 323
+
+
+**Class FPT: Protection of the TSF**
+
+
+protocol (FPT_SSP) ensures that two distributed parts of the TOE (e.g.
+hosts) have synchronised their states after a security-relevant action.
+
+
+1262 Some states may never be synchronised, or the transaction cost may be too
+high for practical use; encryption key revocation is an example, where
+knowing the state after the revocation action is initiated can never be known.
+Either the action was taken and acknowledgment cannot be sent, or the
+message was ignored by hostile communication partners and the revocation
+never occurred. Indeterminacy is unique to distributed TOEs. Indeterminacy
+and state synchrony are related, and the same solution may apply. It is futile
+to design for indeterminate states; the PP/ST author should express other
+requirements in such cases (e.g. raise an alarm, audit the event).
+
+
+**FPT_SSP.1** **Simple trusted acknowledgement**
+
+
+User application notes
+
+
+1263 In this component, the TSF must supply an acknowledgement to another part
+of the TSF when requested. This acknowledgement should indicate that one
+part of a distributed TOE successfully received an unmodified transmission
+from a different part of the distributed TOE.
+
+
+**FPT_SSP.2** **Mutual trusted acknowledgement**
+
+
+User application notes
+
+
+1264 In this component, in addition to the TSF being able to provide an
+acknowledgement for the receipt of a data transmission, the TSF must
+comply with a request from another part of the TSF for an acknowledgement
+to the acknowledgement.
+
+
+1265 For example, the local TSF transmits some data to a remote part of the TSF.
+The remote part of the TSF acknowledges the successful receipt of the data
+and requests that the sending TSF confirm that it receives the
+acknowledgement. This mechanism provides additional confidence that both
+parts of the TSF involved in the data transmission know that the transmission
+completed successfully.
+
+## **J.10 Time stamps (FPT_STM)**
+
+
+User notes
+
+
+1266 This family addresses requirements for a reliable time stamp function within
+a TOE.
+
+
+1267 It is the responsibility of the PP/ST author to clarify the meaning of the
+phrase โreliable time stampโ, and to indicate where the responsibility lies in
+determining the acceptance of trust.
+
+
+Page 300 of 323 Version 3.1 April 2017
+
+
+**Class FPT: Protection of the TSF**
+
+
+**FPT_STM.1** **Reliable time stamps**
+
+
+User application notes
+
+
+1268 Some possible uses of this component include providing reliable time stamps
+for the purposes of audit as well as for security attribute expiration.
+
+## **J.11 Inter-TSF TSF data consistency (FPT_TDC)**
+
+
+User notes
+
+
+1269 In a distributed or composite environment, a TOE may need to exchange
+TSF data (e.g. the SFP-attributes associated with data, audit information,
+identification information) with another trusted IT Product, This family
+defines the requirements for sharing and consistent interpretation of these
+attributes between the TSF of the TOE and that of a different trusted IT
+Product.
+
+
+1270 The components in this family are intended to provide requirements for
+automated support for TSF data consistency when such data is transmitted
+between the TSF of the TOE and another trusted IT Product. It is also
+possible that wholly procedural means could be used to produce security
+attribute consistency, but they are not provided for here.
+
+
+1271 This family is different from FDP_ETC and FDP_ITC, as those two families
+are concerned only with resolving the security attributes between the TSF
+and its import/export medium.
+
+
+1272 If the integrity of the TSF data is of concern, requirements should be chosen
+from the Integrity of exported TSF data (FPT_ITI) family. These
+components specify requirements for the TSF to be able to detect or detect
+and correct modifications to TSF data in transit.
+
+
+**FPT_TDC.1** **Inter-TSF basic TSF data consistency**
+
+
+User application notes
+
+
+1273 The TSF is responsible for maintaining the consistency of TSF data used by
+or associated with the specified function and that are common between two
+or more trusted systems. For example, the TSF data of two different systems
+may have different conventions internally. For the TSF data to be used
+properly (e.g. to afford the user data the same protection as within the TOE)
+by the receiving trusted IT product, the TOE and the other trusted IT product
+must use a pre-established protocol to exchange TSF data.
+
+
+Operations
+
+
+Assignment:
+
+
+1274 In **FPT_TDC.1.1**, the PP/ST author should define the list of TSF data
+types, for which the TSF shall provide the capability to consistently
+
+
+April 2017 Version 3.1 Page 301 of 323
+
+
+**Class FPT: Protection of the TSF**
+
+
+interpret, when shared between the TSF and another trusted IT
+product.
+
+
+1275 In **FPT_TDC.1.2**, the PP/ST should assign the list of interpretation rules
+to be applied by the TSF,
+
+## **J.12 Testing of external entities (FPT_TEE)**
+
+
+User notes
+
+
+1276 This family defines requirements for the testing of one or more external
+entities by the TSF. These external entities are not human users, and they can
+include combinations of software and/or hardware interacting with the TOE.
+
+
+1277 Examples of the types of tests that may be run are:
+
+
+a) Tests for the presence of a firewall, and possibly whether it is
+correctly configured;
+
+
+b) Tests of some of the properties of the operating system that an
+application TOE runs on;
+
+
+c) Tests of some of the properties of the IC that a smart card OS TOE
+runs on (e.g. the random number generator).
+
+
+1278 Note that the external entity may โlieโ about the test results, either on
+purpose or because it is not working correctly.
+
+
+1279 These tests can be carried out either in some maintenance state, at start-up,
+on-line, or continuously. The actions to be taken by the TOE as the result of
+testing are defined also in this family.
+
+
+Evaluator notes
+
+
+1280 The tests of external entities should be sufficient to test all of the
+characteristics of them upon which the TSF relies.
+
+
+**FPT_TEE.1** **Testing of external entities**
+
+
+User application notes
+
+
+1281 This component is not intended to be applied to human users.
+
+
+1282 This component provides support for the periodic testing of properties
+related to external entities upon which the TSF's operation depends, by
+requiring the ability to periodically invoke testing functions.
+
+
+1283 The PP/ST author may refine the requirement to state whether the function
+should be available in off-line, on-line or maintenance mode.
+
+
+Page 302 of 323 Version 3.1 April 2017
+
+
+**Class FPT: Protection of the TSF**
+
+
+Evaluator notes
+
+
+1284 It is acceptable for the functions for periodic testing to be available only in
+an off-line or maintenance mode. Controls should be in place to limit access,
+during maintenance, to authorised users.
+
+
+Operations
+
+
+Selection:
+
+
+1285 In **FPT_TEE.1.1**, the PP/ST author should specify when the TSF will
+run the testing of external entities, during initial start-up, periodically
+during normal operation, at the request of an authorised user, or under
+other conditions. If the tests are run often, then the end users should
+have more confidence that the TOE is operating correctly than if the
+tests are run less frequently. However, this need for confidence that
+the TOE is operating correctly must be balanced with the potential
+impact on the availability of the TOE, as often times, the testing of
+external entities may delay the normal operation of a TOE.
+
+
+Assignment:
+
+
+1286 In **FPT_TEE.1.1**, the PP/ST author should specify the properties of the
+external entities to be checked by the tests. Examples of these
+properties may include configuration or availability properties of a
+directory server supporting some access control part of the TSF.
+
+
+1287 In **FPT_TEE.1.1**, the PP/ST author should, if other conditions are
+selected, specify the frequency with which the testing of external
+entities will be run. An example of this other frecuency or condition
+may be to run the tests each time a user requests to initiate a session
+with the TOE. For instance, this could be the case of testing a
+directory server before its interaction with the TSF during the user
+authentication process.
+
+
+1288 In **FPT_TEE.1.2**, the PP/ST author should specify what are the action(s)
+that the TSF shall perform when the testing fails. Examples of these
+action(s), illustrated by a directory server instance, may include to
+connect to an alternative available server or otherwise to look for a
+backup server.
+
+## **J.13 Internal TOE TSF data replication consistency** **(FPT_TRC)**
+
+
+User notes
+
+
+1289 The requirements of this family are needed to ensure the consistency of TSF
+data when such data is replicated internal to the TOE. Such data may become
+inconsistent if an internal channel between parts of the TOE becomes
+inoperative. If the TOE is internally structured as a network of parts of the
+
+
+April 2017 Version 3.1 Page 303 of 323
+
+
+**Class FPT: Protection of the TSF**
+
+
+TOE, this can occur when parts become disabled, network connections are
+broken, and so on.
+
+
+1290 The method of ensuring consistency is not specified in this component. It
+could be attained through a form of transaction logging (where appropriate
+transactions are โrolled backโ to a site upon reconnection); it could be
+updating the replicated data through a synchronisation protocol. If a
+particular protocol is necessary for a PP/ST, it can be specified through
+refinement.
+
+
+1291 It may be impossible to synchronise some states, or the cost of such
+synchronisation may be too high. Examples of this situation are
+communication channel and encryption key revocations. Indeterminate states
+may also occur; if a specific behaviour is desired, it should be specified via
+refinement.
+
+
+**FPT_TRC.1** **Internal TSF consistency**
+
+
+Operations
+
+
+Assignment:
+
+
+1292 In **FPT_TRC.1.2**, the PP/ST author should specify the list of functions
+dependent on TSF data replication consistency.
+
+## **J.14 TSF self test (FPT_TST)**
+
+
+User notes
+
+
+1293 The family defines the requirements for the self-testing of the TSF with
+respect to some expected correct operation. Examples are interfaces to
+enforcement functions, and sample arithmetical operations on critical parts of
+the TOE. These tests can be carried out at start-up, periodically, at the
+request of an authorised user, or when other conditions are met. The actions
+to be taken by the TOE as the result of self testing are defined in other
+families.
+
+
+1294 The requirements of this family are also needed to detect the corruption of
+TSF data and TSF itself (i.e. TSF executable code or TSF hardware
+component) by various failures that do not necessarily stop the TOE's
+operation (which would be handled by other families). These checks must be
+performed because these failures may not necessarily be prevented. Such
+failures can occur either because of unforeseen failure modes or associated
+oversights in the design of hardware, firmware, or software, or because of
+malicious corruption of the TSF due to inadequate logical and/or physical
+protection.
+
+
+1295 In addition, use of this component may, with appropriate conditions, help to
+prevent inappropriate or damaging TSF changes being applied to an
+operational TOE as the result of maintenance activities.
+
+
+Page 304 of 323 Version 3.1 April 2017
+
+
+**Class FPT: Protection of the TSF**
+
+
+1296 The term โcorrect operation of the TSFโ refers primarily to the operation of
+the TSF and the integrity of the TSF data.
+
+
+**FPT_TST.1** **TSF testing**
+
+
+User application notes
+
+
+1297 This component provides support for the testing of the critical functions of
+the TSF's operation by requiring the ability to invoke testing functions and
+check the integrity of TSF data and executable code.
+
+
+Evaluator notes
+
+
+1298 It is acceptable for the functions that are available to the authorised user for
+periodic testing to be available only in an off-line or maintenance mode.
+Controls should be in place to limit access during these modes to authorised
+users.
+
+
+Operations
+
+
+Selection:
+
+
+1299 In **FPT_TST.1.1**, the PP/ST author should specify when the TSF will
+execute the TSF test; during initial start-up, periodically during
+normal operation, at the request of an authorised user, at other
+conditions. In the case of the latter option, the PP/ST author should
+also assign what those conditions are via the following assignment.
+
+
+1300 In **FPT_TST.1.1**, the PP/ST author should specify whether the self tests
+are to be carried out to demonstrate the correct operation of the entire
+TSF, or of only specified parts of TSF.
+
+
+Assignment:
+
+
+1301 In **FPT_TST.1.1**, the PP/ST author should, if selected, specify the
+conditions under which the self test should take place.
+
+
+1302 In **FPT_TST.1.1**, the PP/ST author should, if selected, specify the list of
+parts of the TSF that will be subject to TSF self-testing.
+
+
+Selection:
+
+
+1303 In **FPT_TST.1.2**, the PP/ST author should specify whether data integrity
+is to be verified for all TSF data, or only for selected data.
+
+
+Assignment:
+
+
+1304 In **FPT_TST.1.2**, the PP/ST author should, if selected, specify the list of
+TSF data that will be verified for integrity.
+
+
+April 2017 Version 3.1 Page 305 of 323
+
+
+**Class FPT: Protection of the TSF**
+
+
+Selection:
+
+
+1305 In **FPT_TST.1.3**, the PP/ST author should specify whether TSF integrity
+is to be verified for all TSF, or only for selected TSF.
+
+
+Assignment:
+
+
+1306 In **FPT_TST.1.3**, the PP/ST author should, if selected, specify the list of
+TSF that will be verified for integrity.
+
+
+Page 306 of 323 Version 3.1 April 2017
+
+
+**Class FRU: Resource utilisation**
+
+# **K Class FRU: Resource utilisation** **(normative)**
+
+
+1307 This class provides three families that support the availability of required
+resources such as processing capability and/or storage capacity. The family
+Fault Tolerance provides protection against unavailability of capabilities
+caused by failure of the TOE. The family Priority of Service ensures that the
+resources will be allocated to the more important or time-critical tasks, and
+cannot be monopolised by lower priority tasks. The family Resource
+Allocation provides limits on the use of available resources, therefore
+preventing users from monopolising the resources.
+
+
+1308 Figure 29 shows the decomposition of this class into its constituent
+components.
+
+
+**Figure 29 - FRU: Resource utilisation class decomposition**
+
+## **K.1 Fault tolerance (FRU_FLT)**
+
+
+User notes
+
+
+1309 This family provides requirements for the availability of capabilities even in
+the case of failures. Examples of such failures are power failure, hardware
+failure, or software error. In case of these errors, if so specified, the TOE will
+maintain the specified capabilities. The PP/ST author could specify, for
+example, that a TOE used in a nuclear plant will continue the operation of
+the shut-down procedure in the case of power-failure or communicationfailure.
+
+
+1310 Because the TOE can only continue its correct operation if the SFRs are
+enforced, there is a requirement that the system must remain in a secure state
+after a failure. This capability is provided by FPT_FLS.1 Failure with
+preservation of secure state.
+
+
+1311 The mechanisms to provide fault tolerance could be active or passive. In case
+of an active mechanism, specific functions are in place that are activated in
+case the error occurs. For example, a fire alarm is an active mechanism: the
+TSF will detect the fire and can take action such as switching operation to a
+backup. In a passive scheme, the architecture of the TOE is capable of
+
+
+April 2017 Version 3.1 Page 307 of 323
+
+
+**Class FRU: Resource utilisation**
+
+
+handling the error. For example, the use of a majority voting scheme with
+multiple processors is a passive solution; failure of one processor will not
+disrupt the operation of the TOE (although it needs to be detected to allow
+correction).
+
+
+1312 For this family, it does not matter whether the failure has been initiated
+accidentally (such as flooding or unplugging the wrong device) or
+intentionally (such as monopolising).
+
+
+**FRU_FLT.1** **Degraded fault tolerance**
+
+
+User application notes
+
+
+1313 This component is intended to specify which capabilities the TOE will still
+provide after a failure of the system. Since it would be difficult to describe
+all specific failures, categories of failures may be specified. Examples of
+general failures are flooding of the computer room, short term power
+interruption, breakdown of a CPU or host, software failure, or buffer
+overflow.
+
+
+Operations
+
+
+Assignment:
+
+
+1314 In **FRU_FLT.1.1**, the PP/ST author should specify the list of TOE
+capabilities the TOE will maintain during and after a specified failure.
+
+
+1315 In **FRU_FLT.1.1**, the PP/ST author should specify the list of type of
+failures against which the TOE has to be explicitly protected. If a
+failure in this list occurs, the TOE will be able to continue its
+operation.
+
+
+**FRU_FLT.2** **Limited fault tolerance**
+
+
+User application notes
+
+
+1316 This component is intended to specify against what type of failures the TOE
+must be resistant. Since it would be difficult to describe all specific failures,
+categories of failures may be specified. Examples of general failures are
+flooding of the computer room, short term power interruption, breakdown of
+a CPU or host, software failure, or overflow of buffer.
+
+
+Operations
+
+
+Assignment:
+
+
+1317 In **FRU_FLT.2.1**, the PP/ST author should specify the list of type of
+failures against which the TOE has to be explicitly protected. If a
+failure in this list occurs, the TOE will be able to continue its
+operation.
+
+
+Page 308 of 323 Version 3.1 April 2017
+
+
+**Class FRU: Resource utilisation**
+
+## **K.2 Priority of service (FRU_PRS)**
+
+
+User notes
+
+
+1318 The requirements of this family allow the TSF to control the use of resources
+under the control of the TSF by users and subjects such that high priority
+activities under the control of the TSF will always be accomplished without
+interference or delay due to low priority activities. In other words, time
+critical tasks will not be delayed by tasks that are less time critical.
+
+
+1319 This family could be applicable to several types of resources, for example,
+processing capacity, and communication channel capacity.
+
+
+1320 The Priority of Service mechanism might be passive or active. In a passive
+Priority of Service system, the system will select the task with the highest
+priority when given a choice between two waiting applications. While using
+passive Priority of Service mechanisms, when a low priority task is running,
+it cannot be interrupted by a high priority task. While using an active Priority
+of Service mechanisms, lower priority tasks might be interrupted by new
+high priority tasks.
+
+
+1321 The audit requirement states that all reasons for rejection should be audited.
+It is left to the developer to argue that an operation is not rejected but delayed.
+
+
+**FRU_PRS.1** **Limited priority of service**
+
+
+User application notes
+
+
+1322 This component defines priorities for a subject, and the resources for which
+this priority will be used. If a subject attempts to take action on a resource
+controlled by the Priority of Service requirements, the access and/or time of
+access will be dependent on the subject's priority, the priority of the currently
+acting subject, and the priority of the subjects still in the queue.
+
+
+Operations
+
+
+Assignment:
+
+
+1323 In **FRU_PRS.1.2**, the PP/ST author should specify the list of controlled
+resources for which the TSF enforces priority of service (e.g.
+resources such as processes, disk space, memory, bandwidth).
+
+
+**FRU_PRS.2** **Full priority of service**
+
+
+User application notes
+
+
+1324 This component defines priorities for a subject. All shareable resources under
+the control of the TSF will be subjected to the Priority of Service mechanism.
+If a subject attempts to take action on a shareable TSF resource, the access
+and/or time of access will be dependent on the subject's priority, the priority
+of the currently acting subject, and the priority of the subjects still in the
+queue.
+
+
+April 2017 Version 3.1 Page 309 of 323
+
+
+**Class FRU: Resource utilisation**
+
+## **K.3 Resource allocation (FRU_RSA)**
+
+
+User notes
+
+
+1325 The requirements of this family allow the TSF to control the use of resources
+under the control of the TSF by users and subjects such that unauthorised
+denial of service will not take place by means of monopolisation of resources
+by other users or subjects.
+
+
+1326 Resource allocation rules allow the creation of quotas or other means of
+defining limits on the amount of resource space or time that may be allocated
+on behalf of a specific user or subjects. These rules may, for example:
+
+
+๏ญ Provide for object quotas that constrain the number and/or size of
+objects a specific user may allocate.
+
+
+๏ญ Control the allocation/deallocation of preassigned resource units
+where these units are under the control of the TSF.
+
+
+1327 In general, these functions will be implemented through the use of attributes
+assigned to users and resources.
+
+
+1328 The objective of these components is to ensure a certain amount of fairness
+among the users (e.g. a single user should not allocate all the available space)
+and subjects. Since resource allocation often goes beyond the lifespan of a
+subject (i.e. files often exist longer than the applications that generated them),
+and multiple instantiations of subjects by the same user should not negatively
+affect other users too much, the components allow that the allocation limits
+are related to the users. In some situations the resources are allocated by a
+subject (e.g. main memory or CPU cycles). In those instances the
+components allow that the resource allocation be on the level of subjects.
+
+
+1329 This family imposes requirements on resource allocation, not on the use of
+the resource itself. The audit requirements therefore, as stated, also apply to
+the allocation of the resource, not to the use of the resource.
+
+
+**FRU_RSA.1** **Maximum quotas**
+
+
+User application notes
+
+
+1330 This component provides requirements for quota mechanisms that apply to
+only a specified set of the shareable resources in the TOE. The requirements
+allow the quotas to be associated with a user, possibly assigned to groups of
+users or subjects as applicable to the TOE.
+
+
+Operations
+
+
+Assignment:
+
+
+1331 In **FRU_RSA.1.1**, the PP/ST author should specify the list of controlled
+resources for which maximum resource allocation limits are required
+(e.g. processes, disk space, memory, bandwidth). If all resources
+
+
+Page 310 of 323 Version 3.1 April 2017
+
+
+**Class FRU: Resource utilisation**
+
+
+under the control of the TSF need to be included, the words โall TSF
+resourcesโ can be specified.
+
+
+Selection:
+
+
+1332 In **FRU_RSA.1.1**, the PP/ST author should select whether the maximum
+quotas apply to individual users, to a defined group of users, or
+subjects or any combination of these.
+
+
+1333 In **FRU_RSA.1.1**, the PP/ST author should select whether the maximum
+quotas are applicable to any given time (simultaneously), or over a
+specific time interval.
+
+
+**FRU_RSA.2** **Minimum and maximum quotas**
+
+
+User application notes
+
+
+1334 This component provides requirements for quota mechanisms that apply to a
+specified set of the shareable resources in the TOE. The requirements allow
+the quotas to be associated with a user, or possibly assigned to groups of
+users as applicable to the TOE.
+
+
+Operations
+
+
+Assignment:
+
+
+1335 In **FRU_RSA.2.1**, the PP/ST author should specify the controlled
+resources for which maximum and minimum resource allocation
+limits are required (e.g. processes, disk space, memory, bandwidth).
+If all resources under the control of the TSF need to be included, the
+words โall TSF resourcesโ can be specified.
+
+
+Selection:
+
+
+1336 In **FRU_RSA.2.1**, the PP/ST author should select whether the maximum
+quotas apply to individual users, to a defined group of users, or
+subjects or any combination of these.
+
+
+1337 In **FRU_RSA.2.1**, the PP/ST author should select whether the maximum
+quotas are applicable to any given time (simultaneously), or over a
+specific time interval.
+
+
+Assignment:
+
+
+1338 In **FRU_RSA.2.2**, the PP/ST author should specify the controlled
+resources for which a minimum allocation limit needs to be set (e.g.
+processes, disk space, memory, bandwidth). If all resources under the
+control of the TSF need to be included the words โall TSF resourcesโ
+can be specified.
+
+
+April 2017 Version 3.1 Page 311 of 323
+
+
+**Class FRU: Resource utilisation**
+
+
+Selection:
+
+
+1339 In **FRU_RSA.2.2**, the PP/ST author should select whether the minimum
+quotas apply to individual users, to a defined group of users, or
+subjects or any combination of these.
+
+
+1340 In **FRU_RSA.2.2**, the PP/ST author should select whether the minimum
+quotas are applicable to any given time (simultaneously), or over a
+specific time interval.
+
+
+Page 312 of 323 Version 3.1 April 2017
+
+
+**Class FTA: TOE access**
+
+# **L Class FTA: TOE access** **(normative)**
+
+
+1341 The establishment of a user's session typically consists of the creation of one
+or more subjects that perform operations in the TOE on behalf of the user. At
+the end of the session establishment procedure, provided the TOE access
+requirements are satisfied, the created subjects bear the attributes determined
+by the identification and authentication functions. This family specifies
+functional requirements for controlling the establishment of a user's session.
+
+
+1342 A user session is defined as the period starting at the time of the
+identification/authentication, or if more appropriate, the start of an
+interaction between the user and the system, up to the moment that all
+subjects (resources and attributes) related to that session have been
+deallocated.
+
+
+1343 Figure 30 shows the decomposition of this class into its constituent
+components.
+
+
+**Figure 30 - FTA: TOE access class decomposition**
+
+
+April 2017 Version 3.1 Page 313 of 323
+
+
+**Class FTA: TOE access**
+
+## **L.1 Limitation on scope of selectable attributes (FTA_LSA)**
+
+
+User notes
+
+
+1344 This family defines requirements that will limit the session security attributes
+a user may select, and the subjects to which a user may be bound, based on:
+the method of access; the location or port of access; and/or the time (e.g.
+time-of-day, day-of-week).
+
+
+1345 This family provides the capability for a PP/ST author to specify
+requirements for the TSF to place limits on the domain of an authorised
+user's security attributes based on an environmental condition. For example,
+a user may be allowed to establish a โsecret sessionโ during normal business
+hours but outside those hours the same user may be constrained to only
+establishing โunclassified sessionsโ. The identification of relevant constraints
+on the domain of selectable attributes can be achieved through the use of the
+selection operation. These constraints can be applied on an attribute-byattribute basis. When there exists a need to specify constraints on multiple
+attributes this component will have to be replicated for each attribute.
+Examples of attributes that could be used to limit the session security
+attributes are:
+
+
+a) The method of access can be used to specify in which type of
+environment the user will be operating (e.g. file transfer protocol,
+terminal, vtam).
+
+
+b) The location of access can be used to constrain the domain of a user's
+selectable attributes based on a user's location or port of access. This
+capability is of particular use in environments where dial-up facilities
+or network facilities are available.
+
+
+c) The time of access can be used to constrain the domain of a user's
+selectable attributes. For example, ranges may be based upon time-ofday, day-of-week, or calendar dates. This constraint provides some
+operational protection against user actions that could occur at a time
+where proper monitoring or where proper procedural measures may
+not be in place.
+
+
+**FTA_LSA.1** **Limitation on scope of selectable attributes**
+
+
+Operations
+
+
+Assignment:
+
+
+1346 In **FTA_LSA.1.1**, the PP/ST author should specify the set of session
+security attributes that are to be constrained. Examples of these
+session security attributes are user clearance level, integrity level and
+roles.
+
+
+1347 In **FTA_LSA.1.1**, the PP/ST author should specify the set of attributes
+that can be use to determine the scope of the session security
+
+
+Page 314 of 323 Version 3.1 April 2017
+
+
+**Class FTA: TOE access**
+
+
+attributes. Examples of such attributes are user identity, originating
+location, time of access, and method of access.
+
+## **L.2 Limitation on multiple concurrent sessions (FTA_MCS)**
+
+
+User notes
+
+
+1348 This family defines how many sessions a user may have at the same time
+(concurrent sessions). This number of concurrent sessions can either be set
+for a group of users or for each individual user.
+
+
+**FTA_MCS.1** **Basic limitation on multiple concurrent sessions**
+
+
+User application notes
+
+
+1349 This component allows the system to limit the number of sessions in order to
+effectively use the resources of the TOE.
+
+
+Operations
+
+
+Assignment:
+
+
+1350 In **FTA_MCS.1.2**, the PP/ST author should specify the default number
+of maximum concurrent sessions to be used.
+
+
+**FTA_MCS.2** **Per user attribute limitation on multiple concurrent sessions**
+
+
+User application notes
+
+
+1351 This component provides additional capabilities over those of FTA_MCS.1
+Basic limitation on multiple concurrent sessions, by allowing further
+constraints to be placed on the number of concurrent sessions that users are
+able to invoke. These constraints are in terms of a user's security attributes,
+such as a user's identity, or membership of a role.
+
+
+Operations
+
+
+Assignment:
+
+
+1352 In **FTA_MCS.2.1**, the PP/ST author should specify the rules that
+determine the maximum number of concurrent sessions. An example
+of a rule is โmaximum number of concurrent sessions is one if the
+user has a classification level of โsecretโ and five otherwiseโ.
+
+
+1353 In **FTA_MCS.2.2**, the PP/ST author should specify the default number
+of maximum concurrent sessions to be used.
+
+
+April 2017 Version 3.1 Page 315 of 323
+
+
+**Class FTA: TOE access**
+
+## **L.3 Session locking and termination (FTA_SSL)**
+
+
+User notes
+
+
+1354 This family defines requirements for the TSF to provide the capability for
+TSF-initiated and user-initiated locking, unlocking, and termination of
+interactive sessions.
+
+
+1355 When a user is directly interacting with subjects in the TOE (interactive
+session), the user's terminal is vulnerable if left unattended. This family
+provides requirements for the TSF to disable (lock) the terminal or terminate
+the session after a specified period of inactivity, and for the user to initiate
+the disabling (locking) of the terminal or terminate the session. To reactivate
+the terminal, an event specified by the PP/ST author, such as the user reauthentication must occur.
+
+
+1356 A user is considered inactive, if he/she has not provided any stimulus to the
+TOE for a specified period of time.
+
+
+1357 A PP/ST author should consider whether FTP_TRP.1 Trusted path should be
+included. In that case, the function โsession lockingโ should be included in
+the operation in FTP_TRP.1 Trusted path.
+
+
+**FTA_SSL.1** **TSF-initiated session locking**
+
+
+User application notes
+
+
+1358 FTA_SSL.1 TSF-initiated session locking, provides the capability for the
+TSF to lock an active user session after a specified period of time. Locking a
+terminal would prevent any further interaction with an existing active session
+through the use of the locked terminal.
+
+
+1359 If display devices are overwritten, the replacement contents need not be
+static (i.e. โscreen saversโ are permitted).
+
+
+1360 This component allows the PP/ST author to specify what events will unlock
+the session. These events may be related to the terminal (e.g. fixed set of
+keystrokes to unlock the session), the user (e.g. reauthentication), or time.
+
+
+Operations
+
+
+Assignment:
+
+
+1361 In **FTA_SSL.1.1**, the PP/ST author should specify the interval of user
+inactivity that will trigger the locking of an interactive session. If so
+desired the PP/ST author could, through the assignment, specify that
+the time interval is left to the authorised administrator or the user.
+The management functions in the FMT class can specify the
+capability to modify this time interval, making it the default value.
+
+
+1362 In **FTA_SSL.1.2**, the PP/ST author should specify the event(s) that
+should occur before the session is unlocked. Examples of such an
+
+
+Page 316 of 323 Version 3.1 April 2017
+
+
+**Class FTA: TOE access**
+
+
+event are: โuser re-authenticationโ or โuser enters unlock keysequenceโ.
+
+
+**FTA_SSL.2** **User-initiated locking**
+
+
+User application notes
+
+
+1363 FTA_SSL.2 User-initiated locking, provides the capability for an authorised
+user to lock and unlock his/her own interactive session. This would provide
+authorised users with the ability to effectively block further use of their
+active sessions without having to terminate the active session.
+
+
+1364 If devices are overwritten, the replacement contents need not be static (i.e.
+โscreen saversโ are permitted).
+
+
+Operations
+
+
+Assignment:
+
+
+1365 In **FTA_SSL.2.2**, the PP/ST author should specify the event(s) that
+should occur before the session is unlocked. Examples of such an
+event are: โuser re-authenticationโ, or โuser enters unlock keysequenceโ.
+
+
+**FTA_SSL.3** **TSF-initiated termination**
+
+
+User application notes
+
+
+1366 FTA_SSL.3 TSF-initiated termination, requires that the TSF terminate an
+interactive user session after a period of inactivity.
+
+
+1367 The PP/ST author should be aware that a session may continue after the user
+terminated his/her activity, for example, background processing. This
+requirement would terminate this background subject after a period of
+inactivity of the user without regard to the status of the subject.
+
+
+Operations
+
+
+Assignment:
+
+
+1368 In **FTA_SSL.3.1**, the PP/ST author should specify the interval of user
+inactivity that will trigger the termination of an interactive session. If
+so desired, the PP/ST author could, through the assignment, specify
+that the interval is left to the authorised administrator or the user. The
+management functions in the FMT class can specify the capability to
+modify this time interval, making it the default value.
+
+
+April 2017 Version 3.1 Page 317 of 323
+
+
+**Class FTA: TOE access**
+
+
+**FTA_SSL.4** **User-initiated termination**
+
+
+User application notes
+
+
+1369 FTA_SSL.4 User-initiated termination, provides the capability for an
+authorised user to terminate his/her interactive session..
+
+
+1370 The PP/ST author should be aware that a session may continue after the user
+terminated his/her activity, for example, background processing. This
+requirement would allow the user to terminate this background subject
+without regard to the status of the subject.
+
+## **L.4 TOE access banners (FTA_TAB)**
+
+
+User notes
+
+
+1371 Prior to identification and authentication, TOE access requirements provide
+the ability for the TOE to display an advisory warning message to potential
+users pertaining to appropriate use of the TOE.
+
+
+**FTA_TAB.1** **Default TOE access banners**
+
+
+User application notes
+
+
+1372 This component requires that there is an advisory warning regarding the
+unauthorised use of the TOE. A PP/ST author could refine the requirement to
+include a default banner.
+
+## **L.5 TOE access history (FTA_TAH)**
+
+
+User notes
+
+
+1373 This family defines requirements for the TSF to display to users, upon
+successful session establishment to the TOE, a history of unsuccessful
+attempts to access the account. This history may include the date, time,
+means of access, and port of the last successful access to the TOE, as well as
+the number of unsuccessful attempts to access the TOE since the last
+successful access by the identified user.
+
+
+**FTA_TAH.1** **TOE access history**
+
+
+User application notes
+
+
+1374 This family can provide authorised users with information that may indicate
+the possible misuse of their user account.
+
+
+1375 This component request that the user is presented with the information. The
+user should be able to review the information, but is not forced to do so. If a
+user so desires he might, for example, create scripts that ignore this
+information and start other processes.
+
+
+Page 318 of 323 Version 3.1 April 2017
+
+
+**Class FTA: TOE access**
+
+
+Operations
+
+
+Selection:
+
+
+1376 In **FTA_TAH.1.1**, the PP/ST author should select the security attributes
+of the last successful session establishment that will be shown at the
+user interface. The items are: date, time, method of access (such as
+ftp), and/or location (e.g. terminal 50).
+
+
+1377 In **FTA_TAH.1.2**, the PP/ST author should select the security attributes
+of the last unsuccessful session establishment that will be shown at
+the user interface. The items are: date, time, method of access (such
+as ftp), and/or location (e.g. terminal 50).
+
+## **L.6 TOE session establishment (FTA_TSE)**
+
+
+User notes
+
+
+1378 This family defines requirements to deny an user permission to establish a
+session with the TOE based on attributes such as the location or port of
+access, the user's security attribute (e.g. identity, clearance level, integrity
+level, membership in a role), ranges of time (e.g. time-of-day, day-of-week,
+calendar dates) or combinations of parameters.
+
+
+1379 This family provides the capability for the PP/ST author to specify
+requirements for the TOE to place constraints on the ability of an authorised
+user to establish a session with the TOE. The identification of relevant
+constraints can be achieved through the use of the selection operation.
+Examples of attributes that could be used to specify the session
+establishment constraints are:
+
+
+a) The location of access can be used to constrain the ability of a user to
+establish an active session with the TOE, based on the user's location
+or port of access. This capability is of particular use in environments
+where dial-up facilities or network facilities are available.
+
+
+b) The user's security attributes can be used to place constraints on the
+ability of a user to establish an active session with the TOE. For
+example, these attributes would provide the capability to deny session
+establishment based on any of the following:
+
+
+๏ญ a user's identity;
+
+
+๏ญ a user's clearance level;
+
+
+๏ญ a user's integrity level; and
+
+
+๏ญ a user's membership in a role.
+
+
+April 2017 Version 3.1 Page 319 of 323
+
+
+**Class FTA: TOE access**
+
+
+1380 This capability is particularly relevant in situations where authorisation or
+login may take place at a different location from where TOE access checks
+are performed.
+
+
+a) The time of access can be used to constrain the ability of a user to
+establish an active session with the TOE based on ranges of time. For
+example, ranges may be based upon time-of-day, day-of-week, or
+calendar dates. This constraint provides some operational protection
+against actions that could occur at a time where proper monitoring or
+where proper procedural measures may not be in place.
+
+
+**FTA_TSE.1** **TOE session establishment**
+
+
+Operations
+
+
+Assignment:
+
+
+1381 In **FTA_TSE.1.1**, the PP/ST author should specify the attributes that can
+be used to restrict the session establishment. Example of possible
+attributes are user identity, originating location (e.g. no remote
+terminals), time of access (e.g. outside hours), or method of access
+(e.g. X-windows).
+
+
+Page 320 of 323 Version 3.1 April 2017
+
+
+**Class FTP: Trusted path/channels**
+
+# **M Class FTP: Trusted path/channels** **(normative)**
+
+
+1382 Users often need to perform functions through direct interaction with the
+TSF. A trusted path provides confidence that a user is communicating
+directly with the TSF whenever it is invoked. A user's response via the
+trusted path guarantees that untrusted applications cannot intercept or modify
+the user's response. Similarly, trusted channels are one approach for secure
+communication between the TSF and another trusted IT product.
+
+
+1383 Absence of a trusted path may allow breaches of accountability or access
+control in environments where untrusted applications are used. These
+applications can intercept user-private information, such as passwords, and
+use it to impersonate other users. As a consequence, responsibility for any
+system actions cannot be reliably assigned to an accountable entity. Also,
+these applications could output erroneous information on an unsuspecting
+user's display, resulting in subsequent user actions that may be erroneous and
+may lead to a security breach.
+
+
+1384 Figure 31 shows the decomposition of this class into its constituent
+components.
+
+
+**Figure 31 - FTP: Trusted path/channels class decomposition**
+
+## **M.1 Inter-TSF trusted channel (FTP_ITC)**
+
+
+User notes
+
+
+1385 This family defines the rules for the creation of a trusted channel connection
+that goes between the TSF and another trusted IT product for the
+performance of security critical operations between the products. An
+example of such a security critical operation is the updating of the TSF
+authentication database by the transfer of data from a trusted product whose
+function is the collection of audit data.
+
+
+**FTP_ITC.1** **Inter-TSF trusted channel**
+
+
+User application notes
+
+
+1386 This component should be used when a trusted communication channel
+between the TSF and another trusted IT product is required.
+
+
+April 2017 Version 3.1 Page 321 of 323
+
+
+**Class FTP: Trusted path/channels**
+
+
+Operations
+
+
+Selection:
+
+
+1387 In **FTP_ITC.1.2**, the PP/ST author must specify whether the local TSF,
+another trusted IT product, or both shall have the capability to initiate
+the trusted channel.
+
+
+Assignment:
+
+
+1388 In **FTP_ITC.1.3**, the PP/ST author should specify the functions for
+which a trusted channel is required. Examples of these functions may
+include transfer of user, subject, and/or object security attributes and
+ensuring consistency of TSF data.
+
+## **M.2 Trusted path (FTP_TRP)**
+
+
+User notes
+
+
+1389 This family defines the requirements to establish and maintain trusted
+communication to or from users and the TSF. A trusted path may be required
+for any security-relevant interaction. Trusted path exchanges may be initiated
+by a user during an interaction with the TSF, or the TSF may establish
+communication with the user via a trusted path.
+
+
+**FTP_TRP.1** **Trusted path**
+
+
+User application notes
+
+
+1390 This component should be used when trusted communication between a user
+and the TSF is required, either for initial authentication purposes only or for
+additional specified user operations.
+
+
+Operations
+
+
+Selection:
+
+
+1391 In **FTP_TRP.1.1**, the PP/ST author should specify whether the trusted
+path must be extended to remote and/or local users.
+
+
+1392 In **FTP_TRP.1.1**, the PP/ST author should specify whether the trusted
+path shall protect the data from modification, disclosure, and/or other
+types of integrity or confidentiality violation.
+
+
+Assignment:
+
+
+1393 In **FTP_TRP.1.1**, if selected, the PP/ST author should identify any
+additional types of integrity or confidentiality violation against which
+the trusted path shall protect the data.
+
+
+Page 322 of 323 Version 3.1 April 2017
+
+
+**Class FTP: Trusted path/channels**
+
+
+Selection:
+
+
+1394 In **FTP_TRP.1.2**, the PP/ST author should specify whether the TSF,
+local users, and/or remote users should be able to initiate the trusted
+path.
+
+
+1395 In **FTP_TRP.1.3**, the PP/ST author should specify whether the trusted
+path is to be used for initial user authentication and/or for other
+specified services.
+
+
+Assignment:
+
+
+1396 In **FTP_TRP.1.3**, if selected, the PP/ST author should identify other
+services for which trusted path is required, if any.
+
+
+April 2017 Version 3.1 Page 323 of 323
+
+
+
diff --git a/niap-cc/sdp-file-encrypt/doc/knowledge_base/CCPART3V3.1R5.md b/niap-cc/sdp-file-encrypt/doc/knowledge_base/CCPART3V3.1R5.md
new file mode 100644
index 0000000..8d8df26
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/doc/knowledge_base/CCPART3V3.1R5.md
@@ -0,0 +1,14244 @@
+Consider using the pymupdf_layout package for a greatly improved page layout analysis.
+# **Foreword**
+
+This version of the Common Criteria for Information Technology Security Evaluation (CC
+v3.1) is the first major revision since being published as CC v2.3 in 2005.
+
+CC v3.1 aims to: eliminate redundant evaluation activities; reduce/eliminate activities that
+contribute little to the final assurance of a product; clarify CC terminology to reduce
+misunderstanding; restructure and refocus the evaluation activities to those areas where
+security assurance is gained; and add new CC requirements if needed.
+
+CC version 3.1 consists of the following parts:
+
+
+๏ญ Part 1: Introduction and general model
+
+
+๏ญ Part 2: Security functional components
+
+
+๏ญ Part 3: Security assurance components
+
+
+_**Trademarks:**_
+
+
+๏ญ UNIX is a registered trademark of The Open Group in the United States and other
+countries
+
+
+๏ญ Windows is a registered trademark of Microsoft Corporation in the United States
+and other countries
+
+
+Page 2 of 247 Version 3.1 April 2017
+
+
+_**Legal Notice:**_
+
+_The governmental organisations listed below contributed to the development of this version_
+_of the Common Criteria for Information Technology Security Evaluation. As the joint_
+_holders of the copyright in the Common Criteria for Information Technology Security_
+_Evaluation, version_ 3.1 _Parts 1 through 3 (called โCC_ 3.1 _โ), they hereby grant non-_
+_exclusive license to ISO/IEC to use CC_ 3.1 _in the continued development/maintenance of the_
+_ISO/IEC 15408 international standard. However, these governmental organisations retain_
+_the right to use, copy, distribute, translate or modify CC_ 3.1 _as they see fit._
+
+_Australia:_ _The Australian Signals Directorate;_
+_Canada:_ _Communications Security Establishment;_
+_France:_ _Agence Nationale de la Sรฉcuritรฉ des Systรจmes d'Information;_
+_Germany:_ _Bundesamt fรผr Sicherheit in der Informationstechnik;_
+_Japan:_ _Information Technology Promotion Agency;_
+_Netherlands:_ _Netherlands National Communications Security Agency;_
+_New Zealand:_ _Government Communications Security Bureau;_
+_Republic of Korea:_ _National Security Research Institute;_
+_Spain:_ _Ministerio de Administraciones Pรบblicas and_
+_Centro Criptolรณgico Nacional;_
+_Sweden:_ _Swedish Defence Materiel Administration;_
+_United Kingdom:_ _National Cyber Security Centre;_
+_United States:_ _The National Security Agency and the_
+_National Institute of Standards and Technology._
+
+
+April 2017 Version 3.1 Page 3 of 247
+
+
+**Table of contents**
+
+# **Table of Contents**
+
+
+**1** **INTRODUCTION ............................................................................................. 11**
+
+
+**2** **SCOPE ........................................................................................................... 12**
+
+
+**3** **NORMATIVE REFERENCES ......................................................................... 13**
+
+
+**4** **TERMS AND DEFINITIONS, SYMBOLS AND ABBREVIATED TERMS ...... 14**
+
+
+**5** **OVERVIEW ..................................................................................................... 15**
+
+
+**5.1** **Organisation of CC Part 3 ..................................................................................................................... 15**
+
+
+**6** **ASSURANCE PARADIGM ............................................................................. 16**
+
+
+**6.1** **CC philosophy ........................................................................................................................................ 16**
+
+
+**6.2** **Assurance approach ............................................................................................................................... 16**
+6.2.1 Significance of vulnerabilities ........................................................................................................ 16
+6.2.2 Cause of vulnerabilities .................................................................................................................. 17
+6.2.3 CC assurance .................................................................................................................................. 17
+6.2.4 Assurance through evaluation......................................................................................................... 17
+
+
+**6.3** **The CC evaluation assurance scale ....................................................................................................... 18**
+
+
+**7** **SECURITY ASSURANCE COMPONENTS .................................................... 19**
+
+
+**7.1** **Security assurance classes, families and components structure ......................................................... 19**
+7.1.1 Assurance class structure ................................................................................................................ 19
+7.1.2 Assurance family structure ............................................................................................................. 20
+7.1.3 Assurance component structure ...................................................................................................... 21
+7.1.4 Assurance elements ........................................................................................................................ 24
+7.1.5 Component taxonomy..................................................................................................................... 24
+
+
+**7.2** **EAL structure ......................................................................................................................................... 24**
+7.2.1 EAL name ....................................................................................................................................... 25
+7.2.2 Objectives ....................................................................................................................................... 25
+7.2.3 Application notes ............................................................................................................................ 25
+7.2.4 Assurance components ................................................................................................................... 26
+7.2.5 Relationship between assurances and assurance levels .................................................................. 26
+
+
+**7.3** **CAP structure ......................................................................................................................................... 27**
+7.3.1 CAP name ....................................................................................................................................... 28
+7.3.2 Objectives ....................................................................................................................................... 28
+7.3.3 Application notes ............................................................................................................................ 28
+7.3.4 Assurance components ................................................................................................................... 28
+7.3.5 Relationship between assurances and assurance levels .................................................................. 29
+
+
+**8** **EVALUATION ASSURANCE LEVELS .......................................................... 31**
+
+
+**8.1** **Evaluation assurance level (EAL) overview ........................................................................................ 31**
+
+
+Page 4 of 247 Version 3.1 April 2017
+
+
+**Table of contents**
+
+
+**8.2** **Evaluation assurance level details ......................................................................................................... 32**
+
+
+**8.3** **Evaluation assurance level 1 (EAL1) - functionally tested ................................................................. 33**
+
+
+**8.4** **Evaluation assurance level 2 (EAL2) - structurally tested .................................................................. 35**
+
+
+**8.5** **Evaluation assurance level 3 (EAL3) - methodically tested and checked .......................................... 37**
+
+
+**8.6** **Evaluation assurance level 4 (EAL4) - methodically designed, tested, and reviewed ...................... 39**
+
+
+**8.7** **Evaluation assurance level 5 (EAL5) - semiformally designed and tested ........................................ 41**
+
+
+**8.8** **Evaluation assurance level 6 (EAL6) - semiformally verified design and tested .............................. 43**
+
+
+**8.9** **Evaluation assurance level 7 (EAL7) - formally verified design and tested ...................................... 45**
+
+
+**9** **COMPOSED ASSURANCE PACKAGES ...................................................... 47**
+
+
+**9.1** **Composed assurance package (CAP) overview ................................................................................... 47**
+
+
+**9.2** **Composed assurance package details ................................................................................................... 49**
+
+
+**9.3** **Composition assurance level A (CAP-A) - Structurally composed .................................................... 50**
+
+
+**9.4** **Composition assurance level B (CAP-B) - Methodically composed ................................................... 52**
+
+
+**9.5** **Composition assurance level C (CAP-C) - Methodically composed, tested and reviewed ............... 54**
+
+
+**10** **CLASS APE: PROTECTION PROFILE EVALUATION ................................. 56**
+
+
+**10.1** **PP introduction (APE_INT) ............................................................................................................. 58**
+
+
+**10.2** **Conformance claims (APE_CCL) .................................................................................................... 59**
+
+
+**10.3** **Security problem definition (APE_SPD) ......................................................................................... 61**
+
+
+**10.4** **Security objectives (APE_OBJ) ........................................................................................................ 62**
+
+
+**10.5** **Extended components definition (APE_ECD) ................................................................................ 64**
+
+
+**10.6** **Security requirements (APE_REQ) ................................................................................................. 65**
+
+
+**11** **CLASS ACE: PROTECTION PROFILE CONFIGURATION EVALUATION .. 67**
+
+
+**11.1** **PP-Module introduction (ACE_INT) .............................................................................................. 69**
+
+
+**11.2** **PP-Module conformance claims (ACE_CCL) ................................................................................ 70**
+
+
+**11.3** **PP-Module Security problem definition (ACE_SPD) .................................................................... 71**
+
+
+**11.4** **PP-Module Security objectives (ACE_OBJ) ................................................................................... 72**
+
+
+**11.5** **PP-Module extended components definition (ACE_ECD) ............................................................ 73**
+
+
+**11.6** **PP-Module security requirements (ACE_REQ) ............................................................................. 74**
+
+
+**11.7** **PP-Module consistency (ACE_MCO) .............................................................................................. 75**
+
+
+April 2017 Version 3.1 Page 5 of 247
+
+
+**Table of contents**
+
+
+**11.8** **PP-Configuration consistency (ACE_CCO) ................................................................................... 76**
+
+
+**12** **CLASS ASE: SECURITY TARGET EVALUATION ....................................... 78**
+
+
+**12.1** **ST introduction (ASE_INT) ............................................................................................................. 79**
+
+
+**12.2** **Conformance claims (ASE_CCL) .................................................................................................... 80**
+
+
+**12.3** **Security problem definition (ASE_SPD) ......................................................................................... 82**
+
+
+**12.4** **Security objectives (ASE_OBJ) ........................................................................................................ 83**
+
+
+**12.5** **Extended components definition (ASE_ECD) ................................................................................ 85**
+
+
+**12.6** **Security requirements (ASE_REQ) ................................................................................................. 86**
+
+
+**12.7** **TOE summary specification (ASE_TSS) ......................................................................................... 88**
+
+
+**13** **CLASS ADV: DEVELOPMENT ...................................................................... 90**
+
+
+**13.1** **Security Architecture (ADV_ARC) ................................................................................................. 97**
+
+
+**13.2** **Functional specification (ADV_FSP) ............................................................................................... 99**
+13.2.1 Detail about the Interfaces ............................................................................................................ 101
+13.2.2 Components of this Family ........................................................................................................... 102
+
+
+**13.3** **Implementation representation (ADV_IMP) ................................................................................ 109**
+
+
+**13.4** **TSF internals (ADV_INT) .............................................................................................................. 113**
+
+
+**13.5** **Security policy modelling (ADV_SPM) ......................................................................................... 117**
+
+
+**13.6** **TOE design (ADV_TDS) ................................................................................................................. 120**
+13.6.1 Detail about the Subsystems and Modules ................................................................................... 121
+
+
+**14** **CLASS AGD: GUIDANCE DOCUMENTS .................................................... 129**
+
+
+**14.1** **Operational user guidance (AGD_OPE) ....................................................................................... 130**
+
+
+**14.2** **Preparative procedures (AGD_PRE) ............................................................................................ 133**
+
+
+**15** **CLASS ALC: LIFE-CYCLE SUPPORT ........................................................ 135**
+
+
+**15.1** **CM capabilities (ALC_CMC) ........................................................................................................ 137**
+
+
+**15.2** **CM scope (ALC_CMS) ................................................................................................................... 146**
+
+
+**15.3** **Delivery (ALC_DEL) ...................................................................................................................... 151**
+
+
+**15.4** **Development security (ALC_DVS) ................................................................................................ 153**
+
+
+**15.5** **Flaw remediation (ALC_FLR) ....................................................................................................... 155**
+
+
+**15.6** **Life-cycle definition (ALC_LCD) .................................................................................................. 160**
+
+
+**15.7** **Tools and techniques (ALC_TAT) ................................................................................................. 163**
+
+
+Page 6 of 247 Version 3.1 April 2017
+
+
+**Table of contents**
+
+
+**16** **CLASS ATE: TESTS .................................................................................... 166**
+
+
+**16.1** **Coverage (ATE_COV) .................................................................................................................... 167**
+
+
+**16.2** **Depth (ATE_DPT) ........................................................................................................................... 170**
+
+
+**16.3** **Functional tests (ATE_FUN) .......................................................................................................... 174**
+
+
+**16.4** **Independent testing (ATE_IND) .................................................................................................... 177**
+
+
+**17** **CLASS AVA: VULNERABILITY ASSESSMENT ......................................... 182**
+
+
+**17.1** **Vulnerability analysis (AVA_VAN) ............................................................................................... 184**
+
+
+**18** **CLASS ACO: COMPOSITION ..................................................................... 189**
+
+
+**18.1** **Composition rationale (ACO_COR) .............................................................................................. 193**
+
+
+**18.2** **Development evidence (ACO_DEV) .............................................................................................. 194**
+
+
+**18.3** **Reliance of dependent component (ACO_REL) ........................................................................... 198**
+
+
+**18.4** **Composed TOE testing (ACO_CTT) ............................................................................................. 201**
+
+
+**18.5** **Composition vulnerability analysis (ACO_VUL) ......................................................................... 204**
+
+
+**A** **DEVELOPMENT (ADV) ................................................................................ 207**
+
+
+**A.1** **ADV_ARC: Supplementary material on security architectures ................................................. 207**
+A.1.1 Security architecture properties .................................................................................................... 207
+A.1.2 Security architecture descriptions ................................................................................................. 208
+
+
+**A.2** **ADV_FSP: Supplementary material on TSFIs ............................................................................. 211**
+A.2.1 Determining the TSFI ................................................................................................................... 212
+A.2.2 Example: A complex DBMS ........................................................................................................ 215
+A.2.3 Example Functional Specification ................................................................................................ 216
+
+
+**A.3** **ADV_INT: Supplementary material on TSF internals ................................................................ 218**
+A.3.1 Structure of procedural software ................................................................................................... 219
+A.3.2 Complexity of procedural software .............................................................................................. 221
+
+
+**A.4** **ADV_TDS: Subsystems and Modules ............................................................................................ 222**
+A.4.1 Subsystems ................................................................................................................................... 222
+A.4.2 Modules ........................................................................................................................................ 223
+A.4.3 Levelling Approach ...................................................................................................................... 226
+
+
+**A.5** **Supplementary material on formal methods................................................................................. 228**
+
+
+**B** **COMPOSITION (ACO) ................................................................................. 230**
+
+
+**B.1** **Necessity for composed TOE evaluations ...................................................................................... 230**
+
+
+**B.2** **Performing Security Target evaluation for a composed TOE ..................................................... 232**
+
+
+**B.3** **Interactions between composed IT entities ................................................................................... 233**
+
+
+April 2017 Version 3.1 Page 7 of 247
+
+
+**Table of contents**
+
+
+**C** **CROSS REFERENCE OF ASSURANCE COMPONENT DEPENDENCIES 240**
+
+
+**D** **CROSS REFERENCE OF PPS AND ASSURANCE COMPONENTS ......... 245**
+
+
+**E** **CROSS REFERENCE OF EALS AND ASSURANCE COMPONENTS ....... 246**
+
+
+**F** **CROSS REFERENCE OF CAPS AND ASSURANCE COMPONENTS ...... 247**
+
+
+Page 8 of 247 Version 3.1 April 2017
+
+
+**List of figures**
+
+# **List of figures**
+
+
+Figure 1 - Assurance class/family/component/element hierarchy ......................................... 20
+Figure 2 - Assurance component structure ............................................................................ 22
+Figure 3 - Sample class decomposition diagram ................................................................... 24
+Figure 4 - EAL structure ........................................................................................................ 25
+Figure 5 - Assurance and assurance level association ........................................................... 27
+Figure 6 - CAP structure ........................................................................................................ 28
+Figure 7 - Assurance and composed assurance package association .................................... 30
+Figure 8 - APE: Protection Profile evaluation class decomposition ..................................... 57
+Figure 9 - ACE: Protection Profile Configuration evaluation class decomposition ............. 67
+Figure 10 - ASE: Security Target evaluation class decomposition ....................................... 78
+Figure 11 - Relationships of ADV constructs to one another and to other families ............. 92
+Figure 12 - ADV: Development class decomposition ........................................................... 96
+Figure 13 - AGD: Guidance documents class decomposition ............................................. 129
+Figure 14 - ALC: Life-cycle support class decomposition ................................................. 136
+Figure 15 - ATE: Tests class decomposition ....................................................................... 166
+Figure 16 - AVA: Vulnerability assessment class decomposition ...................................... 182
+Figure 17 - Relationship between ACO families and interactions between components ... 190
+Figure 18 - Relationship between ACO families ................................................................ 191
+Figure 19 - ACO: Composition class decomposition .......................................................... 192
+Figure 20 - Wrappers ........................................................................................................... 213
+Figure 21 - Interfaces in a DBMS system ........................................................................... 215
+Figure 22 - Subsystems and Modules .................................................................................. 222
+Figure 23 - Base component abstraction ............................................................................. 234
+Figure 24 - Dependent component abstraction .................................................................... 235
+Figure 25 - Composed TOE abstraction .............................................................................. 236
+Figure 26 - Composed component interfaces ...................................................................... 236
+
+
+April 2017 Version 3.1 Page 9 of 247
+
+
+**List of tables**
+
+# **List of tables**
+
+
+Table 1 - Evaluation assurance level summary ..................................................................... 32
+Table 2 - EAL1 ..................................................................................................................... 34
+Table 3 - EAL2 ..................................................................................................................... 36
+Table 4 - EAL3 ..................................................................................................................... 38
+Table 5 - EAL4 ..................................................................................................................... 40
+Table 6 - EAL5 ..................................................................................................................... 42
+Table 7 - EAL6 ..................................................................................................................... 44
+Table 8 - EAL7 ..................................................................................................................... 46
+Table 9 - Composition assurance level summary ................................................................. 48
+Table 10 - CAP-A ................................................................................................................. 51
+Table 11 - CAP-B ................................................................................................................. 53
+Table 12 - CAP-C ................................................................................................................. 55
+Table 13 - PP assurance packages ........................................................................................ 56
+Table 14 Description Detail Levelling ................................................................................ 228
+Table 15 Dependency table for Class ACO: Composition ................................................. 240
+Table 16 Dependency table for Class ADV: Development ................................................ 241
+Table 17 Dependency table for Class AGD: Guidance documents .................................... 241
+Table 18 Dependency table for Class ALC: Life-cycle support ......................................... 242
+Table 19 Dependency table for Class APE: Protection Profile evaluation ......................... 242
+Table 20 Dependency table for Class ACE: Protection Profile Configuration evaluation . 243
+Table 21 Dependency table for Class ASE: Security Target evaluation ............................ 243
+Table 22 Dependency table for Class ATE: Tests .............................................................. 244
+Table 23 Dependency table for Class AVA: Vulnerability assessment ............................. 244
+Table 24 PP assurance level summary ................................................................................ 245
+Table 25 Evaluation assurance level summary ................................................................... 246
+Table 26 Composition assurance level summary................................................................ 247
+
+
+Page 10 of 247 Version 3.1 April 2017
+
+
+**Introduction**
+
+# **1 Introduction**
+
+
+1 Security assurance components, as defined in this CC Part 3, are the basis for
+the security assurance requirements expressed in a Protection Profile (PP) or
+a Security Target (ST).
+
+
+2 These requirements establish a standard way of expressing the assurance
+requirements for TOEs. This CC Part 3 catalogues the set of assurance
+components, families and classes. This CC Part 3 also defines evaluation
+criteria for PPs and STs and presents evaluation assurance levels that define
+the predefined CC scale for rating assurance for TOEs, which is called the
+Evaluation Assurance Levels (EALs).
+
+
+3 The audience for this CC Part 3 includes consumers, developers, and
+evaluators of secure IT products. CC Part 1 Chapter 7 provides additional
+information on the target audience of the CC, and on the use of the CC by the
+groups that comprise the target audience. These groups may use this part of
+the CC as follows:
+
+
+a) Consumers, who use this CC Part 3 when selecting components to
+express assurance requirements to satisfy the security objectives
+expressed in a PP or ST, determining required levels of security
+assurance of the TOE.
+
+
+b) Developers, who respond to actual or perceived consumer security
+requirements in constructing a TOE, reference this CC Part 3 when
+interpreting statements of assurance requirements and determining
+assurance approaches of TOEs.
+
+
+c) Evaluators, who use the assurance requirements defined in this part of
+the CC as mandatory statement of evaluation criteria when
+determining the assurance of TOEs and when evaluating PPs and STs.
+
+
+April 2017 Version 3.1 Page 11 of 247
+
+
+**Scope**
+
+# **2 Scope**
+
+
+4 This CC Part 3 defines the assurance requirements of the CC. It includes the
+evaluation assurance levels (EALs) that define a scale for measuring
+assurance for component TOEs, the composed assurance packages (CAPs)
+that define a scale for measuring assurance for composed TOEs, the
+individual assurance components from which the assurance levels and
+packages are composed, and the criteria for evaluation of PPs and STs.
+
+
+Page 12 of 247 Version 3.1 April 2017
+
+
+**Normative references**
+
+# **3 Normative references**
+
+
+5 The following referenced documents are indispensable for the application of
+this document. For dated references, only the edition cited applies. For
+undated references, the latest edition of the referenced document (including
+any amendments) applies.
+
+
+[CC-1] Common Criteria for Information Technology
+Security Evaluation, Version 3.1, revision 5, April
+2017. Part 1: Introduction and general model.
+
+
+[CC-2] Common Criteria for Information Technology
+Security Evaluation, Version 3.1, revision 5, April
+2017. Part 2: Functional security components.
+
+
+April 2017 Version 3.1 Page 13 of 247
+
+
+**Terms and definitions, symbols and abbreviated terms**
+
+# **4 Terms and definitions, symbols and** **abbreviated terms**
+
+
+6 For the purposes of this document, the terms, definitions, symbols and
+abbreviated terms given in CC Part 1 apply.
+
+
+Page 14 of 247 Version 3.1 April 2017
+
+
+**Overview**
+
+# **5 Overview**
+
+## **5.1 Organisation of CC Part 3**
+
+
+7 Chapter 6 describes the paradigm used in the security assurance requirements
+of CC Part 3.
+
+
+8 Chapter 7 describes the presentation structure of the assurance classes,
+families, components, evaluation assurance levels along with their
+relationships, and the structure of the composed assurance packages. It also
+characterises the assurance classes and families found in Chapters 10 through
+18.
+
+
+9 Chapter 8 provides detailed definitions of the EALs.
+
+
+10 Chapter 9 provides detailed definitions of the CAPs.
+
+
+11 Chapters 10 through 18 provide the detailed definitions of the CC Part 3
+assurance classes.
+
+
+12 Annex A provides further explanations and examples of the concepts behind
+the Development class.
+
+
+13 Annex B provides an explanation of the concepts behind composed TOE
+evaluations and the Composition class.
+
+
+14 Annex C provides a summary of the dependencies between the assurance
+components.
+
+
+15 Annex D provides a cross reference between PPs and the families and
+components of the APE class.
+
+
+16 Annex E provides a cross reference between the EALs and the assurance
+components.
+
+
+17 Annex F provides a cross reference between the CAPs and the assurance
+components.
+
+
+April 2017 Version 3.1 Page 15 of 247
+
+
+**Assurance paradigm**
+
+# **6 Assurance paradigm**
+
+
+18 The purpose of this Chapter is to document the philosophy that underpins the
+CC approach to assurance. An understanding of this Chapter will permit the
+reader to understand the rationale behind the CC Part 3 assurance
+requirements.
+
+## **6.1 CC philosophy**
+
+
+19 The CC philosophy is that the threats to security and organisational security
+policy commitments should be clearly articulated and the proposed security
+measures be demonstrably sufficient for their intended purpose.
+
+
+20 Furthermore, measures should be adopted that reduce the likelihood of
+vulnerabilities, the ability to exercise (i.e. intentionally exploit or
+unintentionally trigger) a vulnerability, and the extent of the damage that
+could occur from a vulnerability being exercised. Additionally, measures
+should be adopted that facilitate the subsequent identification of
+vulnerabilities and the elimination, mitigation, and/or notification that a
+vulnerability has been exploited or triggered.
+
+## **6.2 Assurance approach**
+
+
+21 The CC philosophy is to provide assurance based upon an evaluation (active
+investigation) of the IT product that is to be trusted. Evaluation has been the
+traditional means of providing assurance and is the basis for prior evaluation
+criteria documents. In aligning the existing approaches, the CC adopts the
+same philosophy. The CC proposes measuring the validity of the
+documentation and of the resulting IT product by expert evaluators with
+increasing emphasis on scope, depth, and rigour.
+
+
+22 The CC does not exclude, nor does it comment upon, the relative merits of
+other means of gaining assurance. Research continues with respect to
+alternative ways of gaining assurance. As mature alternative approaches
+emerge from these research activities, they will be considered for inclusion
+in the CC, which is so structured as to allow their future introduction.
+
+
+**6.2.1** **Significance of vulnerabilities**
+
+
+23 It is assumed that there are threat agents that will actively seek to exploit
+opportunities to violate security policies both for illicit gains and for wellintentioned, but nonetheless insecure actions. Threat agents may also
+accidentally trigger security vulnerabilities, causing harm to the organisation.
+Due to the need to process sensitive information and the lack of availability
+of sufficiently trusted products, there is significant risk due to failures of IT.
+It is, therefore, likely that IT security breaches could lead to significant loss.
+
+
+24 IT security breaches arise through the intentional exploitation or the
+unintentional triggering of vulnerabilities in the application of IT within
+business concerns.
+
+
+Page 16 of 247 Version 3.1 April 2017
+
+
+**Assurance paradigm**
+
+
+25 Steps should be taken to prevent vulnerabilities arising in IT products. To the
+extent feasible, vulnerabilities should be:
+
+
+a) eliminated -- that is, active steps should be taken to expose, and
+remove or neutralise, all exercisable vulnerabilities;
+
+
+b) minimised -- that is, active steps should be taken to reduce, to an
+acceptable residual level, the potential impact of any exercise of a
+vulnerability;
+
+
+c) monitored -- that is, active steps should be taken to ensure that any
+attempt to exercise a residual vulnerability will be detected so that
+steps can be taken to limit the damage.
+
+
+**6.2.2** **Cause of vulnerabilities**
+
+
+26 Vulnerabilities can arise through failures in:
+
+
+a) requirements -- that is, an IT product may possess all the functions
+and features required of it and still contain vulnerabilities that render
+it unsuitable or ineffective with respect to security;
+
+
+b) development -- that is, an IT product does not meet its specifications
+and/or vulnerabilities have been introduced as a result of poor
+development standards or incorrect design choices;
+
+
+c) operation -- that is, an IT product has been constructed correctly to a
+correct specification but vulnerabilities have been introduced as a
+result of inadequate controls upon the operation.
+
+
+**6.2.3** **CC assurance**
+
+
+27 Assurance is grounds for confidence that an IT product meets its security
+objectives. Assurance can be derived from reference to sources such as
+unsubstantiated assertions, prior relevant experience, or specific experience.
+However, the CC provides assurance through active investigation. Active
+investigation is an evaluation of the IT product in order to determine its
+security properties.
+
+
+**6.2.4** **Assurance through evaluation**
+
+
+28 Evaluation has been the traditional means of gaining assurance, and is the
+basis of the CC approach. Evaluation techniques can include, but are not
+limited to:
+
+
+a) analysis and checking of process(es) and procedure(s);
+
+
+b) checking that process(es) and procedure(s) are being applied;
+
+
+c) analysis of the correspondence between TOE design representations;
+
+
+d) analysis of the TOE design representation against the requirements;
+
+
+April 2017 Version 3.1 Page 17 of 247
+
+
+**Assurance paradigm**
+
+
+e) verification of proofs;
+
+
+f) analysis of guidance documents;
+
+
+g) analysis of functional tests developed and the results provided;
+
+
+h) independent functional testing;
+
+
+i) analysis for vulnerabilities (including flaw hypothesis);
+
+
+j) penetration testing.
+
+## **6.3 The CC evaluation assurance scale**
+
+
+29 The CC philosophy asserts that greater assurance results from the application
+of greater evaluation effort, and that the goal is to apply the minimum effort
+required to provide the necessary level of assurance. The increasing level of
+effort is based upon:
+
+
+a) scope -- that is, the effort is greater because a larger portion of the IT
+product is included;
+
+
+b) depth -- that is, the effort is greater because it is deployed to a finer
+level of design and implementation detail;
+
+
+c) rigour -- that is, the effort is greater because it is applied in a more
+structured, formal manner.
+
+
+Page 18 of 247 Version 3.1 April 2017
+
+
+**Security assurance components**
+
+# **7 Security assurance components**
+
+## **7.1 Security assurance classes, families and components** **structure**
+
+
+30 The following Sections describe the constructs used in representing the
+assurance classes, families, and components.
+
+
+31 Figure 1 illustrates the SARs defined in this CC Part 3. Note that the most
+abstract collection of SARs is referred to as a class. Each class contains
+assurance families, which then contain assurance components, which in turn
+contain assurance elements. Classes and families are used to provide a
+taxonomy for classifying SARs, while components are used to specify SARs
+in a PP/ST.
+
+
+**7.1.1** **Assurance class structure**
+
+
+32 Figure 1 illustrates the assurance class structure.
+
+
+7.1.1.1 Class name
+
+
+33 Each assurance class is assigned a unique name. The name indicates the
+topics covered by the assurance class.
+
+
+34 A unique short form of the assurance class name is also provided. This is the
+primary means for referencing the assurance class. The convention adopted
+is an โAโ followed by two letters related to the class name.
+
+
+7.1.1.2 Class introduction
+
+
+35 Each assurance class has an introductory Section that describes the
+composition of the class and contains supportive text covering the intent of
+the class.
+
+
+7.1.1.3 Assurance families
+
+
+36 Each assurance class contains at least one assurance family. The structure of
+the assurance families is described in the following Section.
+
+
+April 2017 Version 3.1 Page 19 of 247
+
+
+**Security assurance components**
+
+
+**Figure 1 - Assurance class/family/component/element hierarchy**
+
+
+**7.1.2** **Assurance family structure**
+
+
+37 Figure 1 illustrates the assurance family structure.
+
+
+7.1.2.1 Family name
+
+
+38 Every assurance family is assigned a unique name. The name provides
+descriptive information about the topics covered by the assurance family.
+Each assurance family is placed within the assurance class that contains other
+families with the same intent.
+
+
+39 A unique short form of the assurance family name is also provided. This is
+the primary means used to reference the assurance family. The convention
+adopted is that the short form of the class name is used, followed by an
+underscore, and then three letters related to the family name.
+
+
+Page 20 of 247 Version 3.1 April 2017
+
+
+**Security assurance components**
+
+
+7.1.2.2 Objectives
+
+
+40 The objectives Section of the assurance family presents the intent of the
+assurance family.
+
+
+41 This Section describes the objectives, particularly those related to the CC
+assurance paradigm, that the family is intended to address. The description
+for the assurance family is kept at a general level. Any specific details
+required for objectives are incorporated in the particular assurance
+component.
+
+
+7.1.2.3 Component levelling
+
+
+42 Each assurance family contains one or more assurance components. This
+Section of the assurance family describes the components available and
+explains the distinctions between them. Its main purpose is to differentiate
+between the assurance components once it has been determined that the
+assurance family is a necessary or useful part of the SARs for a PP/ST.
+
+
+43 Assurance families containing more than one component are levelled and
+rationale is provided as to how the components are levelled. This rationale is
+in terms of scope, depth, and/or rigour.
+
+
+7.1.2.4 Application notes
+
+
+44 The application notes Section of the assurance family, if present, contains
+additional information for the assurance family. This information should be
+of particular interest to users of the assurance family (e.g. PP and ST authors,
+designers of TOEs, evaluators). The presentation is informal and covers, for
+example, warnings about limitations of use and areas where specific attention
+may be required.
+
+
+7.1.2.5 Assurance components
+
+
+45 Each assurance family has at least one assurance component. The structure
+of the assurance components is provided in the following Section.
+
+
+**7.1.3** **Assurance component structure**
+
+
+46 Figure 2 illustrates the assurance component structure.
+
+
+April 2017 Version 3.1 Page 21 of 247
+
+
+**Security assurance components**
+
+
+**Figure 2 - Assurance component structure**
+
+
+47 The relationship between components within a family is highlighted using a
+bolding convention. Those parts of the requirements that are new, enhanced
+or modified beyond the requirements of the previous component within a
+hierarchy are bolded.
+
+
+7.1.3.1 Component identification
+
+
+48 The component identification Section provides descriptive information
+necessary to identify, categorise, register, and reference a component.
+
+
+49 Every assurance component is assigned a unique name. The name provides
+descriptive information about the topics covered by the assurance component.
+Each assurance component is placed within the assurance family that shares
+its security objective.
+
+
+50 A unique short form of the assurance component name is also provided. This
+is the primary means used to reference the assurance component. The
+convention used is that the short form of the family name is used, followed
+by a period, and then a numeric character. The numeric characters for the
+components within each family are assigned sequentially, starting from 1.
+
+
+7.1.3.2 Objectives
+
+
+51 The objectives Section of the assurance component, if present, contains
+specific objectives for the particular assurance component. For those
+assurance components that have this Section, it presents the specific intent of
+the component and a more detailed explanation of the objectives.
+
+
+7.1.3.3 Application notes
+
+
+52 The application notes Section of an assurance component, if present,
+contains additional information to facilitate the use of the component.
+
+
+Page 22 of 247 Version 3.1 April 2017
+
+
+**Security assurance components**
+
+
+7.1.3.4 Dependencies
+
+
+53 Dependencies among assurance components arise when a component is not
+self-sufficient, and relies upon the presence of another component.
+
+
+54 Each assurance component provides a complete list of dependencies to other
+assurance components. Some components may list โNo dependenciesโ, to
+indicate that no dependencies have been identified. The components
+depended upon may have dependencies on other components.
+
+
+55 The dependency list identifies the minimum set of assurance components
+which are relied upon. Components which are hierarchical to a component in
+the dependency list may also be used to satisfy the dependency.
+
+
+56 In specific situations the indicated dependencies might not be applicable. The
+PP/ST author, by providing rationale for why a given dependency is not
+applicable, may elect not to satisfy that dependency.
+
+
+7.1.3.5 Assurance elements
+
+
+57 A set of assurance elements is provided for each assurance component. An
+assurance element is a security requirement which, if further divided, would
+not yield a meaningful evaluation result. It is the smallest security
+requirement recognised in the CC.
+
+
+58 Each assurance element is identified as belonging to one of the three sets of
+assurance elements:
+
+
+a) Developer action elements: the activities that shall be performed by
+the developer. This set of actions is further qualified by evidential
+material referenced in the following set of elements. Requirements
+for developer actions are identified by appending the letter โDโ to the
+element number.
+
+
+b) Content and presentation of evidence elements: the evidence required,
+what the evidence shall demonstrate, and what information the
+evidence shall convey. Requirements for content and presentation of
+evidence are identified by appending the letter โCโ to the element
+number.
+
+
+c) Evaluator action elements: the activities that shall be performed by
+the evaluator. This set of actions explicitly includes confirmation that
+the requirements prescribed in the content and presentation of
+evidence elements have been met. It also includes explicit actions and
+analysis that shall be performed in addition to that already performed
+by the developer. Implicit evaluator actions are also to be performed
+as a result of developer action elements which are not covered by
+content and presentation of evidence requirements. Requirements for
+evaluator actions are identified by appending the letter โEโ to the
+element number.
+
+
+April 2017 Version 3.1 Page 23 of 247
+
+
+**Security assurance components**
+
+
+59 The developer actions and content and presentation of evidence define the
+assurance requirements that are used to represent a developer's
+responsibilities in demonstrating assurance in the TOE meeting the SFRs of
+a PP or ST.
+
+
+60 The evaluator actions define the evaluator's responsibilities in the two
+aspects of evaluation. The first aspect is validation of the PP/ST, in
+accordance with the classes APE and ASE in Chapters APE: Protection
+Profile evaluation and ASE: Security Target evaluation. The second aspect is
+verification of the TOE's conformance with its SFRs and SARs. By
+demonstrating that the PP/ST is valid and that the requirements are met by
+the TOE, the evaluator can provide a basis for confidence that the TOE in its
+operational environment solves the defined security problem.
+
+
+61 The developer action elements, content and presentation of evidence
+elements, and explicit evaluator action elements, identify the evaluator effort
+that shall be expended in verifying the security claims made in the ST of the
+TOE.
+
+
+**7.1.4** **Assurance elements**
+
+
+62 Each element represents a requirement to be met. These statements of
+requirements are intended to be clear, concise, and unambiguous. Therefore,
+there are no compound sentences: each separable requirement is stated as an
+individual element.
+
+
+**7.1.5** **Component taxonomy**
+
+
+63 This CC Part 3 contains classes of families and components that are grouped
+on the basis of related assurance. At the start of each class is a diagram that
+indicates the families in the class and the components in each family.
+
+
+**Figure 3 - Sample class decomposition diagram**
+
+
+64 In Figure 3, above, the class as shown contains a single family. The family
+contains three components that are linearly hierarchical (i.e. component 2
+requires more than component 1, in terms of specific actions, specific
+evidence, or rigour of the actions or evidence). The assurance families in this
+CC Part 3 are all linearly hierarchical, although linearity is not a mandatory
+criterion for assurance families that may be added in the future.
+
+## **7.2 EAL structure**
+
+
+65 Figure 4 illustrates the EALs and associated structure defined in this CC Part
+3. Note that while the figure shows the contents of the assurance components,
+it is intended that this information would be included in an EAL by reference
+to the actual components defined in the CC.
+
+
+Page 24 of 247 Version 3.1 April 2017
+
+
+**Security assurance components**
+
+
+**7.2.1** **EAL name**
+
+
+
+**Figure 4 - EAL structure**
+
+
+
+66 Each EAL is assigned a unique name. The name provides descriptive
+information about the intent of the EAL.
+
+
+67 A unique short form of the EAL name is also provided. This is the primary
+means used to reference the EAL.
+
+
+**7.2.2** **Objectives**
+
+
+68 The objectives Section of the EAL presents the intent of the EAL.
+
+
+**7.2.3** **Application notes**
+
+
+69 The application notes Section of the EAL, if present, contains information of
+particular interest to users of the EAL (e.g. PP and ST authors, designers of
+TOEs targeting this EAL, evaluators). The presentation is informal and
+covers, for example, warnings about limitations of use and areas where
+specific attention may be required.
+
+
+April 2017 Version 3.1 Page 25 of 247
+
+
+**Security assurance components**
+
+
+**7.2.4** **Assurance components**
+
+
+70 A set of assurance components have been chosen for each EAL.
+
+
+71 A higher level of assurance than that provided by a given EAL can be
+achieved by:
+
+
+a) including additional assurance components from other assurance
+families; or
+
+
+b) replacing an assurance component with a higher level assurance
+component from the same assurance family.
+
+
+**7.2.5** **Relationship between assurances and assurance levels**
+
+
+72 Figure 5 illustrates the relationship between the SARs and the assurance
+levels defined in the CC. While assurance components further decompose
+into assurance elements, assurance elements cannot be individually
+referenced by assurance levels. Note that the arrow in the figure represents a
+reference from an EAL to an assurance component within the class where it
+is defined.
+
+
+Page 26 of 247 Version 3.1 April 2017
+
+
+**Security assurance components**
+
+
+**Figure 5 - Assurance and assurance level association**
+
+## **7.3 CAP structure**
+
+
+73 The structure of the CAPs is similar to that of the EALs. The main difference
+between these two types of package is the type of TOE they apply to; the
+EALs applying to component TOEs and the CAPs applying to composed
+TOEs.
+
+
+74 Figure 6 illustrates the CAPs and associated structure defined in this CC Part
+3. Note that while the figure shows the contents of the assurance components,
+it is intended that this information would be included in a CAP by reference
+to the actual components defined in the CC.
+
+
+April 2017 Version 3.1 Page 27 of 247
+
+
+**Security assurance components**
+
+
+**Figure 6 - CAP structure**
+
+
+**7.3.1** **CAP name**
+
+
+75 Each CAP is assigned a unique name. The name provides descriptive
+information about the intent of the CAP.
+
+
+76 A unique short form of the CAP name is also provided. This is the primary
+means used to reference the CAP.
+
+
+**7.3.2** **Objectives**
+
+
+77 The objectives Section of the CAP presents the intent of the CAP.
+
+
+**7.3.3** **Application notes**
+
+
+78 The application notes Section of the CAP, if present, contains information of
+particular interest to users of the CAP (e.g. PP and ST authors, integrators of
+composed TOEs targeting this CAP, evaluators). The presentation is
+informal and covers, for example, warnings about limitations of use and
+areas where specific attention may be required.
+
+
+**7.3.4** **Assurance components**
+
+
+79 A set of assurance components have been chosen for each CAP.
+
+
+Page 28 of 247 Version 3.1 April 2017
+
+
+**Security assurance components**
+
+
+80 Some dependencies identify the activities performed during the evaluation of
+the dependent component on which the composed TOE activity relies. Where
+it is not explicitly identified that the dependency is on a dependent
+component activity, the dependency is to another evaluation activity of the
+composed TOE.
+
+
+81 A higher level of assurance than that provided by a given CAP can be
+achieved by:
+
+
+a) including additional assurance components from other assurance
+families; or
+
+
+b) replacing an assurance component with a higher level assurance
+component from the same assurance family.
+
+
+82 The ACO: Composition components included in the CAP assurance
+packages should not be used as augmentations for component TOE
+evaluations, as this would provide no meaningful assurance for the
+component.
+
+
+**7.3.5** **Relationship between assurances and assurance levels**
+
+
+83 Figure 7 illustrates the relationship between the SARs and the composed
+assurance packages defined in the CC. While assurance components further
+decompose into assurance elements, assurance elements cannot be
+individually referenced by assurance packages. Note that the arrow in the
+figure represents a reference from a CAP to an assurance component within
+the class where it is defined.
+
+
+April 2017 Version 3.1 Page 29 of 247
+
+
+**Security assurance components**
+
+
+**Figure 7 - Assurance and composed assurance package association**
+
+
+Page 30 of 247 Version 3.1 April 2017
+
+
+**Evaluation assurance levels**
+
+# **8 Evaluation assurance levels**
+
+
+84 The Evaluation Assurance Levels (EALs) provide an increasing scale that
+balances the level of assurance obtained with the cost and feasibility of
+acquiring that degree of assurance. The CC approach identifies the separate
+concepts of assurance in a TOE at the end of the evaluation, and of
+maintenance of that assurance during the operational use of the TOE.
+
+
+85 It is important to note that not all families and components from CC Part 3
+are included in the EALs. This is not to say that these do not provide
+meaningful and desirable assurances. Instead, it is expected that these
+families and components will be considered for augmentation of an EAL in
+those PPs and STs for which they provide utility.
+
+## **8.1 Evaluation assurance level (EAL) overview**
+
+
+86 Table 1 represents a summary of the EALs. The columns represent a
+hierarchically ordered set of EALs, while the rows represent assurance
+families. Each number in the resulting matrix identifies a specific assurance
+component where applicable.
+
+
+87 As outlined in the next Section, seven hierarchically ordered evaluation
+assurance levels are defined in the CC for the rating of a TOE's assurance.
+They are hierarchically ordered inasmuch as each EAL represents more
+assurance than all lower EALs. The increase in assurance from EAL to EAL
+is accomplished by substitution of a hierarchically higher assurance
+component from the same assurance family (i.e. increasing rigour, scope,
+and/or depth) and from the addition of assurance components from other
+assurance families (i.e. adding new requirements).
+
+
+88 These EALs consist of an appropriate combination of assurance components
+as described in Chapter 7 of this CC Part 3. More precisely, each EAL
+includes no more than one component of each assurance family and all
+assurance dependencies of every component are addressed.
+
+
+89 While the EALs are defined in the CC, it is possible to represent other
+combinations of assurance. Specifically, the notion of โaugmentationโ allows
+the addition of assurance components (from assurance families not already
+included in the EAL) or the substitution of assurance components (with
+another hierarchically higher assurance component in the same assurance
+family) to an EAL. Of the assurance constructs defined in the CC, only EALs
+may be augmented. The notion of an โEAL minus a constituent assurance
+componentโ is not recognised by the standard as a valid claim. Augmentation
+carries with it the obligation on the part of the claimant to justify the utility
+and added value of the added assurance component to the EAL. An EAL
+may also be augmented with extended assurance requirements.
+
+
+April 2017 Version 3.1 Page 31 of 247
+
+
+**Evaluation assurance levels**
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+|Assurance
class|Assurance
Family|Assurance Components by Evaluation
Assurance Level|Col4|Col5|Col6|Col7|Col8|Col9|
+|---|---|---|---|---|---|---|---|---|
+|Assurance
class|Assurance
Family|EAL1|EAL2|EAL3|EAL4|EAL5|EAL6|EAL7|
+|Development|ADV_ARC||**1**|1|1|1|1|1|
+|Development|ADV_FSP|**1**|**2**|**3**|**4**|**5**|5|**6**|
+|Development|ADV_IMP||||**1**|1|**2**|2|
+|Development|ADV_INT|||||**2**|**3**|3|
+|Development|ADV_SPM||||||**1**|1|
+|Development|ADV_TDS||**1**|**2**|**3**|**4**|**5**|**6**|
+|Guidance
documents|AGD_OPE|**1**|1|1|1|1|1|1|
+|Guidance
documents|AGD_PRE|**1**|1|1|1|1|1|1|
+|Life-cycle
support|ALC_CMC|**1**|**2**|**3**|**4**|4|**5**|5|
+|Life-cycle
support|ALC_CMS|**1**|**2**|**3**|**4**|**5**|5|5|
+|Life-cycle
support|ALC_DEL||**1**|1|1|1|1|1|
+|Life-cycle
support|ALC_DVS|||**1**|1|1|**2**|2|
+|Life-cycle
support|ALC_FLR||||||||
+|Life-cycle
support|ALC_LCD|||**1**|1|1|1|**2**|
+|Life-cycle
support|ALC_TAT||||**1**|**2**|**3**|3|
+|Security
Target
evaluation|ASE_CCL|**1**|1|1|1|1|1|1|
+|Security
Target
evaluation|ASE_ECD|**1**|1|1|1|1|1|1|
+|Security
Target
evaluation|ASE_INT|**1**|1|1|1|1|1|1|
+|Security
Target
evaluation|ASE_OBJ|**1**|**2**|2|2|2|2|2|
+|Security
Target
evaluation|ASE_REQ|**1**|**2**|2|2|2|2|2|
+|Security
Target
evaluation|ASE_SPD||**1**|1|1|1|1|1|
+|Security
Target
evaluation|ASE_TSS|**1**|1|1|1|1|1|1|
+|Tests|ATE_COV||**1**|**2**|2|2|**3**|3|
+|Tests|ATE_DPT|||**1**|1|**3**|3|**4**|
+|Tests|ATE_FUN||**1**|1|1|1|**2**|2|
+|Tests|ATE_IND|**1**|**2**|2|2|2|2|**3**|
+|Vulnerability
assessment|AVA_VAN|**1**|**2**|2|**3**|**4**|**5**|5|
+
+
+
+**Table 1 - Evaluation assurance level summary**
+
+## **8.2 Evaluation assurance level details**
+
+
+90 The following Sections provide definitions of the EALs, highlighting
+differences between the specific requirements and the prose characterisations
+of those requirements using bold type.
+
+
+Page 32 of 247 Version 3.1 April 2017
+
+
+**Evaluation assurance levels**
+
+## **8.3 Evaluation assurance level 1 (EAL1) - functionally** **tested**
+
+
+Objectives
+
+
+91 EAL1 is applicable where some confidence in correct operation is required,
+but the threats to security are not viewed as serious. It will be of value where
+independent assurance is required to support the contention that due care has
+been exercised with respect to the protection of personal or similar
+information.
+
+
+92 EAL1 requires only a limited security target. It is sufficient to simply state
+the SFRs that the TOE must meet, rather than deriving them from threats,
+OSPs and assumptions through security objectives.
+
+
+93 EAL1 provides an evaluation of the TOE as made available to the customer,
+including independent testing against a specification, and an examination of
+the guidance documentation provided. It is intended that an EAL1 evaluation
+could be successfully conducted without assistance from the developer of the
+TOE, and for minimal outlay.
+
+
+94 An evaluation at this level should provide evidence that the TOE functions in
+a manner consistent with its documentation.
+
+
+Assurance components
+
+
+95 **EAL1 provides a basic level of assurance by a limited security target and**
+**an analysis of the SFRs in that ST using a functional and interface**
+**specification and guidance documentation, to understand the security**
+**behaviour.**
+
+
+96 **The analysis is supported by a search for potential vulnerabilities in the**
+**public domain and independent testing (functional and penetration) of**
+**the TSF.**
+
+
+97 **EAL1 also provides assurance through unique identification of the TOE**
+**and of the relevant evaluation documents.**
+
+
+98 **This EAL provides a meaningful increase in assurance over unevaluated**
+**IT.**
+
+
+April 2017 Version 3.1 Page 33 of 247
+
+
+**Evaluation assurance levels**
+
+|Assurance Class|Assurance components|
+|---|---|
+|ADV: Development|ADV_FSP.1 Basic functional specification|
+|AGD: Guidance documents|AGD_OPE.1 Operational user guidance|
+|AGD: Guidance documents|AGD_PRE.1 Preparative procedures|
+|ALC: Life-cycle support|ALC_CMC.1 Labelling of the TOE|
+|ALC: Life-cycle support|ALC_CMS.1 TOE CM coverage|
+|ASE: Security Target evaluation|ASE_CCL.1 Conformance claims|
+|ASE: Security Target evaluation|ASE_ECD.1 Extended components definition|
+|ASE: Security Target evaluation|ASE_INT.1 ST introduction|
+|ASE: Security Target evaluation|ASE_OBJ.1 Security objectives for the
operational environment|
+|ASE: Security Target evaluation|ASE_REQ.1 Stated security requirements|
+|ASE: Security Target evaluation|ASE_TSS.1 TOE summary specification|
+|ATE: Tests|ATE_IND.1 Independent testing - conformance|
+|AVA: Vulnerability assessment|AVA_VAN.1 Vulnerability survey|
+
+
+
+**Table 2 - EAL1**
+
+
+Page 34 of 247 Version 3.1 April 2017
+
+
+**Evaluation assurance levels**
+
+## **8.4 Evaluation assurance level 2 (EAL2) - structurally** **tested**
+
+
+Objectives
+
+
+99 EAL2 requires the co-operation of the developer in terms of the delivery of
+design information and test results, but should not demand more effort on the
+part of the developer than is consistent with good commercial practise. As
+such it should not require a substantially increased investment of cost or time.
+
+
+100 EAL2 is therefore applicable in those circumstances where developers or
+users require a low to moderate level of independently assured security in the
+absence of ready availability of the complete development record. Such a
+situation may arise when securing legacy systems, or where access to the
+developer may be limited.
+
+
+Assurance components
+
+
+101 **EAL2** provides assurance by a **full** security target and an analysis of the
+SFRs in that ST, using a functional and interface specification, guidance
+documentation **and** **a** **basic** **description** **of** **the** **architecture** **of** **the** **TOE,** to
+understand the security behaviour.
+
+
+102 The analysis is supported by independent testing of the TSF, **evidence** **of**
+**developer** **testing** **based** **on** **the** **functional** **specification,** **selective**
+**independent** **confirmation** **of** **the** **developer** **test** **results,** **and** **a**
+**vulnerability** **analysis** **(based** **upon** **the** **functional** **specification,** **TOE**
+**design,** **security** **architecture** **description** **and** **guidance** **evidence**
+**provided)** **demonstrating** **resistance** **to** **penetration** **attackers** **with** **a** **basic**
+**attack** **potential.**
+
+
+103 **EAL2** also provides assurance through **use** of **a** **configuration** **management**
+**system** and **evidence** of **secure** **delivery** **procedures.**
+
+
+104 This EAL **represents** a meaningful increase in assurance **from** **EAL1** **by**
+**requiring** **developer** **testing,** **a** **vulnerability** **analysis** **(in** **addition** **to** **the**
+**search** **of** **the** **public** **domain),** **and** **independent** **testing** **based** **upon** **more**
+**detailed** **TOE** **specifications.**
+
+
+April 2017 Version 3.1 Page 35 of 247
+
+
+**Evaluation assurance levels**
+
+
+
+
+
+
+
+
+
+
+
+
+
+|Assurance Class|Assurance components|
+|---|---|
+|ADV: Development|ADV_ARC.1 Security architecture description|
+|ADV: Development|ADV_FSP.2 Security-enforcing functional
specification|
+|ADV: Development|ADV_TDS.1 Basic design|
+|AGD: Guidance documents|AGD_OPE.1 Operational user guidance|
+|AGD: Guidance documents|AGD_PRE.1 Preparative procedures|
+|ALC: Life-cycle support|ALC_CMC.2 Use of a CM system|
+|ALC: Life-cycle support|ALC_CMS.2 Parts of the TOE CM coverage|
+|ALC: Life-cycle support|ALC_DEL.1 Delivery procedures|
+|ASE: Security Target evaluation|ASE_CCL.1 Conformance claims|
+|ASE: Security Target evaluation|ASE_ECD.1 Extended components definition|
+|ASE: Security Target evaluation|ASE_INT.1 ST introduction|
+|ASE: Security Target evaluation|ASE_OBJ.2 Security objectives|
+|ASE: Security Target evaluation|ASE_REQ.2 Derived security requirements|
+|ASE: Security Target evaluation|ASE_SPD.1 Security problem definition|
+|ASE: Security Target evaluation|ASE_TSS.1 TOE summary specification|
+|ATE: Tests|ATE_COV.1 Evidence of coverage|
+|ATE: Tests|ATE_FUN.1 Functional testing|
+|ATE: Tests|ATE_IND.2 Independent testing - sample|
+|AVA: Vulnerability assessment|AVA_VAN.2 Vulnerability analysis|
+
+
+**Table 3 - EAL2**
+
+
+
+Page 36 of 247 Version 3.1 April 2017
+
+
+**Evaluation assurance levels**
+
+## **8.5 Evaluation assurance level 3 (EAL3) - methodically** **tested and checked**
+
+
+Objectives
+
+
+105 EAL3 permits a conscientious developer to gain maximum assurance from
+positive security engineering at the design stage without substantial alteration
+of existing sound development practises.
+
+
+106 EAL3 is applicable in those circumstances where developers or users require
+a moderate level of independently assured security, and require a thorough
+investigation of the TOE and its development without substantial reengineering.
+
+
+Assurance components
+
+
+107 **EAL3** provides assurance by a full security target and an analysis of the
+SFRs in that ST, using a functional and interface specification, guidance
+documentation, and **an** **architectural** description of the **design** of the TOE,
+to understand the security behaviour.
+
+
+108 The analysis is supported by independent testing of the TSF, evidence of
+developer testing based on the functional specification **and** **TOE** **design,**
+selective independent confirmation of the developer test results, and a
+vulnerability analysis (based upon the functional specification, TOE design,
+security architecture description and guidance evidence provided)
+demonstrating resistance to penetration attackers with a basic attack potential.
+
+
+109 **EAL3** also provides assurance through **the** use of **development**
+**environment** **controls,** **TOE** configuration management, and evidence of
+secure delivery procedures.
+
+
+110 This EAL represents a meaningful increase in assurance from **EAL2** by
+requiring **more** **complete** testing **coverage** of the **security** **functionality** and
+**mechanisms** **and/or** **procedures** **that** **provide** **some** **confidence** **that** **the**
+TOE **will** **not** **be** **tampered** **with** **during** **development.**
+
+
+April 2017 Version 3.1 Page 37 of 247
+
+
+**Evaluation assurance levels**
+
+
+
+
+
+
+
+
+
+
+
+
+
+|Assurance Class|Assurance components|
+|---|---|
+|ADV: Development|ADV_ARC.1 Security architecture description|
+|ADV: Development|ADV_FSP.3 Functional specification with
complete summary|
+|ADV: Development|ADV_TDS.2 Architectural design|
+|AGD: Guidance documents|AGD_OPE.1 Operational user guidance|
+|AGD: Guidance documents|AGD_PRE.1 Preparative procedures|
+|ALC: Life-cycle support|ALC_CMC.3 Authorisation controls|
+|ALC: Life-cycle support|ALC_CMS.3 Implementation representation
CM coverage|
+|ALC: Life-cycle support|ALC_DEL.1 Delivery procedures|
+|ALC: Life-cycle support|ALC_DVS.1 Identification of security
measures|
+|ALC: Life-cycle support|ALC_LCD.1 Developer defined life-cycle
model|
+|ASE: Security Target evaluation|ASE_CCL.1 Conformance claims|
+|ASE: Security Target evaluation|ASE_ECD.1 Extended components definition|
+|ASE: Security Target evaluation|ASE_INT.1 ST introduction|
+|ASE: Security Target evaluation|ASE_OBJ.2 Security objectives|
+|ASE: Security Target evaluation|ASE_REQ.2 Derived security requirements|
+|ASE: Security Target evaluation|ASE_SPD.1 Security problem definition|
+|ASE: Security Target evaluation|ASE_TSS.1 TOE summary specification|
+|ATE: Tests|ATE_COV.2 Analysis of coverage|
+|ATE: Tests|ATE_DPT.1 Testing: basic design|
+|ATE: Tests|ATE_FUN.1 Functional testing|
+|ATE: Tests|ATE_IND.2 Independent testing - sample|
+|AVA: Vulnerability assessment|AVA_VAN.2 Vulnerability analysis|
+
+
+**Table 4 - EAL3**
+
+
+
+Page 38 of 247 Version 3.1 April 2017
+
+
+**Evaluation assurance levels**
+
+## **8.6 Evaluation assurance level 4 (EAL4) - methodically** **designed, tested, and reviewed**
+
+
+Objectives
+
+
+111 EAL4 permits a developer to gain maximum assurance from positive
+security engineering based on good commercial development practises which,
+though rigorous, do not require substantial specialist knowledge, skills, and
+other resources. EAL4 is the highest level at which it is likely to be
+economically feasible to retrofit to an existing product line.
+
+
+112 EAL4 is therefore applicable in those circumstances where developers or
+users require a moderate to high level of independently assured security in
+conventional commodity TOEs and are prepared to incur additional securityspecific engineering costs.
+
+
+Assurance components
+
+
+113 **EAL4** provides assurance by a full security target and an analysis of the
+SFRs in that ST, using a functional and **complete** interface specification,
+guidance documentation, **a** description of the **basic** **modular** design of the
+TOE, **and** **a** **subset** **of** **the** **implementation,** to understand the security
+behaviour.
+
+
+114 The analysis is supported by independent testing of the TSF, evidence of
+developer testing based on the functional specification and TOE design,
+selective independent confirmation of the developer test results, and a
+vulnerability analysis (based upon the functional specification, TOE design,
+**implementation** **representation,** security architecture description and
+guidance evidence provided) demonstrating resistance to penetration
+attackers with **an** **Enhanced-Basic** attack potential.
+
+
+115 **EAL4** also provides assurance through the use of development environment
+controls **and** **additional** TOE configuration management **including**
+**automation,** and evidence of secure delivery procedures.
+
+
+116 This EAL represents a meaningful increase in assurance from **EAL3** by
+requiring more **design** **description,** the **implementation** **representation** **for**
+**the** **entire** **TSF,** and **improved** mechanisms and/or procedures that provide
+confidence that the TOE will not be tampered with during development.
+
+
+April 2017 Version 3.1 Page 39 of 247
+
+
+**Evaluation assurance levels**
+
+
+
+
+
+
+
+
+
+
+
+
+
+|Assurance Class|Assurance components|
+|---|---|
+|ADV: Development|ADV_ARC.1 Security architecture description|
+|ADV: Development|ADV_FSP.4 Complete functional specification|
+|ADV: Development|ADV_IMP.1 Implementation representation of
the TSF|
+|ADV: Development|ADV_TDS.3 Basic modular design|
+|AGD: Guidance documents|AGD_OPE.1 Operational user guidance|
+|AGD: Guidance documents|AGD_PRE.1 Preparative procedures|
+|ALC: Life-cycle support|ALC_CMC.4 Production support, acceptance
procedures and automation|
+|ALC: Life-cycle support|ALC_CMS.4 Problem tracking CM coverage|
+|ALC: Life-cycle support|ALC_DEL.1 Delivery procedures|
+|ALC: Life-cycle support|ALC_DVS.1 Identification of security
measures|
+|ALC: Life-cycle support|ALC_LCD.1 Developer defined life-cycle
model|
+|ALC: Life-cycle support|ALC_TAT.1 Well-defined development tools|
+|ASE: Security Target evaluation|ASE_CCL.1 Conformance claims|
+|ASE: Security Target evaluation|ASE_ECD.1 Extended components definition|
+|ASE: Security Target evaluation|ASE_INT.1 ST introduction|
+|ASE: Security Target evaluation|ASE_OBJ.2 Security objectives|
+|ASE: Security Target evaluation|ASE_REQ.2 Derived security requirements|
+|ASE: Security Target evaluation|ASE_SPD.1 Security problem definition|
+|ASE: Security Target evaluation|ASE_TSS.1 TOE summary specification|
+|ATE: Tests|ATE_COV.2 Analysis of coverage|
+|ATE: Tests|ATE_DPT.1 Testing: basic design|
+|ATE: Tests|ATE_FUN.1 Functional testing|
+|ATE: Tests|ATE_IND.2 Independent testing - sample|
+|AVA: Vulnerability assessment|AVA_VAN.3 Focused vulnerability analysis|
+
+
+**Table 5 - EAL4**
+
+
+
+Page 40 of 247 Version 3.1 April 2017
+
+
+**Evaluation assurance levels**
+
+## **8.7 Evaluation assurance level 5 (EAL5) - semiformally** **designed and tested**
+
+
+Objectives
+
+
+117 EAL5 permits a developer to gain maximum assurance from security
+engineering based upon rigorous commercial development practises
+supported by moderate application of specialist security engineering
+techniques. Such a TOE will probably be designed and developed with the
+intent of achieving EAL5 assurance. It is likely that the additional costs
+attributable to the EAL5 requirements, relative to rigorous development
+without the application of specialised techniques, will not be large.
+
+
+118 EAL5 is therefore applicable in those circumstances where developers or
+users require a high level of independently assured security in a planned
+development and require a rigorous development approach without incurring
+unreasonable costs attributable to specialist security engineering techniques.
+
+
+Assurance components
+
+
+119 **EAL5** provides assurance by a full security target and an analysis of the
+SFRs in that ST, using a functional and complete interface specification,
+guidance documentation, a description of the design of the TOE, and the
+implementation, to understand the security behaviour. **A** **modular** **TSF**
+**design** **is** **also** **required.**
+
+
+120 The analysis is supported by independent testing of the TSF, evidence of
+developer testing based on the functional specification, TOE design,
+selective independent confirmation of the developer test results, and **an**
+**independent** vulnerability analysis demonstrating resistance to penetration
+attackers with **a** **moderate** attack potential.
+
+
+121 **EAL5** also provides assurance through the use of **a** development
+environment controls, and **comprehensive** TOE configuration management
+including automation, and evidence of secure delivery procedures.
+
+
+122 This EAL represents a meaningful increase in assurance from **EAL4** by
+requiring **semiformal** **design** **descriptions,** **a** more **structured** **(and** **hence**
+**analysable)** **architecture,** and improved mechanisms and/or procedures that
+provide confidence that the TOE will not be tampered with during
+development.
+
+
+April 2017 Version 3.1 Page 41 of 247
+
+
+**Evaluation assurance levels**
+
+
+
+
+
+
+
+
+
+
+
+
+
+|Assurance Class|Assurance components|
+|---|---|
+|ADV: Development|ADV_ARC.1 Security architecture description|
+|ADV: Development|ADV_FSP.5 Complete semi-formal functional
specification with additional error information|
+|ADV: Development|ADV_IMP.1 Implementation representation of
the TSF|
+|ADV: Development|ADV_INT.2 Well-structured internals|
+|ADV: Development|ADV_TDS.4 Semiformal modular design|
+|AGD: Guidance documents|AGD_OPE.1 Operational user guidance|
+|AGD: Guidance documents|AGD_PRE.1 Preparative procedures|
+|ALC: Life-cycle support|ALC_CMC.4 Production support, acceptance
procedures and automation|
+|ALC: Life-cycle support|ALC_CMS.5 Development tools CM coverage|
+|ALC: Life-cycle support|ALC_DEL.1 Delivery procedures|
+|ALC: Life-cycle support|ALC_DVS.1 Identification of security
measures|
+|ALC: Life-cycle support|ALC_LCD.1 Developer defined life-cycle
model|
+|ALC: Life-cycle support|ALC_TAT.2 Compliance with implementation
standards|
+|ASE: Security Target evaluation|ASE_CCL.1 Conformance claims|
+|ASE: Security Target evaluation|ASE_ECD.1 Extended components definition|
+|ASE: Security Target evaluation|ASE_INT.1 ST introduction|
+|ASE: Security Target evaluation|ASE_OBJ.2 Security objectives|
+|ASE: Security Target evaluation|ASE_REQ.2 Derived security requirements|
+|ASE: Security Target evaluation|ASE_SPD.1 Security problem definition|
+|ASE: Security Target evaluation|ASE_TSS.1 TOE summary specification|
+|ATE: Tests|ATE_COV.2 Analysis of coverage|
+|ATE: Tests|ATE_DPT.3 Testing: modular design|
+|ATE: Tests|ATE_FUN.1 Functional testing|
+|ATE: Tests|ATE_IND.2 Independent testing - sample|
+|AVA: Vulnerability assessment|AVA_VAN.4 Methodical vulnerability analysis|
+
+
+**Table 6 - EAL5**
+
+
+
+Page 42 of 247 Version 3.1 April 2017
+
+
+**Evaluation assurance levels**
+
+## **8.8 Evaluation assurance level 6 (EAL6) - semiformally** **verified design and tested**
+
+
+Objectives
+
+
+123 EAL6 permits developers to gain high assurance from application of security
+engineering techniques to a rigorous development environment in order to
+produce a premium TOE for protecting high value assets against significant
+risks.
+
+
+124 EAL6 is therefore applicable to the development of security TOEs for
+application in high risk situations where the value of the protected assets
+justifies the additional costs.
+
+
+Assurance components
+
+
+125 **EAL6** provides assurance by a full security target and an analysis of the
+SFRs in that ST, using a functional and complete interface specification,
+guidance documentation, the design of the TOE, and the implementation to
+understand the security behaviour. **Assurance** **is** **additionally** **gained**
+**through** **a** **formal** **model** **of** **select** **TOE** **security** **policies** **and** **a** **semiformal**
+**presentation** **of** **the** **functional** **specification** **and** **TOE** **design.** A modular,
+**layered** **and** **simple** TSF design is also required.
+
+
+126 The analysis is supported by independent testing of the TSF, evidence of
+developer testing based on the functional specification, TOE design,
+selective independent confirmation of the developer test results, and an
+independent vulnerability analysis demonstrating resistance to penetration
+attackers with a **high** attack potential.
+
+
+127 **EAL6** also provides assurance through the use of a **structured** development
+**process,** **development** environment controls, and comprehensive TOE
+configuration management including **complete** automation, and evidence of
+secure delivery procedures.
+
+
+128 This EAL represents a meaningful increase in assurance from **EAL5** by
+requiring **more** **comprehensive** **analysis,** a **structured** **representation** **of**
+**the** **implementation,** more **architectural** **structure** **(e.g.** **layering),** **more**
+**comprehensive** **independent** **vulnerability** **analysis,** and improved
+**configuration** **management** **and** development **environment** **controls.**
+
+
+April 2017 Version 3.1 Page 43 of 247
+
+
+**Evaluation assurance levels**
+
+
+
+
+
+
+
+
+
+
+
+
+
+|Assurance Class|Assurance components|
+|---|---|
+|ADV: Development|ADV_ARC.1 Security architecture description|
+|ADV: Development|ADV_FSP.5 Complete semi-formal functional
specification with additional error information|
+|ADV: Development|ADV_IMP.2 Complete mapping of the
implementation representation of the TSF|
+|ADV: Development|ADV_INT.3 Minimally complex internals|
+|ADV: Development|ADV_SPM.1 Formal TOE security policy
model|
+|ADV: Development|ADV_TDS.5 Complete semiformal modular
design|
+|AGD: Guidance documents|AGD_OPE.1 Operational user guidance|
+|AGD: Guidance documents|AGD_PRE.1 Preparative procedures|
+|ALC: Life-cycle support|ALC_CMC.5 Advanced support|
+|ALC: Life-cycle support|ALC_CMS.5 Development tools CM coverage|
+|ALC: Life-cycle support|ALC_DEL.1 Delivery procedures|
+|ALC: Life-cycle support|ALC_DVS.2 Sufficiency of security measures|
+|ALC: Life-cycle support|ALC_LCD.1 Developer defined life-cycle
model|
+|ALC: Life-cycle support|ALC_TAT.3 Compliance with implementation
standards - all parts|
+|ASE: Security Target evaluation|ASE_CCL.1 Conformance claims|
+|ASE: Security Target evaluation|ASE_ECD.1 Extended components definition|
+|ASE: Security Target evaluation|ASE_INT.1 ST introduction|
+|ASE: Security Target evaluation|ASE_OBJ.2 Security objectives|
+|ASE: Security Target evaluation|ASE_REQ.2 Derived security requirements|
+|ASE: Security Target evaluation|ASE_SPD.1 Security problem definition|
+|ASE: Security Target evaluation|ASE_TSS.1 TOE summary specification|
+|ATE: Tests|ATE_COV.3 Rigorous analysis of coverage|
+|ATE: Tests|ATE_DPT.3 Testing: modular design|
+|ATE: Tests|ATE_FUN.2 Ordered functional testing|
+|ATE: Tests|ATE_IND.2 Independent testing - sample|
+|AVA: Vulnerability assessment|AVA_VAN.5 Advanced methodical
vulnerability analysis|
+
+
+**Table 7 - EAL6**
+
+
+Page 44 of 247 Version 3.1 April 2017
+
+
+**Evaluation assurance levels**
+
+## **8.9 Evaluation assurance level 7 (EAL7) - formally verified** **design and tested**
+
+
+Objectives
+
+
+129 EAL7 is applicable to the development of security TOEs for application in
+extremely high risk situations and/or where the high value of the assets
+justifies the higher costs. Practical application of EAL7 is currently limited
+to TOEs with tightly focused security functionality that is amenable to
+extensive formal analysis.
+
+
+Assurance components
+
+
+130 **EAL7** provides assurance by a full security target and an analysis of the
+SFRs in that ST, using a functional and complete interface specification,
+guidance documentation, the design of the TOE, and **a** **structured**
+**presentation** **of** the implementation to understand the security behaviour.
+Assurance is additionally gained through a formal model of select TOE
+security policies and a semiformal presentation of the functional
+specification and TOE design. A modular, layered and simple TSF design is
+also required.
+
+
+131 The analysis is supported by independent testing of the TSF, evidence of
+developer testing based on the functional specification, TOE design **and**
+**implementation** **representation,** **complete** independent confirmation of the
+developer test results, and an independent vulnerability analysis
+demonstrating resistance to penetration attackers with a high attack potential.
+
+
+132 **EAL7** also provides assurance through the use of a structured development
+process, development environment controls, and comprehensive TOE
+configuration management including complete automation, and evidence of
+secure delivery procedures.
+
+
+133 This EAL represents a meaningful increase in assurance from **EAL6** by
+requiring more comprehensive analysis **using** **formal** **representations** and
+**formal** **correspondence,** and **comprehensive** **testing.**
+
+
+April 2017 Version 3.1 Page 45 of 247
+
+
+**Evaluation assurance levels**
+
+
+
+
+
+
+
+
+
+
+
+
+
+|Assurance Class|Assurance components|
+|---|---|
+|ADV: Development|ADV_ARC.1 Security architecture description|
+|ADV: Development|ADV_FSP.6 Complete semi-formal functional
specification with additional formal
specification|
+|ADV: Development|ADV_IMP.2 Complete mapping of the
implementation representation of the TSF|
+|ADV: Development|ADV_INT.3 Minimally complex internals|
+|ADV: Development|ADV_SPM.1 Formal TOE security policy
model|
+|ADV: Development|ADV_TDS.6 Complete semiformal modular
design with formal high-level design
presentation|
+|AGD: Guidance documents|AGD_OPE.1 Operational user guidance|
+|AGD: Guidance documents|AGD_PRE.1 Preparative procedures|
+|ALC: Life-cycle support|ALC_CMC.5 Advanced support|
+|ALC: Life-cycle support|ALC_CMS.5 Development tools CM coverage|
+|ALC: Life-cycle support|ALC_DEL.1 Delivery procedures|
+|ALC: Life-cycle support|ALC_DVS.2 Sufficiency of security measures|
+|ALC: Life-cycle support|ALC_LCD.2 Measurable life-cycle model|
+|ALC: Life-cycle support|ALC_TAT.3 Compliance with implementation
standards - all parts|
+|ASE: Security Target evaluation|ASE_CCL.1 Conformance claims|
+|ASE: Security Target evaluation|ASE_ECD.1 Extended components definition|
+|ASE: Security Target evaluation|ASE_INT.1 ST introduction|
+|ASE: Security Target evaluation|ASE_OBJ.2 Security objectives|
+|ASE: Security Target evaluation|ASE_REQ.2 Derived security requirements|
+|ASE: Security Target evaluation|ASE_SPD.1 Security problem definition|
+|ASE: Security Target evaluation|ASE_TSS.1 TOE summary specification|
+|ATE: Tests|ATE_COV.3 Rigorous analysis of coverage|
+|ATE: Tests|ATE_DPT.4 Testing: implementation
representation|
+|ATE: Tests|ATE_FUN.2 Ordered functional testing|
+|ATE: Tests|ATE_IND.3 Independent testing - complete|
+|AVA: Vulnerability assessment|AVA_VAN.5 Advanced methodical
vulnerability analysis|
+
+
+**Table 8 - EAL7**
+
+
+Page 46 of 247 Version 3.1 April 2017
+
+
+**Composed assurance packages**
+
+# **9 Composed assurance packages**
+
+
+134 The Composed Assurance Packages (CAPs) provide an increasing scale that
+balances the level of assurance obtained with the cost and feasibility of
+acquiring that degree of assurance for composed TOEs.
+
+
+135 It is important to note that there are only a small number of families and
+components from CC Part 3 included in the CAPs. This is due to their nature
+of building upon evaluation results of previously evaluated entities (base
+components and dependent components), and is not to say that these do not
+provide meaningful and desirable assurances.
+
+## **9.1 Composed assurance package (CAP) overview**
+
+
+136 CAPs are to be applied to composed TOEs, which are comprised of
+components that have been (are going through) component TOE evaluation
+(see Annex B). The individual components will have been certified to an
+EAL or another assurance package specified in the ST. It is expected that a
+basic level of assurance in a composed TOE will be gained through
+application of EAL1, which can be achieved with information about the
+components that is generally available in the public domain. (EAL1 can be
+applied as specified within to both component and composed TOEs.) CAPs
+provide an alternative approach to obtaining higher levels of assurance for a
+composed TOE than application of the EALs above EAL1.
+
+
+137 While a dependent component can be evaluated using a previously evaluated
+and certified base component to satisfy the IT platform requirements in the
+environment, this does not provide any formal assurance of the interactions
+between the components or the possible introduction of vulnerabilities
+resulting from the composition. Composed assurance packages consider
+these interactions and, at higher levels of assurance, ensure that the interface
+between the components has itself been the subject of testing. A vulnerability
+analysis of the composed TOE is also performed to consider the possible
+introduction of vulnerabilities as a result of composing the components.
+
+
+138 Table 9 represents a summary of the CAPs. The columns represent a
+hierarchically ordered set of CAPs, while the rows represent assurance
+families. Each number in the resulting matrix identifies a specific assurance
+component where applicable.
+
+
+139 As outlined in the next Section, three hierarchically ordered composed
+assurance packages are defined in the CC for the rating of a composed TOE's
+assurance. They are hierarchically ordered inasmuch as each CAP represents
+more assurance than all lower CAPs. The increase in assurance from CAP to
+CAP is accomplished by substitution of a hierarchically higher assurance
+component from the same assurance family (i.e. increasing rigour, scope,
+and/or depth) and from the addition of assurance components from other
+assurance families (i.e. adding new requirements). These increases result in
+
+
+April 2017 Version 3.1 Page 47 of 247
+
+
+**Composed assurance packages**
+
+
+greater analysis of the composition to identify the impact on the evaluation
+results gained for the individual component TOEs.
+
+
+140 These CAPs consist of an appropriate combination of assurance components
+as described in Chapter 7 of this CC Part 3. More precisely, each CAP
+includes no more than one component of each assurance family and all
+assurance dependencies of every component are addressed.
+
+
+141 The CAPs only consider resistance against an attacker with an attack
+potential up to Enhanced-Basic. This is due to the level of design information
+that can be provided through the ACO_DEV, limiting some of the factors
+associated with attack potential (knowledge of the composed TOE) and
+subsequently affecting the rigour of vulnerability analysis that can be
+performed by the evaluator. Therefore, the level of assurance in the
+composed TOE is limited, although the assurance in the individual
+components within the composed TOE may be much higher.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+|Assurance class|Assurance
Family|Assurance Components by
Composition Assurance
Package|Col4|Col5|
+|---|---|---|---|---|
+|Assurance class|Assurance
Family|CAP-A|CAP-B|CAP-C|
+|Composition|ACO_COR|**1**|1|1|
+|Composition|ACO_CTT|**1**|**2**|2|
+|Composition|ACO_DEV|**1**|**2**|**3**|
+|Composition|ACO_REL|**1**|1|**2**|
+|Composition|ACO_VUL|**1**|**2**|**3**|
+|Guidance
documents|AGD_OPE|**1**|1|1|
+|Guidance
documents|AGD_PRE|**1**|1|1|
+|Life-cycle
support|ALC_CMC|**1**|1|1|
+|Life-cycle
support|ALC_CMS|**2**|2|2|
+|Life-cycle
support|ALC_DEL||||
+|Life-cycle
support|ALC_DVS||||
+|Life-cycle
support|ALC_FLR||||
+|Life-cycle
support|ALC_LCD||||
+|Life-cycle
support|ALC_TAT||||
+|Security Target
evaluation|ASE_CCL|**1**|1|1|
+|Security Target
evaluation|ASE_ECD|**1**|1|1|
+|Security Target
evaluation|ASE_INT|**1**|1|1|
+|Security Target
evaluation|ASE_OBJ|**1**|**2**|2|
+|Security Target
evaluation|ASE_REQ|**1**|**2**|2|
+|Security Target
evaluation|ASE_SPD||**1**|1|
+|Security Target
evaluation|ASE_TSS|**1**|1|1|
+
+
+
+**Table 9 - Composition assurance level summary**
+
+
+Page 48 of 247 Version 3.1 April 2017
+
+
+**Composed assurance packages**
+
+## **9.2 Composed assurance package details**
+
+
+142 The following Sections provide definitions of the CAPs, highlighting
+differences between the specific requirements and the prose characterisations
+of those requirements using bold type.
+
+
+April 2017 Version 3.1 Page 49 of 247
+
+
+**Composed assurance packages**
+
+## **9.3 Composition assurance level A (CAP-A) - Structurally** **composed**
+
+
+Objectives
+
+
+143 CAP-A is applicable when a composed TOE is integrated and confidence in
+the correct security operation of the resulting composite is required. This
+requires the cooperation of the developer of the dependent component in
+terms of delivery of design information and test results from the dependent
+component certification, without requiring the involvement of the base
+component developer.
+
+
+144 CAP-A is therefore applicable in those circumstances where developers or
+users require a low to moderate level of independently assured security in the
+absence of ready availability of the complete development record.
+
+
+Assurance components
+
+
+145 **CAP-A provides assurance by analysis of a security target for the**
+**composed TOE. The SFRs in the composed TOE ST are analysed using**
+**the outputs from the evaluations of the component TOEs (e.g. ST,**
+**guidance documentation) and a specification for the interfaces between**
+**the component TOEs in the composed TOE to understand the security**
+**behaviour.**
+
+
+146 **The analysis is supported by independent testing of the interfaces of the**
+**base component that are relied upon by the dependent component, as**
+**described in the reliance information, evidence of developer testing**
+**based on the reliance information, development information and**
+**composition rationale, and selective independent confirmation of the**
+**developer test results. The analysis is also supported by a vulnerability**
+**review of the composed TOE by the evaluator.**
+
+
+147 **CAP-A also provides assurance through unique identification of the**
+**composed TOE (i.e. IT TOE and guidance documentation).**
+
+
+Page 50 of 247 Version 3.1 April 2017
+
+
+**Composed assurance packages**
+
+
+
+
+
+
+
+
+
+
+
+
+|Assurance Class|Assurance components|
+|---|---|
+|ACO: Composition|ACO_COR.1 Composition rationale|
+|ACO: Composition|ACO_CTT.1 Interface testing|
+|ACO: Composition|ACO_DEV.1 Functional Description|
+|ACO: Composition|ACO_REL.1 Basic reliance information|
+|ACO: Composition|ACO_VUL.1 Composition vulnerability review|
+|AGD: Guidance documents|AGD_OPE.1 Operational user guidance|
+|AGD: Guidance documents|AGD_PRE.1 Preparative procedures|
+|ALC: Life-cycle support|ALC_CMC.1 Labelling of the TOE|
+|ALC: Life-cycle support|ALC_CMS.2 Parts of the TOE CM coverage|
+|ASE: Security Target evaluation|ASE_CCL.1 Conformance claims|
+|ASE: Security Target evaluation|ASE_ECD.1 Extended components definition|
+|ASE: Security Target evaluation|ASE_INT.1 ST introduction|
+|ASE: Security Target evaluation|ASE_OBJ.1 Security objectives for the
operational environment|
+|ASE: Security Target evaluation|ASE_REQ.1 Stated security requirements|
+|ASE: Security Target evaluation|ASE_TSS.1 TOE summary specification|
+
+
+
+**Table 10 - CAP-A**
+
+
+April 2017 Version 3.1 Page 51 of 247
+
+
+**Composed assurance packages**
+
+## **9.4 Composition assurance level B (CAP-B) - Methodically** **composed**
+
+
+Objectives
+
+
+148 CAP-B permits a conscientious developer to gain maximum assurance from
+understanding, at a subsystem level, the affects of interactions between
+component TOEs integrated in the composed TOE, whilst minimising the
+demand of involvement of the base component developer.
+
+
+149 CAP-B is applicable in those circumstances where developers or users
+require a moderate level of independently assured security, and require a
+thorough investigation of the composed TOE and its development without
+substantial re-engineering.
+
+
+Assurance components
+
+
+150 **CAP-B** provides assurance by analysis of a **full** security target for the
+composed TOE. The SFRs in the composed TOE ST are analysed using the
+outputs from the evaluations of the component TOEs (e.g. ST, guidance
+documentation), a specification for the interfaces between the component
+TOEs **and** **the** **TOE** **design** **(describing** **TSF** **subsystems)** **contained** in the
+composed **development** **information** to understand the security behaviour.
+
+
+151 The analysis is supported by independent testing of the interfaces of the base
+component that are relied upon by the dependent component, as described in
+the reliance information **(now** **also** **including** **TOE** **design),** evidence of
+developer testing based on the reliance information, development
+information and composition rationale, and selective independent
+confirmation of the developer test results. The analysis is also supported by a
+vulnerability **analysis** of the composed TOE by the evaluator **demonstrating**
+**resistance** **to** **attackers** **with** **basic** **attack** **potential.**
+
+
+152 **This** **CAP** **represents** **a** **meaningful** **increase** **in** **assurance** **from** CAP-A **by**
+**requiring** **more** **complete** **testing** **coverage** of the **security** **functionality.**
+
+
+Page 52 of 247 Version 3.1 April 2017
+
+
+**Composed assurance packages**
+
+
+
+
+
+
+
+
+
+
+
+
+|Assurance Class|Assurance components|
+|---|---|
+|ACO: Composition|ACO_COR.1 Composition rationale|
+|ACO: Composition|ACO_CTT.2 Rigorous interface testing|
+|ACO: Composition|ACO_DEV.2 Basic evidence of design|
+|ACO: Composition|ACO_REL.1 Basic reliance information|
+|ACO: Composition|ACO_VUL.2 Composition vulnerability
analysis|
+|AGD: Guidance documents|AGD_OPE.1 Operational user guidance|
+|AGD: Guidance documents|AGD_PRE.1 Preparative procedures|
+|ALC: Life-cycle support|ALC_CMC.1 Labelling of the TOE|
+|ALC: Life-cycle support|ALC_CMS.2 Parts of the TOE CM coverage|
+|ASE: Security Target evaluation|ASE_CCL.1 Conformance claims|
+|ASE: Security Target evaluation|ASE_ECD.1 Extended components definition|
+|ASE: Security Target evaluation|ASE_INT.1 ST introduction|
+|ASE: Security Target evaluation|ASE_OBJ.2 Security objectives|
+|ASE: Security Target evaluation|ASE_REQ.2 Derived security requirements|
+|ASE: Security Target evaluation|ASE_SPD.1 Security problem definition|
+|ASE: Security Target evaluation|ASE_TSS.1 TOE summary specification|
+
+
+
+**Table 11 - CAP-B**
+
+
+April 2017 Version 3.1 Page 53 of 247
+
+
+**Composed assurance packages**
+
+## **9.5 Composition assurance level C (CAP-C) - Methodically** **composed, tested and reviewed**
+
+
+Objectives
+
+
+153 CAP-C permits a developer to gain maximum assurance from positive
+analysis of the interactions between the components of the composed TOE,
+which, though rigorous, do not require full access to all evaluation evidence
+of the base component.
+
+
+154 CAP-C is therefore applicable in those circumstances where developers or
+users require a moderate to high level of independently assured security in
+conventional commodity composed TOEs and are prepared to incur
+additional security-specific engineering costs.
+
+
+Assurance components
+
+
+155 **CAP-C** provides assurance by analysis of a full security target for the
+composed TOE. The SFRs in the composed TOE ST are analysed using the
+outputs from the evaluations of the component TOEs (e.g. ST, guidance
+documentation), a specification for the interfaces between the component
+TOEs and the TOE design (describing TSF **modules)** contained in the
+composed development information to understand the security behaviour.
+
+
+156 The analysis is supported by independent testing of the interfaces of the base
+component that are relied upon by the dependent component, as described in
+the reliance information (now including TOE design), evidence of developer
+testing based on the reliance information, development information and
+composition rationale, and selective independent confirmation of the
+developer test results. The analysis is also supported by a vulnerability
+analysis of the composed TOE by the evaluator demonstrating resistance to
+attackers with **Enhanced-Basic** attack potential.
+
+
+157 This CAP represents a meaningful increase in assurance from **CAP-B** by
+requiring more **design** **description** **and** **demonstration** of **resistance** **to** **a**
+**higher** **attack** **potential.**
+
+
+Page 54 of 247 Version 3.1 April 2017
+
+
+**Composed assurance packages**
+
+
+
+
+
+
+
+
+
+
+
+
+|Assurance Class|Assurance components|
+|---|---|
+|ACO: Composition|ACO_COR.1 Composition rationale|
+|ACO: Composition|ACO_CTT.2 Rigorous interface testing|
+|ACO: Composition|ACO_DEV.3 Detailed evidence of design|
+|ACO: Composition|ACO_REL.2 Reliance information|
+|ACO: Composition|ACO_VUL.3 Enhanced-Basic Composition
vulnerability analysis|
+|AGD: Guidance documents|AGD_OPE.1 Operational user guidance|
+|AGD: Guidance documents|AGD_PRE.1 Preparative procedures|
+|ALC: Life-cycle support|ALC_CMC.1 Labelling of the TOE|
+|ALC: Life-cycle support|ALC_CMS.2 Parts of the TOE CM coverage|
+|ASE: Security Target evaluation|ASE_CCL.1 Conformance claims|
+|ASE: Security Target evaluation|ASE_ECD.1 Extended components definition|
+|ASE: Security Target evaluation|ASE_INT.1 ST introduction|
+|ASE: Security Target evaluation|ASE_OBJ.2 Security objectives|
+|ASE: Security Target evaluation|ASE_REQ.2 Derived security requirements|
+|ASE: Security Target evaluation|ASE_SPD.1 Security problem definition|
+|ASE: Security Target evaluation|ASE_TSS.1 TOE summary specification|
+
+
+
+**Table 12 - CAP-C**
+
+
+April 2017 Version 3.1 Page 55 of 247
+
+
+**Class APE: Protection Profile evaluation**
+
+# **10 Class APE: Protection Profile evaluation**
+
+
+158 Evaluating a PP is required to demonstrate that the PP is sound and internally
+consistent, and, if the PP is based on one or more other PPs or on packages,
+that the PP is a correct instantiation of these PPs and packages. These
+properties are necessary for the PP to be suitable for use as the basis for
+writing an ST or another PP.
+
+
+159 This Chapter should be used in conjunction with Annexes A, B and C in CC
+Part 1, as these Annexes clarify the concepts here and provide many
+examples.
+
+
+160 This standard defines two assurance packages for PP evaluation as follows:
+
+
+a) Low assurance PP evaluation package;
+
+
+b) (Standard) PP evaluation package.
+
+
+161 The assurance components for these packages are defined by table 13.
+
+
+
+
+
+
+
+
+
+
+|Assurance class|Assurance
family|Assurance component|Col4|
+|---|---|---|---|
+|Assurance class|Assurance
family|Low Assurance
PP|PP|
+|Protection Profile
evaluation|APE_CCL|**1**|1|
+|Protection Profile
evaluation|APE_ECD|**1**|1|
+|Protection Profile
evaluation|APE_INT|**1**|1|
+|Protection Profile
evaluation|APE_OBJ|**1**|**2**|
+|Protection Profile
evaluation|APE_REQ|**1**|**2**|
+|Protection Profile
evaluation|APE_SPD||**1**|
+
+
+
+**Table 13 - PP assurance packages**
+
+
+162 Figure 8 shows the families within this class, and the hierarchy of
+components within the families.
+
+
+Page 56 of 247 Version 3.1 April 2017
+
+
+**Class APE: Protection Profile evaluation**
+
+
+**Figure 8 - APE: Protection Profile evaluation class decomposition**
+
+
+April 2017 Version 3.1 Page 57 of 247
+
+
+**Class APE: Protection Profile evaluation**
+
+## **10.1 PP introduction (APE_INT)**
+
+
+Objectives
+
+
+163 The objective of this family is to describe the TOE in a narrative way.
+
+
+164 Evaluation of the PP introduction is required to demonstrate that the PP is
+correctly identified, and that the PP reference and TOE overview are
+consistent with each other.
+
+
+**APE_INT.1** **PP introduction**
+
+
+Dependencies: No dependencies.
+
+
+Developer action elements:
+
+
+**APE_INT.1.1D** **The developer shall provide a PP introduction.**
+
+
+Content and presentation elements:
+
+
+**APE_INT.1.1C** **The PP introduction shall contain a PP reference and a TOE overview.**
+
+
+**APE_INT.1.2C** **The PP reference shall uniquely identify the PP.**
+
+
+**APE_INT.1.3C** **The TOE overview shall summarise the usage and major security**
+**features of the TOE.**
+
+
+**APE_INT.1.4C** **The TOE overview shall identify the TOE type.**
+
+
+**APE_INT.1.5C** **The** **TOE** **overview** **shall** **identify** **any** **non-TOE**
+**hardware/software/firmware available to the TOE.**
+
+
+Evaluator action elements:
+
+
+**APE_INT.1.1E** **The evaluator** _**shall confirm**_ **that the information provided meets all**
+**requirements for content and presentation of evidence.**
+
+
+Page 58 of 247 Version 3.1 April 2017
+
+
+**Class APE: Protection Profile evaluation**
+
+## **10.2 Conformance claims (APE_CCL)**
+
+
+Objectives
+
+
+165 The objective of this family is to determine the validity of the conformance
+claim. In addition, this family specifies how STs and other PPs are to claim
+conformance with the PP.
+
+
+**APE_CCL.1** **Conformance claims**
+
+
+Dependencies: APE_INT.1 PP introduction
+APE_ECD.1 Extended components definition
+APE_REQ.1 Stated security requirements
+
+
+Developer action elements:
+
+
+**APE_CCL.1.1D** **The developer shall provide a conformance claim.**
+
+
+**APE_CCL.1.2D** **The developer shall provide a conformance claim rationale.**
+
+
+**APE_CCL.1.3D** **The developer shall provide a conformance statement.**
+
+
+Content and presentation elements:
+
+
+**APE_CCL.1.1C** **The conformance claim shall contain a CC conformance claim that**
+
+**identifies the version of the CC to which the PP claims conformance.**
+
+
+**APE_CCL.1.2C** **The CC conformance claim shall describe the conformance of the PP to**
+
+**CC Part 2 as either CC Part 2 conformant or CC Part 2 extended.**
+
+
+**APE_CCL.1.3C** **The CC conformance claim shall describe the conformance of the PP to**
+
+**CC Part 3 as either CC Part 3 conformant or CC Part 3 extended.**
+
+
+**APE_CCL.1.4C** **The CC conformance claim shall be consistent with the extended**
+
+**components definition.**
+
+
+**APE_CCL.1.5C** **The conformance claim shall identify all PPs and security requirement**
+
+**packages to which the PP claims conformance.**
+
+
+**APE_CCL.1.6C** **The conformance claim shall describe any conformance of the PP to a**
+
+**package as either package-conformant or package-augmented.**
+
+
+**APE_CCL.1.7C** **The conformance claim rationale shall demonstrate that the TOE type is**
+
+**consistent with the TOE type in the PPs for which conformance is being**
+**claimed.**
+
+
+**APE_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.**
+
+
+April 2017 Version 3.1 Page 59 of 247
+
+
+**Class APE: Protection Profile evaluation**
+
+
+**APE_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.**
+
+
+**APE_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.**
+
+
+**APE_CCL.1.11C** **The conformance statement shall describe the conformance required of**
+
+**any PPs/STs to the PP as strict-PP or demonstrable-PP conformance.**
+
+
+Evaluator action elements:
+
+
+**APE_CCL.1.1E** **The evaluator** _**shall confirm**_ **that the information provided meets all**
+
+**requirements for content and presentation of evidence.**
+
+
+Page 60 of 247 Version 3.1 April 2017
+
+
+**Class APE: Protection Profile evaluation**
+
+## **10.3 Security problem definition (APE_SPD)**
+
+
+Objectives
+
+
+166 This part of the PP defines the security problem to be addressed by the TOE
+and the operational environment of the TOE.
+
+
+167 Evaluation of the security problem definition is required to demonstrate that
+the security problem intended to be addressed by the TOE and its operational
+environment, is clearly defined.
+
+
+**APE_SPD.1** **Security problem definition**
+
+
+Dependencies: No dependencies.
+
+
+Developer action elements:
+
+
+**APE_SPD.1.1D** **The developer shall provide a security problem definition.**
+
+
+Content and presentation elements:
+
+
+**APE_SPD.1.1C** **The security problem definition shall describe the threats.**
+
+
+**APE_SPD.1.2C** **All threats shall be described in terms of a threat agent, an asset, and an**
+
+**adverse action.**
+
+
+**APE_SPD.1.3C** **The security problem definition shall describe the OSPs.**
+
+
+**APE_SPD.1.4C** **The security problem definition shall describe the assumptions about the**
+
+**operational environment of the TOE.**
+
+
+Evaluator action elements:
+
+
+**APE_SPD.1.1E** **The evaluator** _**shall confirm**_ **that the information provided meets all**
+**requirements for content and presentation of evidence.**
+
+
+April 2017 Version 3.1 Page 61 of 247
+
+
+**Class APE: Protection Profile evaluation**
+
+## **10.4 Security objectives (APE_OBJ)**
+
+
+Objectives
+
+
+168 The security objectives are a concise statement of the intended response to
+the security problem defined through the Security problem definition
+(APE_SPD) family.
+
+
+169 Evaluation of the security objectives is required to demonstrate that the
+security objectives adequately and completely address the security problem
+definition and that the division of this problem between the TOE and its
+operational environment is clearly defined.
+
+
+Component levelling
+
+
+170 The components in this family are levelled on whether they prescribe only
+security objectives for the operational environment, or also security
+objectives for the TOE.
+
+
+**APE_OBJ.1** **Security objectives for the operational environment**
+
+
+Dependencies: No dependencies.
+
+
+Developer action elements:
+
+
+**APE_OBJ.1.1D** **The developer shall provide a statement of security objectives.**
+
+
+Content and presentation elements:
+
+
+**APE_OBJ.1.1C** **The statement of security objectives shall describe the security objectives**
+
+**for the operational environment.**
+
+
+Evaluator action elements:
+
+
+**APE_OBJ.1.1E** **The evaluator** _**shall confirm**_ **that the information provided meets all**
+
+**requirements for content and presentation of evidence.**
+
+
+**APE_OBJ.2** **Security objectives**
+
+
+Dependencies: APE_SPD.1 Security problem definition
+
+
+Developer action elements:
+
+
+**APE_OBJ.2.1D** The developer shall provide a statement of security objectives.
+
+
+**APE_OBJ.2.2D** **The developer shall provide a security objectives rationale.**
+
+
+Content and presentation elements:
+
+
+**APE_OBJ.2.1C** The statement of security objectives shall describe the security objectives for
+
+the **TOE** **and** **the** **security** **objectives** **for** **the** operational environment.
+
+
+Page 62 of 247 Version 3.1 April 2017
+
+
+**Class APE: Protection Profile evaluation**
+
+
+**APE_OBJ.2.2C** **The security objectives rationale shall trace each security objective for**
+
+**the TOE back to threats countered by that security objective and OSPs**
+**enforced by that security objective.**
+
+
+**APE_OBJ.2.3C** **The security objectives rationale shall trace each security objective for**
+
+**the operational environment back to threats countered by that security**
+**objective, OSPs enforced by that security objective, and assumptions**
+**upheld by that security objective.**
+
+
+**APE_OBJ.2.4C** **The security objectives rationale shall demonstrate that the security**
+
+**objectives counter all threats.**
+
+
+**APE_OBJ.2.5C** **The security objectives rationale shall demonstrate that the security**
+
+**objectives enforce all OSPs.**
+
+
+**APE_OBJ.2.6C** **The security objectives rationale shall demonstrate that the security**
+
+**objectives for the operational environment uphold all assumptions.**
+
+
+Evaluator action elements:
+
+
+**APE_OBJ.2.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+April 2017 Version 3.1 Page 63 of 247
+
+
+**Class APE: Protection Profile evaluation**
+
+## **10.5 Extended components definition (APE_ECD)**
+
+
+Objectives
+
+
+171 Extended security requirements are requirements that are not based on
+components from CC Part 2 or CC Part 3, but are based on extended
+components: components defined by the PP author.
+
+
+172 Evaluation of the definition of extended components is necessary to
+determine that they are clear and unambiguous, and that they are necessary,
+i.e. they may not be clearly expressed using existing CC Part 2 or CC Part 3
+components.
+
+
+**APE_ECD.1** **Extended components definition**
+
+
+Dependencies: No dependencies.
+
+
+Developer action elements:
+
+
+**APE_ECD.1.1D** **The developer shall provide a statement of security requirements.**
+
+
+**APE_ECD.1.2D** **The developer shall provide an extended components definition.**
+
+
+Content and presentation elements:
+
+
+**APE_ECD.1.1C** **The statement of security requirements shall identify all extended**
+
+**security requirements.**
+
+
+**APE_ECD.1.2C** **The extended components definition shall define an extended component**
+
+**for each extended security requirement.**
+
+
+**APE_ECD.1.3C** **The extended components definition shall describe how each extended**
+
+**component is related to the existing CC components, families, and**
+**classes.**
+
+
+**APE_ECD.1.4C** **The extended components definition shall use the existing CC**
+
+**components, families, classes, and methodology as a model for**
+**presentation.**
+
+
+**APE_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:
+
+
+**APE_ECD.1.1E** **The evaluator** _**shall confirm**_ **that the information provided meets all**
+
+**requirements for content and presentation of evidence.**
+
+
+**APE_ECD.1.2E** **The evaluator** _**shall confirm**_ **that no extended component may be clearly**
+
+**expressed using existing components.**
+
+
+Page 64 of 247 Version 3.1 April 2017
+
+
+**Class APE: Protection Profile evaluation**
+
+## **10.6 Security requirements (APE_REQ)**
+
+
+Objectives
+
+
+173 The SFRs form a clear, unambiguous and well-defined description of the
+expected security behaviour of the TOE. The SARs form a clear,
+unambiguous and well-defined description of the expected activities that will
+be undertaken to gain assurance in the TOE.
+
+
+174 Evaluation of the security requirements is required to ensure that they are
+clear, unambiguous and well-defined.
+
+
+Component levelling
+
+
+175 The components in this family are levelled on whether they are stated as is,
+or whether the SFRs are derived from security objectives for the TOE.
+
+
+**APE_REQ.1** **Stated security requirements**
+
+
+Dependencies: APE_ECD.1 Extended components definition
+
+
+Developer action elements:
+
+
+**APE_REQ.1.1D** **The developer shall provide a statement of security requirements.**
+
+
+**APE_REQ.1.2D** **The developer shall provide a security requirements rationale.**
+
+
+Content and presentation elements:
+
+
+**APE_REQ.1.1C** **The statement of security requirements shall describe the SFRs and the**
+
+**SARs.**
+
+
+**APE_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.**
+
+
+**APE_REQ.1.3C** **The statement of security requirements shall identify all operations on**
+
+**the security requirements.**
+
+
+**APE_REQ.1.4C** **All operations shall be performed correctly.**
+
+
+**APE_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.**
+
+
+**APE_REQ.1.6C** **The statement of security requirements shall be internally consistent.**
+
+
+Evaluator action elements:
+
+
+**APE_REQ.1.1E** **The evaluator** _**shall confirm**_ **that the information provided meets all**
+
+**requirements for content and presentation of evidence.**
+
+
+April 2017 Version 3.1 Page 65 of 247
+
+
+**Class APE: Protection Profile evaluation**
+
+
+**APE_REQ.2** **Derived security requirements**
+
+
+Dependencies: APE_OBJ.2 Security objectives
+APE_ECD.1 Extended components definition
+
+
+Developer action elements:
+
+
+**APE_REQ.2.1D** The developer shall provide a statement of security requirements.
+
+
+**APE_REQ.2.2D** The developer shall provide a security requirements rationale.
+
+
+Content and presentation elements:
+
+
+**APE_REQ.2.1C** The statement of security requirements shall describe the SFRs and the SARs.
+
+
+**APE_REQ.2.2C** All subjects, objects, operations, security attributes, external entities and
+
+other terms that are used in the SFRs and the SARs shall be defined.
+
+
+**APE_REQ.2.3C** The statement of security requirements shall identify all operations on the
+
+security requirements.
+
+
+**APE_REQ.2.4C** All operations shall be performed correctly.
+
+
+**APE_REQ.2.5C** Each dependency of the security requirements shall either be satisfied, or the
+
+security requirements rationale shall justify the dependency not being
+satisfied.
+
+
+**APE_REQ.2.6C** **The security requirements rationale shall trace each SFR back to the**
+
+**security objectives for the TOE.**
+
+
+**APE_REQ.2.7C** **The security requirements rationale shall demonstrate that the SFRs**
+
+**meet all security objectives for the TOE.**
+
+
+**APE_REQ.2.8C** **The security requirements rationale shall explain why the SARs were**
+
+**chosen.**
+
+
+**APE_REQ.2.9C** The statement of security requirements shall be internally consistent.
+
+
+Evaluator action elements:
+
+
+**APE_REQ.2.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+Page 66 of 247 Version 3.1 April 2017
+
+
+**Class ACE: Protection Profile Configuration evaluation**
+
+# **11 Class ACE: Protection Profile** **Configuration evaluation**
+
+
+176 Evaluating a PP-Configuration is required to demonstrate that the PPConfiguration is sound and consistent. These properties are necessary for the
+PP-Configuration to be suitable for use as the basis for writing an ST or
+another PP or PP-Configuration.
+
+
+177 The class ACE is defined for the evaluation of a PP-Configuration composed
+of one or more PPs and one PP-Module.
+
+
+178 This Chapter should be used in conjunction with Annexes B and C in CC
+Part 1, as these Annexes clarify the concepts here and provide many
+examples.
+
+
+179 This standard does not define low assurance PP-Configuration evaluation
+package. There is only one assurance package for PP-Configuration
+evaluation, equivalent to Standard PP evaluation package.
+
+
+180 Figure 9 shows the families within this class, and the hierarchy of
+components within the families.
+
+
+**Figure 9 - ACE: Protection Profile Configuration evaluation class**
+
+**decomposition**
+
+
+April 2017 Version 3.1 Page 67 of 247
+
+
+**Class ACE: Protection Profile Configuration evaluation**
+
+
+181 The ACE class is based on APE.
+
+
+Page 68 of 247 Version 3.1 April 2017
+
+
+**Class ACE: Protection Profile Configuration evaluation**
+
+## **11.1 PP-Module introduction (ACE_INT)**
+
+
+Objectives
+
+
+182 The objective of this family is to describe the TOE in a narrative way.
+
+
+183 The objective of this sub-activity is to determine whether the PP-Module is
+correctly identified, and whether the PP-Module reference and TOE
+overview are consistent with each other.
+
+
+**ACE_INT.1** **PP-Module introduction**
+
+
+Dependencies: No dependencies.
+
+
+Application notes
+
+
+184 _All content and presentation elements of APE_INT.1 hold with PP-Module_
+_instead of PP._
+
+
+Developer action elements:
+
+
+**ACE_INT.1.1D** **The developer shall provide a PP-Module introduction.**
+
+
+Content and presentation elements:
+
+
+**ACE_INT.1.1C** **The PP-Module introduction shall uniquely identify all the Base-PPs on**
+
+**which the PP-Module relies, including their logical structuring and**
+**relationship to the PP-Module according to CC Part 1, section B.14.3.2.**
+
+
+**ACE_INT.1.2C** **The TOE overview shall identify the differences introduced by the PP-**
+
+**Module with respect to the TOE overview of its Base-PP(s).**
+
+
+Evaluator action elements:
+
+
+**ACE_INT.1.1E** **The evaluator** _**shall confirm**_ **that the information provided meets all**
+**requirements for content and presentation of evidence.**
+
+
+April 2017 Version 3.1 Page 69 of 247
+
+
+**Class ACE: Protection Profile Configuration evaluation**
+
+## **11.2 PP-Module conformance claims (ACE_CCL)**
+
+
+Objectives
+
+
+185 The objective of this family is to determine the validity of the conformance
+claim. Unlike standard Protection Profiles, a PP-Module cannot claim
+conformance to another PP or PP-Module, nor to CC part 3 or any SAR
+package.
+
+
+**ACE_CCL.1** **PP-Module conformance claims**
+
+
+Dependencies: ACE_INT.1 PP-Module introduction
+ACE_ECD.1 PP-Module extended components
+definition
+ACE_REQ.1 PP-Module security requirements
+
+
+Developer action elements:
+
+
+**ACE_CCL.1.1D** **The developer shall provide a conformance claim.**
+
+
+Content and presentation elements:
+
+
+**ACE_CCL.1.1C** **The conformance claim shall contain a CC conformance claim that**
+
+**identifies the version of the CC to which the PP-Module claims**
+**conformance.**
+
+
+**ACE_CCL.1.2C** **The CC conformance claim shall describe the conformance of the PP-**
+
+**Module to CC Part 2 as either CC Part 2 conformant or CC Part 2**
+**extended.**
+
+
+**ACE_CCL.1.3C** **The conformance claim shall identify all security functional requirement**
+
+**packages to which the PP-Module claims conformance**
+
+
+**ACE_CCL.1.4C** **The CC conformance claim shall be consistent with the extended**
+
+**components definition.**
+
+
+Evaluator action elements:
+
+
+**ACE_CCL.1.1E** **The evaluator** _**shall confirm**_ **that the information provided meets all**
+
+**requirements for content and presentation of evidence.**
+
+
+Page 70 of 247 Version 3.1 April 2017
+
+
+**Class ACE: Protection Profile Configuration evaluation**
+
+## **11.3 PP-Module Security problem definition (ACE_SPD)**
+
+
+**ACE_SPD.1** **PP-Module Security problem definition**
+
+
+Dependencies: No dependencies.
+
+
+Application notes
+
+
+186 _All content and presentation elements of APE_SPD.1 hold._
+
+
+April 2017 Version 3.1 Page 71 of 247
+
+
+**Class ACE: Protection Profile Configuration evaluation**
+
+## **11.4 PP-Module Security objectives (ACE_OBJ)**
+
+
+**ACE_OBJ.1** **PP-Module Security objectives**
+
+
+Dependencies: No dependencies.
+
+
+Application notes
+
+
+187 _All content and presentation elements of APE_OBJ.2 hold._
+
+
+Page 72 of 247 Version 3.1 April 2017
+
+
+**Class ACE: Protection Profile Configuration evaluation**
+
+## **11.5 PP-Module extended components definition (ACE_ECD)**
+
+
+Objectives
+
+
+188 Extended security functional requirements are requirements that are not
+based on components from CC Part 2, but are based on extended
+components: components defined by the PP-Module author.
+
+
+189 Evaluation of the definition of extended functional components is necessary
+to determine that they are clear and unambiguous, and that they are necessary,
+i.e. they may not be clearly expressed using existing CC Part 2 components.
+
+
+**ACE_ECD.1** **PP-Module extended components definition**
+
+
+Dependencies: No dependencies.
+
+
+Developer action elements:
+
+
+**ACE_ECD.1.1D** **The developer shall provide a statement of security functional**
+
+**requirements.**
+
+
+**ACE_ECD.1.2D** **The developer shall provide an extended functional components**
+
+**definition.**
+
+
+Content and presentation elements:
+
+
+**ACE_ECD.1.1C** **The statement of security functional requirements shall identify all**
+
+**extended security functional requirements.**
+
+
+**ACE_ECD.1.2C** **The extended functional components definition shall define an extended**
+
+**functional component for each extended security functional requirement.**
+
+
+**ACE_ECD.1.3C** **The extended functional components definition shall describe how each**
+
+**extended functional component is related to the existing CC Part 2**
+**components, families, and classes.**
+
+
+**ACE_ECD.1.4C** **The extended functional components definition shall use the existing CC**
+
+**Part 2 components, families, classes, and methodology as a model for**
+**presentation.**
+
+
+**ACE_ECD.1.5C** **The extended functional components shall consist of measurable and**
+
+**objective elements such that conformance or nonconformance to these**
+**elements can be demonstrated.**
+
+
+Evaluator action elements:
+
+
+**ACE_ECD.1.1E** **The evaluator** _**shall confirm**_ **that the information provided meets all**
+
+**requirements for content and presentation of evidence.**
+
+
+**ACE_ECD.1.2E** **The evaluator** _**shall confirm**_ **that no extended functional component may**
+
+**be clearly expressed using existing components.**
+
+
+April 2017 Version 3.1 Page 73 of 247
+
+
+**Class ACE: Protection Profile Configuration evaluation**
+
+## **11.6 PP-Module security requirements (ACE_REQ)**
+
+
+Objectives
+
+
+190 The SFRs form a clear, unambiguous and well-defined description of the
+expected security behaviour of the TOE.
+
+
+191 Evaluation of the security functional requirements is required to ensure that
+they are clear, unambiguous and well-defined.
+
+
+**ACE_REQ.1** **PP-Module security requirements**
+
+
+Dependencies: ACE_ECD.1 PP-Module extended components
+definition
+ACE_OBJ.1 PP-Module Security objectives
+
+
+Developer action elements:
+
+
+**ACE_REQ.1.1D** **The developer shall provide a statement of security functional**
+
+**requirements.**
+
+
+**ACE_REQ.1.2D** **The developer shall provide a security requirements rationale.**
+
+
+Content and presentation elements:
+
+
+**ACE_REQ.1.1C** **The statement of security requirements shall describe the SFRs that**
+
+**hold on the TOE.**
+
+
+**ACE_REQ.1.2C** **All subjects, objects, operations, security attributes, external entities and**
+
+**other terms that are used in the SFRs shall be defined.**
+
+
+**ACE_REQ.1.3C** **The statement of security functional requirements shall identify all**
+
+**operations on the security functional requirements.**
+
+
+**ACE_REQ.1.4C** **All operations shall be performed correctly.**
+
+
+**ACE_REQ.1.5C** **Each dependency of the security functional requirements shall either be**
+
+**satisfied, or the security functional requirements rationale shall justify**
+**the dependency not being satisfied.**
+
+
+**ACE_REQ.1.6C** **The security functional requirements rationale shall trace each SFR**
+
+**back to the security objectives for the TOE.**
+
+
+**ACE_REQ.1.7C** **The security functional requirements rationale shall demonstrate that**
+
+**the SFRs meet all security objectives for the TOE.**
+
+
+Evaluator action elements:
+
+
+**ACE_REQ.1.1E** **The evaluator** _**shall confirm**_ **that the information provided meets all**
+
+**requirements for content and presentation of evidence.**
+
+
+Page 74 of 247 Version 3.1 April 2017
+
+
+**Class ACE: Protection Profile Configuration evaluation**
+
+## **11.7 PP-Module consistency (ACE_MCO)**
+
+
+Objectives
+
+
+192 The objective of this family is to determine the validity of the PP-Module.
+
+
+**ACE_MCO.1** **PP-Module consistency**
+
+
+Dependencies: ACE_INT.1 PP-Module introduction
+ACE_SPD.1 PP-Module Security problem definition
+ACE_OBJ.1 PP-Module Security objectives
+ACE_REQ.1 PP-Module security requirements
+
+
+Developer action elements:
+
+
+**ACE_MCO.1.1D** **The developer shall provide a consistency rationale of the PP-Module**
+
+**with respect to its Base-PP(s) identified in the PP-Module introduction.**
+**If the PP-Module specifies alternate sets of Base-PPs, the developer shall**
+**provide as many consistency rationales as the number of alternate set of**
+**Base-PPs.**
+
+
+Content and presentation elements:
+
+
+**ACE_MCO.1.1C** **The consistency rationale shall demonstrate that the TOE type of the**
+
+**PP-Module is consistent with the TOE type(s) in the Base-PPs identified**
+**in the PP-Module introduction.**
+
+
+**ACE_MCO.1.2C** **The consistency rationale shall demonstrate that the statement of the**
+
+**security problem definition is consistent with the statement of the**
+**security problem definition in the Base-PPs identified in the PP-Module**
+**introduction.**
+
+
+**ACE_MCO.1.3C** **The consistency rationale shall demonstrate that the statement of**
+
+**security objectives is consistent with the statement of security objectives**
+**in the Base-PPs identified in the PP-Module introduction.**
+
+
+**ACE_MCO.1.4C** **The consistency rationale shall demonstrate that the statement of**
+
+**security requirements is consistent with the statement of security**
+**requirements in the Base-PPs identified in the PP-Module introduction.**
+
+
+Evaluator action elements:
+
+
+**ACE_MCO.1.1E** **The evaluator** _**shall confirm**_ **that the information provided meets all**
+
+**requirements for content and presentation of evidence. If the PP-Module**
+**specifies alternate sets of Base-PPs, the evaluator** _**shall perform**_ **this**
+**action for each consistency rationale with its related Base-PPs in the**
+**alternate set of Base-PPs of the PP-Module.**
+
+
+April 2017 Version 3.1 Page 75 of 247
+
+
+**Class ACE: Protection Profile Configuration evaluation**
+
+## **11.8 PP-Configuration consistency (ACE_CCO)**
+
+
+Objectives
+
+
+193 The objective of this family is to determine the well-formedness and the
+consistency of the PP-Configuration.
+
+
+**ACE_CCO.1** **PP-Configuration consistency**
+
+
+Dependencies: ACE_INT.1 PP-Module introduction
+ACE_REQ.1 PP-Module security requirements
+ACE_MCO.1 PP-Module consistency
+
+
+Developer action elements:
+
+
+**ACE_CCO.1.1D** **The developer shall provide the reference of the PP-Configuration.**
+
+
+**ACE_CCO.1.2D** **The developer shall provide a components statement.**
+
+
+**ACE_CCO.1.3D** **The developer shall provide a conformance statement and a**
+
+**conformance claim.**
+
+
+**ACE_CCO.1.4D** **The developer shall provide a SAR statement.**
+
+
+Content and presentation elements:
+
+
+**ACE_CCO.1.1C** **The PP-Configuration reference shall uniquely identify the PP-**
+
+**Configuration.**
+
+
+**ACE_CCO.1.2C** **The components statements shall uniquely identify the Protection**
+
+**Profiles and the PP-Modules that compose the PP-Configuration.**
+
+
+**ACE_CCO.1.3C** **The conformance statement shall specify the kind of conformity of the**
+
+**PP-Configuration, either strict or demonstrable. The conformance claim**
+**shall contain a CC conformance claim that identifies the version of the**
+**CC to which the PP-Configuration and its underlying Base-PP(s) and**
+**PP-Module claim conformance.**
+
+
+**ACE_CCO.1.4C** **The SAR statement shall specify the set of SAR or predefined EAL that**
+
+**applies to this PP-Configuration.**
+
+
+**ACE_CCO.1.5C** **The Base-PP(s) on which the PP-Modules relies shall belong the**
+
+**Protection Profiles identified in the components statement of the PP-**
+**Configuration.**
+
+
+Evaluator action elements:
+
+
+**ACE_CCO.1.1E** **The evaluator** _**shall confirm**_ **that the information provided meets all**
+
+**requirements for content and presentation of evidence.**
+
+
+Page 76 of 247 Version 3.1 April 2017
+
+
+**Class ACE: Protection Profile Configuration evaluation**
+
+
+**ACE_CCO.1.2E** **The evaluator** _**shall check**_ **that the PP-Configuration made up of all the**
+
+**Protection Profiles and PP-Modules identified in the components**
+**statement of the PP-Configuration is consistent.**
+
+
+April 2017 Version 3.1 Page 77 of 247
+
+
+**Class ASE: Security Target evaluation**
+
+# **12 Class ASE: Security Target evaluation**
+
+
+194 Evaluating an ST is required to demonstrate that the ST is sound and
+internally consistent, and, if the ST is based on one or more PPs or packages,
+that the ST is a correct instantiation of these PPs and packages. These
+properties are necessary for the ST to be suitable for use as the basis for a
+TOE evaluation.
+
+
+195 This Chapter should be used in conjunction with Annexes A, B and C in CC
+Part 1, as these Annexes clarify the concepts here and provide many
+examples.
+
+
+196 Figure 10 shows the families within this class, and the hierarchy of
+components within the families.
+
+
+**Figure 10 - ASE: Security Target evaluation class decomposition**
+
+
+Page 78 of 247 Version 3.1 April 2017
+
+
+**Class ASE: Security Target evaluation**
+
+## **12.1 ST introduction (ASE_INT)**
+
+
+Objectives
+
+
+197 The objective of this family is to describe the TOE in a narrative way on
+three levels of abstraction: TOE reference, TOE overview and TOE
+description.
+
+
+198 Evaluation of the ST introduction is required to demonstrate that the ST and
+the TOE are correctly identified, that the TOE is correctly described at three
+levels of abstraction and that these three descriptions are consistent with each
+other.
+
+
+**ASE_INT.1** **ST introduction**
+
+
+Dependencies: No dependencies.
+
+
+Developer action elements:
+
+
+**ASE_INT.1.1D** **The developer shall provide an ST introduction.**
+
+
+Content and presentation elements:
+
+
+**ASE_INT.1.1C** **The ST introduction shall contain an 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 summarise the usage and major security**
+**features of the TOE.**
+
+
+**ASE_INT.1.5C** **The TOE overview shall identify the TOE type.**
+
+
+**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.**
+
+
+April 2017 Version 3.1 Page 79 of 247
+
+
+**Class ASE: Security Target evaluation**
+
+## **12.2 Conformance claims (ASE_CCL)**
+
+
+Objectives
+
+
+199 The objective of this family is to determine the validity of the conformance
+claim. In addition, this family specifies how STs are to claim conformance
+with the PP.
+
+
+**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**
+
+**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.**
+
+
+Page 80 of 247 Version 3.1 April 2017
+
+
+**Class ASE: Security Target evaluation**
+
+
+**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.**
+
+
+April 2017 Version 3.1 Page 81 of 247
+
+
+**Class ASE: Security Target evaluation**
+
+## **12.3 Security problem definition (ASE_SPD)**
+
+
+Objectives
+
+
+200 This part of the ST defines the security problem to be addressed by the TOE
+and the operational environment of the TOE.
+
+
+201 Evaluation of the security problem definition is required to demonstrate that
+the security problem intended to be addressed by the TOE and its operational
+environment, is clearly defined.
+
+
+**ASE_SPD.1** **Security problem definition**
+
+
+Dependencies: No dependencies.
+
+
+Developer action elements:
+
+
+**ASE_SPD.1.1D** **The developer shall provide a security problem definition.**
+
+
+Content and presentation elements:
+
+
+**ASE_SPD.1.1C** **The security problem definition shall describe the threats.**
+
+
+**ASE_SPD.1.2C** **All threats shall be described in terms of a threat agent, an asset, and an**
+**adverse action.**
+
+
+**ASE_SPD.1.3C** **The security problem definition shall describe the OSPs.**
+
+
+**ASE_SPD.1.4C** **The security problem definition shall describe the assumptions about the**
+**operational environment of the TOE.**
+
+
+Evaluator action elements:
+
+
+**ASE_SPD.1.1E** **The evaluator** _**shall confirm**_ **that the information provided meets all**
+**requirements for content and presentation of evidence.**
+
+
+Page 82 of 247 Version 3.1 April 2017
+
+
+**Class ASE: Security Target evaluation**
+
+## **12.4 Security objectives (ASE_OBJ)**
+
+
+Objectives
+
+
+202 The security objectives are a concise statement of the intended response to
+the security problem defined through the Security problem definition
+(ASE_SPD) family.
+
+
+203 Evaluation of the security objectives is required to demonstrate that the
+security objectives adequately and completely address the security problem
+definition, that the division of this problem between the TOE and its
+operational environment is clearly defined.
+
+
+Component levelling
+
+
+204 The components in this family are levelled on whether they prescribe only
+security objectives for the operational environment, or also security
+objectives for the TOE.
+
+
+**ASE_OBJ.1** **Security objectives for the operational environment**
+
+
+Dependencies: No dependencies.
+
+
+Developer action elements:
+
+
+**ASE_OBJ.1.1D** **The developer shall provide a statement of security objectives.**
+
+
+Content and presentation elements:
+
+
+**ASE_OBJ.1.1C** **The statement of security objectives shall describe the security objectives**
+
+**for the operational environment.**
+
+
+Evaluator action elements:
+
+
+**ASE_OBJ.1.1E** **The evaluator** _**shall confirm**_ **that the information provided meets all**
+**requirements for content and presentation of evidence.**
+
+
+**ASE_OBJ.2** **Security objectives**
+
+
+Dependencies: ASE_SPD.1 Security problem definition
+
+
+Developer action elements:
+
+
+**ASE_OBJ.2.1D** The developer shall provide a statement of security objectives.
+
+
+**ASE_OBJ.2.2D** **The developer shall provide a security objectives rationale.**
+
+
+Content and presentation elements:
+
+
+**ASE_OBJ.2.1C** **The statement of security objectives shall describe the security objectives**
+
+**for the TOE and the security objectives for the operational environment.**
+
+
+April 2017 Version 3.1 Page 83 of 247
+
+
+**Class ASE: Security Target evaluation**
+
+
+**ASE_OBJ.2.2C** **The security objectives rationale shall trace each security objective for**
+
+**the TOE back to threats countered by that security objective and OSPs**
+**enforced by that security objective.**
+
+
+**ASE_OBJ.2.3C** **The security objectives rationale shall trace each security objective for**
+
+**the operational environment back to threats countered by that security**
+**objective, OSPs enforced by that security objective, and assumptions**
+**upheld by that security objective.**
+
+
+**ASE_OBJ.2.4C** The security objectives **rationale** shall **demonstrate** **that** the security
+
+objectives **counter** **all** **threats.**
+
+
+**ASE_OBJ.2.5C** **The security objectives rationale shall demonstrate that the security**
+
+**objectives enforce all OSPs.**
+
+
+**ASE_OBJ.2.6C** **The security objectives rationale shall demonstrate that the security**
+
+**objectives for the operational environment uphold all assumptions.**
+
+
+Evaluator action elements:
+
+
+**ASE_OBJ.2.1E** The evaluator _**shall confirm**_ that the information provided meets all
+requirements for content and presentation of evidence.
+
+
+Page 84 of 247 Version 3.1 April 2017
+
+
+**Class ASE: Security Target evaluation**
+
+## **12.5 Extended components definition (ASE_ECD)**
+
+
+Objectives
+
+
+205 Extended security requirements are requirements that are not based on
+components from CC Part 2 or CC Part 3, but are based on extended
+components: components defined by the ST author.
+
+
+206 Evaluation of the definition of extended components is necessary to
+determine that they are clear and unambiguous, and that they are necessary,
+i.e. they may not be clearly expressed using existing CC Part 2 or CC Part 3
+components.
+
+
+**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:
+
+
+**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.**
+
+
+April 2017 Version 3.1 Page 85 of 247
+
+
+**Class ASE: Security Target evaluation**
+
+## **12.6 Security requirements (ASE_REQ)**
+
+
+Objectives
+
+
+207 The SFRs form a clear, unambiguous and well-defined description of the
+expected security behaviour of the TOE. The SARs form a clear,
+unambiguous and canonical description of the expected activities that will be
+undertaken to gain assurance in the TOE.
+
+
+208 Evaluation of the security requirements is required to ensure that they are
+clear, unambiguous and well-defined.
+
+
+Component levelling
+
+
+209 The components in this family are levelled on whether they are stated as is.
+
+
+**ASE_REQ.1** **Stated security requirements**
+
+
+Dependencies: 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.**
+
+
+**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.**
+
+
+Page 86 of 247 Version 3.1 April 2017
+
+
+**Class ASE: Security Target evaluation**
+
+
+**ASE_REQ.2** **Derived security requirements**
+
+
+Dependencies: ASE_OBJ.2 Security objectives
+ASE_ECD.1 Extended components definition
+
+
+Developer action elements:
+
+
+**ASE_REQ.2.1D** The developer shall provide a statement of security requirements.
+
+
+**ASE_REQ.2.2D** The developer shall provide a security requirements rationale.
+
+
+Content and presentation elements:
+
+
+**ASE_REQ.2.1C** The statement of security requirements shall describe the SFRs and the SARs.
+
+
+**ASE_REQ.2.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.2.3C** The statement of security requirements shall identify all operations on the
+
+security requirements.
+
+
+**ASE_REQ.2.4C** All operations shall be performed correctly.
+
+
+**ASE_REQ.2.5C** Each dependency of the security requirements shall either be satisfied, or the
+
+security requirements rationale shall justify the dependency not being
+satisfied.
+
+
+**ASE_REQ.2.6C** **The security requirements rationale shall trace each SFR back to the**
+
+**security objectives for the TOE.**
+
+
+**ASE_REQ.2.7C** **The security requirements rationale shall demonstrate that the SFRs**
+
+**meet all security objectives for the TOE.**
+
+
+**ASE_REQ.2.8C** **The security requirements rationale shall explain why the SARs were**
+
+**chosen.**
+
+
+**ASE_REQ.2.9C** The statement of security requirements shall be internally consistent.
+
+
+Evaluator action elements:
+
+
+**ASE_REQ.2.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+April 2017 Version 3.1 Page 87 of 247
+
+
+**Class ASE: Security Target evaluation**
+
+## **12.7 TOE summary specification (ASE_TSS)**
+
+
+Objectives
+
+
+210 The TOE summary specification enables evaluators and potential consumers
+to gain a general understanding of how the TOE is implemented.
+
+
+211 Evaluation of the TOE summary specification is necessary to determine
+whether it is adequately described how the TOE:
+
+
+๏ญ meets its SFRs;
+
+
+๏ญ protects itself against interference, logical tampering and bypass.
+
+
+and whether the TOE summary specification is consistent with other
+narrative descriptions of the TOE.
+
+
+Component levelling
+
+
+212 The components in this family are levelled on whether the TOE summary
+specification only needs to describe how the TOE meets the SFRs, or
+whether the TOE summary specification also needs to describe how the TOE
+protects itself against logical tampering and bypass. This additional
+description may be used in special circumstances where there might be a
+specific concern regarding the TOE security architecture.
+
+
+**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.**
+
+
+Page 88 of 247 Version 3.1 April 2017
+
+
+**Class ASE: Security Target evaluation**
+
+
+**ASE_TSS.2** **TOE summary specification with architectural design summary**
+
+
+Dependencies: ASE_INT.1 ST introduction
+ASE_REQ.1 Stated security requirements
+ADV_ARC.1 Security architecture description
+
+
+Developer action elements:
+
+
+**ASE_TSS.2.1D** The developer shall provide a TOE summary specification.
+
+
+Content and presentation elements:
+
+
+**ASE_TSS.2.1C** The TOE summary specification shall describe how the TOE meets each
+SFR.
+
+
+**ASE_TSS.2.2C** **The TOE summary specification shall describe how the TOE protects**
+**itself against interference and logical tampering.**
+
+
+**ASE_TSS.2.3C** **The TOE summary specification shall describe how the TOE protects**
+**itself against bypass.**
+
+
+Evaluator action elements:
+
+
+**ASE_TSS.2.1E** The evaluator _**shall confirm**_ that the information provided meets all
+requirements for content and presentation of evidence.
+
+
+**ASE_TSS.2.2E** The evaluator _**shall confirm**_ that the TOE summary specification is
+consistent with the TOE overview and the TOE description.
+
+
+April 2017 Version 3.1 Page 89 of 247
+
+
+**Class ADV: Development**
+
+# **13 Class ADV: Development**
+
+
+213 The requirements of the Development class provide information about the
+TOE. The knowledge obtained by this information is used as the basis for
+conducting vulnerability analysis and testing upon the TOE, as described in
+the AVA and ATE classes.
+
+
+214 The Development class encompasses six families of requirements for
+structuring and representing the TSF at various levels and varying forms of
+abstraction. These families include:
+
+
+๏ญ requirements for the description (at the various levels of abstraction)
+of the design and implementation of the SFRs (ADV_FSP,
+ADV_TDS, ADV_IMP)
+
+
+๏ญ requirements for the description of the architecture-oriented features
+of domain separation, TSF self-protection and non-bypassability of
+the security functionality (ADV_ARC)
+
+
+๏ญ requirements for a security policy model and for correspondence
+mappings between security policy model and the functional
+specification (ADV_SPM)
+
+
+๏ญ requirements on the internal structure of the TSF, which covers
+aspects such as modularity, layering, and minimisation of complexity
+(ADV_INT)
+
+
+215 When documenting the security functionality of a TOE, there are two
+properties that need to be demonstrated. The first property is that the security
+functionality works correctly; that is, it performs as specified. The second
+property, and one that is arguably harder to demonstrate, is that the TOE
+cannot be used in a way such that the security functionality can be corrupted
+or bypassed. These two properties require somewhat different approaches in
+analysis, and so the families in ADV are structured to support these different
+approaches. The families Functional specification (ADV_FSP), TOE design
+(ADV_TDS), Implementation representation (ADV_IMP), and Security
+policy modelling (ADV_SPM) deal with the first property: the specification
+of the security functionality. The families Security Architecture
+(ADV_ARC) and TSF internals (ADV_INT) deal with the second property:
+the specification of the design of the TOE demonstrating the security
+functionality cannot be corrupted or bypassed. It should be noted that both
+properties need to be realised: the more confidence one has that the
+properties are satisfied, the more trustworthy the TOE is. The components in
+the families are designed so that more assurance can be gained as the
+components hierarchically increase.
+
+
+216 The paradigm for the families targeted at the first property is one of design
+decomposition. At the highest level, there is a functional specification of the
+TSF in terms of its interfaces (describing _what_ the TSF does in terms of
+
+
+Page 90 of 247 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+requests to the TSF for services and resulting responses), decomposing the
+TSF into smaller units (dependent on the assurance desired and the
+complexity of the TOE) and describing _how_ the TSF accomplishes its
+functions (to a level of detail commensurate with the assurance level), and
+showing the implementation of the TSF. A formal model of the security
+behaviour also may be given. All levels of decomposition are used in
+determining the completeness and accuracy of all other levels, ensuring that
+the levels are mutually supportive. The requirements for the various TSF
+representations are separated into different families, to allow the PP/ST
+author to specify which TSF representations are required. The level chosen
+will dictate the assurance desired/gained.
+
+
+217 Figure 11 indicates the relationships among the various TSF representations
+of the ADV class, as well as their relationships with other classes. As the
+figure indicates, the APE and ASE classes define the requirements for the
+correspondence between the SFRs and the security objectives for the TOE.
+Class ASE also defines requirements for the correspondence between both
+the security objectives and SFRs, and for the TOE summary specification
+which explains how the TOE meets its SFRs. The activities of
+ALC_CMC.5.2E include the verification that the TSF that is tested under the
+ATE and AVA classes is in fact the one described by all of the ADV
+decomposition levels.
+
+
+April 2017 Version 3.1 Page 91 of 247
+
+
+**Class ADV: Development**
+
+
+**Figure 11 - Relationships of ADV constructs to one another and to other**
+
+**families**
+
+
+218 The requirements for all other correspondence shown in Figure 11 are
+defined in the ADV class. The Security policy modelling (ADV_SPM)
+family defines the requirements for formally modelling selected SFRs, and
+providing correspondence between the functional specification and the
+formal model. Each assurance family specific to a TSF representation (i.e.,
+Functional specification (ADV_FSP), TOE design (ADV_TDS) and
+Implementation representation (ADV_IMP)) defines requirements relating
+that TSF representation to the SFRs. All decompositions must accurately
+reflect all other decompositions (i.e., be mutually supportive); the developer
+supplies the tracings in the last .C elements of the components. Assurance
+relating to this factor is obtained during the analysis for each of the levels of
+decomposition by referring to other levels of decomposition (in a recursive
+fashion) while the analysis of a particular level of decomposition is being
+performed; the evaluator verifies the correspondence as part of the second E
+
+
+Page 92 of 247 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+element. The understanding gained from these levels of decomposition form
+the basis of the functional and penetration testing efforts.
+
+
+219 The ADV_INT family is not represented in this figure, as it is related to the
+internal structure of the TSF, and is only indirectly related to the process of
+refinement of the TSF representations. Similarly, the ADV_ARC family is
+not represented in the figure because it relates to the architectural soundness,
+rather than representation, of the TSF. Both ADV_INT and ADV_ARC
+relate to the analysis of the property that the TOE cannot be made to
+circumvent or corrupt its security functionality.
+
+
+220 The TOE security functionality (TSF) consists of all parts of the TOE that
+have to be relied upon for enforcement of the SFRs. The TSF includes both
+functionality that directly enforces the SFRs, as well as functionality that,
+while not directly enforcing the SFRs, contributes to their enforcement in a
+more indirect manner, including functionality with the capability to cause the
+SFRs to be violated. This includes portions of the TOE that are invoked on
+start-up that are responsible for putting the TSF into its initial secure state.
+
+
+221 Several important concepts were used in the development of the components
+of the ADV families. These concepts, while introduced briefly here, are
+explained more fully in the application notes for the families.
+
+
+222 One over-riding notion is that, as more information becomes available,
+greater assurance can be obtained that the security functionality 1) is
+correctly implemented; 2) cannot be corrupted; and 3) cannot be bypassed.
+This is done through the verification that the documentation is correct and
+consistent with other documentation, and by providing information that can
+be used to ensure that the testing activities (both functional and penetration
+testing) are comprehensive. This is reflected in the levelling of the
+components of the families. In general, components are levelled based on the
+amount of information that is to be provided (and subsequently analysed).
+
+
+223 While not true for all TOEs, it is generally the case that the TSF is
+sufficiently complex that there are portions of the TSF that deserve more
+intense examination than other portions of the TSF. Determining those
+portions is unfortunately somewhat subjective, thus terminology and
+components have been defined such that as the level of assurance increases,
+the responsibility for determining what portions of the TSF need to be
+examined in detail shifts from the developer to the evaluator. To aid in
+expressing this concept, the following terminology is introduced. It should be
+noted that in the families of the class, this terminology is used when
+expressing SFR-related portions of the TOE (that is, elements and work units
+embodied in the Functional specification (ADV_FSP), TOE design
+(ADV_TDS), and Implementation representation (ADV_IMP) families).
+While the general concept (that some portions of the TOE are more
+_interesting_ than others) applies to other families, the criteria are expressed
+differently in order to obtain the assurance required.
+
+
+224 All portions of the TSF are _security relevant_, meaning that they must
+preserve the security of the TOE as expressed by the SFRs and requirements
+
+
+April 2017 Version 3.1 Page 93 of 247
+
+
+**Class ADV: Development**
+
+
+for domain separation and non-bypassability. One aspect of security
+relevance is the degree to which a portion of the TSF enforces a security
+requirement. Since different portions of the TOE play different roles (or no
+apparent role at all) in enforcing security requirements, this creates a
+continuum of SFR relevance: at one end of this continuum are portions of the
+TOE that are termed _SFR-enforcing_ . Such portions play a direct role in
+implementing any SFR on the TOE. Such SFRs refer to any functionality
+provided by one of the SFRs contained in the ST. It should be noted that the
+definition of _plays a role in_ for SFR-enforcing functionality is impossible to
+express quantitatively. For example, in the implementation of a Discretionary
+Access Control (DAC) mechanism, a very narrow view of _SFR-enforcing_
+might be the several lines of code that actually perform the check of a
+subject's attributes against the object's attributes. A broader view would
+include the software entity (e.g., C function) that contained the several lines
+of code. A broader view still would include callers of the C function, since
+they would be responsible for enforcing the decision returned by the attribute
+check. A still broader view would include any code in the call tree (or
+programming equivalent for the implementation language used) for that C
+function (e.g., a sort function that sorted access control list entries in a firstmatch algorithm implementation). At some point, the component is not so
+much _enforcing_ the security policy but rather plays a _supporting_ role; such
+components are termed _SFR supporting_ .
+
+
+225 One of the characteristics of SFR-supporting functionality is that it is trusted
+to preserve the correctness of the SFR implementation by operating without
+error. Such functionality may be depended on by SFR-enforcing
+functionality, but the dependence is generally at a functional level; for
+example, memory management, buffer management, etc. Further down on
+the security relevance continuum is functionality termed _SFR non-interfering_ .
+Such functionality has no role in implementing the SFRs, and is likely part of
+the TSF because of its environment; for example, any code running in a
+privileged hardware mode on an operating system. It needs to be considered
+part of the TSF because, if compromised (or replaced by malicious code), it
+could compromise the correct operation of an SFR by virtue of its operating
+in the privileged hardware mode. An example of SFR non-interfering
+functionality might be a set of mathematical floating point operations
+implemented in kernel mode for speed considerations.
+
+
+226 The architecture family (Security Architecture (ADV_ARC)) provides for
+requirements and analysis of the TOE based on properties of domain
+separation, self-protection, and non-bypassability. These properties relate to
+the SFRs in that, if these properties are not present, it will likely lead to the
+failure of mechanisms implementing SFRs. Functionality and design relating
+to these properties _is not_ considered a part of the continuum described above,
+but instead is treated separately due to its fundamentally different nature and
+analysis requirements.
+
+
+227 The difference in analysis of the implementation of SFRs (SFR-enforcing
+and SFR-supporting functionality) and the implementation of somewhat
+fundamental security properties of the TOE, which include the initialisation,
+
+
+Page 94 of 247 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+self-protection, and non-bypassability concerns, is that the SFR-related
+functionality is more or less directly visible and relatively easy to test, while
+the above-mentioned properties require varying degrees of analysis on a
+much broader set of functionality. Further, the depth of analysis for such
+properties will vary depending on the design of the TOE. The ADV families
+are constructed to address this by a separate family (Security Architecture
+(ADV_ARC)) devoted to analysis of the initialisation, self-protection, and
+non-bypassability requirements, while the other families are concerned with
+analysis of the functionality supporting SFRs.
+
+
+228 Even in cases where different descriptions are necessary for the multiple
+levels of abstraction, it is not absolutely necessary for each and every TSF
+representation to be in a separate document. Indeed, it may be the case that a
+single document meets the documentation requirements for more than one
+TSF representation, since it is the information about each of these TSF
+representations that is required, rather than the resulting document structure.
+In cases where multiple TSF representations are combined within a single
+document, the developer should indicate which portions of the documents
+meet which requirements.
+
+
+229 Three types of specification style are mandated by this class: informal,
+semiformal and formal. The functional specification and TOE design
+documentation are always written in either informal or semiformal style. A
+semiformal style reduces the ambiguity in these documents over an informal
+presentation. A formal specification may also be required _in addition to_ the
+semi-formal presentation; the value is that a description of the TSF in more
+than one way will add increased assurance that the TSF has been completely
+and accurately specified.
+
+
+230 An informal specification is written as prose in natural language. Natural
+language is used here as meaning communication in any commonly spoken
+tongue (e.g. Spanish, German, French, English, Dutch). An informal
+specification is not subject to any notational or special restrictions other than
+those required as ordinary conventions for that language (e.g. grammar and
+syntax). While no notational restrictions apply, the informal specification is
+also required to provide defined meanings for terms that are used in a context
+other than that accepted by normal usage.
+
+
+231 The difference between semiformal and informal documents is only a matter
+of formatting or presentation: a semiformal notation includes such things as
+an explicit glossary of terms, a standardised presentation format, etc. A
+semiformal specification is written to a standard presentation template. The
+presentation should use terms consistently if written in a natural language.
+The presentation may also use more structured languages/diagrams (e.g.
+data-flow diagrams, state transition diagrams, entity-relationship diagrams,
+data structure diagrams, and process or program structure diagrams).
+Whether based on diagrams or natural language, a set of conventions must be
+used in the presentation. The glossary explicitly identifies the words that are
+being used in a precise and constant manner; similarly, the standardised
+format implies that extreme care has been taken in methodically preparing
+the document in a manner that maximises clarity. It should be noted that
+
+
+April 2017 Version 3.1 Page 95 of 247
+
+
+**Class ADV: Development**
+
+
+fundamentally different portions of the TSF may have different semiformal
+notation conventions and presentation styles (as long as the number of
+different โsemiformal notationsโ is small); this still conforms to the concept
+of a _semiformal presentation_ .
+
+
+232 A formal specification is written in a notation based upon well-established
+mathematical concepts, and is typically accompanied by supporting
+explanatory (informal) prose. These mathematical concepts are used to
+define the syntax and semantics of the notation and the proof rules that
+support logical reasoning. The syntactic and semantic rules supporting a
+formal notation should define how to recognise constructs unambiguously
+and determine their meaning. There needs to be evidence that it is impossible
+to derive contradictions, and all rules supporting the notation need to be
+defined or referenced.
+
+
+233 Figure 12 shows the families within this class, and the hierarchy of
+components within the families.
+
+
+**Figure 12 - ADV: Development class decomposition**
+
+
+Page 96 of 247 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+## **13.1 Security Architecture (ADV_ARC)**
+
+
+Objectives
+
+
+234 The objective of this family is for the developer to provide a description of
+the security architecture of the TSF. This will allow analysis of the
+information that, when coupled with the other evidence presented for the
+TSF, will confirm the TSF achieves the desired properties. The security
+architecture descriptions supports the implicit claim that security analysis of
+the TOE can be achieved by examining the TSF; without a sound
+architecture, the entire TOE functionality would have to be examined.
+
+
+Component levelling
+
+
+235 This family contains only one component.
+
+
+Application notes
+
+
+236 The properties of self-protection, domain separation, and non-bypassability
+are distinct from security functionality expressed by Part 2 SFRs because
+self-protection and non-bypassability largely have no directly observable
+interface at the TSF. Rather, they are properties of the TSF that are achieved
+through the design of the TOE and TSF, and enforced by the correct
+implementation of that design.
+
+
+237 The approach used in this family is for the developer to design and provide a
+TSF that exhibits the above-mentioned properties, and to provide evidence
+(in the form of documentation) that explains these properties of the TSF.
+This explanation is provided at the same level of detail as the description of
+the SFR-enforcing elements of the TOE in the TOE design document. The
+evaluator has the responsibility for looking at the evidence and, coupled with
+other evidence delivered for the TOE and TSF, determining that the
+properties are achieved.
+
+
+238 Specification of security functionality implementing the SFRs (in the
+Functional specification (ADV_FSP) and TOE design (ADV_TDS)) will not
+necessarily describe mechanisms employed in implementing self-protection
+and non-bypassability (e.g. memory management mechanisms). Therefore,
+the material needed to provide the assurance that these requirements are
+being achieved is better suited to a presentation separate from the design
+decomposition of the TSF as embodied in ADV_FSP and ADV_TDS. This is
+not to imply that the security architecture description called for by this
+component cannot reference or make use of the design decomposition
+material; but it is likely that much of the detail present in the decomposition
+documentation will not be relevant to the argument being provided for the
+security architecture description document.
+
+
+239 The description of architectural soundness can be thought of as a developer's
+vulnerability analysis, in that it provides the justification for why the TSF is
+sound and enforces all of its SFRs. Where the soundness is achieved through
+specific security mechanisms, these will be tested as part of the Depth
+
+
+April 2017 Version 3.1 Page 97 of 247
+
+
+**Class ADV: Development**
+
+
+(ATE_DPT) requirements; where the soundness is achieved solely through
+the architecture, the behaviour will be tested as part of the AVA:
+Vulnerability assessment requirements.
+
+
+240 This family consists of requirements for a security architecture description
+that describes the self-protection, domain separation, non-bypassability
+principles, including a description of how these principles are supported by
+the parts of the TOE that are used for TSF initialisation.
+
+
+241 Additional information on the security architecture properties of selfprotection, domain separation, and non-bypassability can be found in Annex
+A.1, ADV_ARC: Supplementary material on security architectures.
+
+
+**ADV_ARC.1** **Security architecture description**
+
+
+Dependencies: ADV_FSP.1 Basic functional specification
+ADV_TDS.1 Basic design
+
+
+Developer action elements:
+
+
+**ADV_ARC.1.1D** **The developer shall design and implement the TOE so that the security**
+
+**features of the TSF cannot be bypassed.**
+
+
+**ADV_ARC.1.2D** **The developer shall design and implement the TSF so that it is able to**
+
+**protect itself from tampering by untrusted active entities.**
+
+
+**ADV_ARC.1.3D** **The developer shall provide a security architecture description of the**
+
+**TSF.**
+
+
+Content and presentation elements:
+
+
+**ADV_ARC.1.1C** **The security architecture description shall be at a level of detail**
+
+**commensurate with the description of the SFR-enforcing abstractions**
+**described in the TOE design document.**
+
+
+**ADV_ARC.1.2C** **The security architecture description shall describe the security domains**
+
+**maintained by the TSF consistently with the SFRs.**
+
+
+**ADV_ARC.1.3C** **The security architecture description shall describe how the TSF**
+
+**initialisation process is secure.**
+
+
+**ADV_ARC.1.4C** **The security architecture description shall demonstrate that the TSF**
+
+**protects itself from tampering.**
+
+
+**ADV_ARC.1.5C** **The security architecture description shall demonstrate that the TSF**
+
+**prevents bypass of the SFR-enforcing functionality.**
+
+
+Evaluator action elements:
+
+
+**ADV_ARC.1.1E** **The evaluator** _**shall confirm**_ **that the information provided meets all**
+
+**requirements for content and presentation of evidence.**
+
+
+Page 98 of 247 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+## **13.2 Functional specification (ADV_FSP)**
+
+
+Objectives
+
+
+242 This family levies requirements upon the functional specification, which
+describes the TSF interfaces (TSFIs). The TSFI consists of all means by
+which external entities (or subjects in the TOE but outside of the TSF)
+supply data to the TSF, receive data from the TSF and invoke services from
+the TSF. It does _not_ describe how the TSF processes those service requests,
+nor does it describe the communication when the TSF invokes services from
+its operational environment; this information is addressed by the TOE design
+(ADV_TDS) and Reliance of dependent component (ACO_REL) families,
+respectively.
+
+
+243 This family provides assurance directly by allowing the evaluator to
+understand how the TSF meets the claimed SFRs. It also provides assurance
+indirectly, as input to other assurance families and classes:
+
+
+๏ญ ADV_ARC, where the description of the TSFIs may be used to gain
+better understanding of how the TSF is protected against corruption
+(i.e. subversion of self-protection or domain separation) and/or
+bypass;
+
+
+๏ญ ATE, where the description of the TSFIs is an important input for
+both developer and evaluator testing;
+
+
+๏ญ AVA, where the description of the TSFIs is used to search for
+vulnerabilities.
+
+
+Component levelling
+
+
+244 The components in this family are levelled on the degree of detail required of
+the description of the TSFIs, and the degree of formalism required of the
+description of the TSFIs.
+
+
+Application notes
+
+
+245 Once the TSFIs are determined (see A.2.1, Determining the TSFI for
+guidance and examples of determining TSFI), they are described. At lowerlevel components, developers focus their documentation (and evaluators
+focus their analysis) on the more security-relevant aspects of the TOE. Three
+categories of TSFIs are defined, based upon the relevance the services
+available through them have to the SFRs being claimed:
+
+
+๏ญ If a service available through an interface can be traced to one of the
+SFRs levied on the TSF, then that interface is termed _SFR-enforcing_ .
+Note that it is possible that an interface may have various services
+and results, some of which may be SFR-enforcing and some of which
+may not.
+
+
+April 2017 Version 3.1 Page 99 of 247
+
+
+**Class ADV: Development**
+
+
+๏ญ interfaces to (or services available through an interface relating to)
+services that SFR-enforcing functionality depends upon, but need
+only to function correctly in order for the security policies of the TOE
+to be preserved, are termed _SFR-supporting_ .
+
+
+๏ญ Interfaces to services on which SFR-enforcing functionality has no
+dependence are termed _SFR non-interfering_ .
+
+
+246 It should be noted that in order for an interface to be SFR-supporting or SFR
+non-interfering it must have _no_ SFR-enforcing services or results. In contrast,
+an SFR-enforcing interface may have SFR-supporting services (for example,
+the ability to set the system clock may be an SFR-enforcing service of an
+interface, but if that same interface is used to display the system date that
+service may be only SFR-supporting). An example of a purely SFRsupporting interface is a system call interface that is used both by users and
+by a portion of the TSF that is running on behalf of users.
+
+
+247 As more information about the TSFIs becomes available, the greater the
+assurance that can be gained that the interfaces are correctly
+categorised/analysed. The requirements are structured such that, at the lowest
+level, the information required for SFR non-interfering interfaces is the
+minimum necessary in order for the evaluator to make this determination in
+an effective manner. At higher levels, more information becomes available
+so that the evaluator has greater confidence in the designation.
+
+
+248 The purpose in defining these labels (SFR-enforcing, SFR-supporting, and
+SFR-non-interfering) and for levying different requirements upon each (at
+the lower assurance components) is to provide a first approximation of where
+to focus the analysis and the evidence upon which that analysis is performed.
+If the developer's documentation of the TSF interfaces describes all of the
+interfaces to the degree specified in the requirements for the SFR-enforcing
+interfaces (that is, if the documentation exceeds the requirements), there is no
+need for the developer to create new evidence to match the requirements.
+Similarly, because the labels are merely a means of differentiating the
+interface types within the requirements, there is no need for the developer to
+update the evidence solely to label the interfaces as SFR-enforcing, SFRsupporting, and SFR-non-interfering. The primary purpose of this labelling is
+to allow developers with less mature development methodologies (and
+associated artifacts, such as detailed interface and design documentation) to
+provide only the necessary evidence without undue cost.
+
+
+249 The last C element of each component within this family provides a direct
+correspondence between the SFRs and the functional specification; that is, an
+indication of which interfaces are used to invoke each of the claimed SFRs.
+In the cases where the ST contains such functional requirements as Residual
+information protection (FDP_RIP), whose functionality may not manifest
+itself at the TSFIs, the functional specification and/or the tracing is expected
+to identify these SFRs; including them in the functional specification helps to
+ensure that they are not lost at lower levels of decomposition, where they
+will be relevant.
+
+
+Page 100 of 247 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+**13.2.1** **Detail about the Interfaces**
+
+
+250 The requirements define collections of details about TSFI to be provided. For
+the purposes of the requirements, interfaces are specified (in varying degrees
+of detail) in terms of their purpose, method of use, parameters, parameter
+descriptions, and error messages.
+
+
+251 The _purpose_ of an interface is a high-level description of the general goal of
+the interface (e.g. process GUI commands, receive network packets, provide
+printer output, etc.)
+
+
+252 The interface's _method of use_ describes how the interface is supposed to be
+used. This description should be built around the various interactions
+available at that interface. For instance, if the interface were a Unix
+command shell, _ls_, _mv_ and _cp_ would be interactions for that interface. For
+each interaction the method of use describes what the interaction does, both
+for behaviour seen at the interface (e.g. the programmer calling the API, the
+Windows users changing a setting in the registry, etc.) as well as behaviour
+at other interfaces (e.g. generating an audit record).
+
+
+253 _Parameters_ are explicit inputs to and outputs from an interface that control
+the behaviour of that interface. For example, parameters are the arguments
+supplied to an API; the various fields in a packet for a given network
+protocol; the individual key values in the Windows Registry; the signals
+across a set of pins on a chip; the flags that can be set for the _ls_, etc. The
+parameters are โidentifiedโ with a simple list of what they are.
+
+
+254 A _parameter description_ tells what the parameter is in some meaningful way.
+For instance, an acceptable parameter description for interface _foo(i)_ would
+be โparameter i is an integer that indicates the number of users currently
+logged in to the systemโ. A description such as โparameter i is an integerโ is
+not an acceptable.
+
+
+255 The description of an interface's _actions_ describes what the interface does.
+This is more detailed than the purpose in that, while the โpurposeโ reveals
+why one might want to use it, the โactionsโ reveals everything that it does.
+These actions might be related to the SFRs or not. In cases where the
+interface's action is not related to SFRs, its description is said to be
+_summarised_, meaning the description merely makes clear that it is indeed not
+SFR-related.
+
+
+256 The _error message description_ identifies the condition that generated it, what
+the message is, and the meaning of any error codes. An error message is
+generated by the TSF to signify that a problem or irregularity of some degree
+has been encountered. The requirements in this family refer to different kinds
+of error messages:
+
+
+๏ญ a โdirectโ error message is a security-relevant response through a
+specific TSFI invocation.
+
+
+April 2017 Version 3.1 Page 101 of 247
+
+
+**Class ADV: Development**
+
+
+๏ญ an โindirectโ error cannot be tied to a specific TSFI invocation
+because it results from system-wide conditions (e.g. resource
+exhaustion, connectivity interruptions, etc.). Error messages that are
+not security-relevant are also considered โindirectโ.
+
+
+๏ญ โremainingโ errors are any other errors, such as those that might be
+referenced within the code. For example, the use of conditionchecking code that checks for conditions that would not logically
+occur (e.g. a final โelseโ after a list of โcaseโ statements), would
+provide for generating a catch-all error message; in an operational
+TOE, these error messages should never be seen.
+
+
+257 An example functional specification is provided in A.2.3.
+
+
+**13.2.2** **Components of this Family**
+
+
+258 Increasing assurance through increased completeness and accuracy in the
+interface specification is reflected in the documentation required from the
+developer as detailed in the various hierarchical components of this family.
+
+
+259 At ADV_FSP.1 Basic functional specification, the only documentation
+required is a characterisation of all TSFIs and a high level description of
+SFR-enforcing and SFR-supporting TSFIs. To provide some assurance that
+the โimportantโ aspects of the TSF have been correctly characterised at the
+TSFIs, the developer is required to provide the purpose and method of use,
+parameters for the SFR-enforcing and SFR-supporting TSFIs.
+
+
+260 At ADV_FSP.2 Security-enforcing functional specification, the developer is
+required to provide the purpose, method of use, parameters, and parameter
+descriptions for all TSFIs. Additionally, for the SFR-enforcing TSFIs the
+developer has to describe the SFR-enforcing actions and direct error
+messages.
+
+
+261 At ADV_FSP.3 Functional specification with complete summary, the
+developer must now, in addition to the information required at ADV_FSP.2,
+provide enough information about the SFR-supporting and SFR-noninterfering actions to show that they are not SFR-enforcing. Further, the
+developer must now document all of the direct error messages resulting from
+the invocation of SFR-enforcing TSFIs.
+
+
+262 At ADV_FSP.4 Complete functional specification, all TSFIs - whether SFRenforcing, SFR-supporting, SFR-non-interfering - must be described to the
+same degree, including all of the direct error messages.
+
+
+263 At ADV_FSP.5 Complete semi-formal functional specification with
+additional error information, the TSFIs descriptions also include error
+messages that do not result from an invocation of a TSFI.
+
+
+264 At ADV_FSP.6 Complete semi-formal functional specification with
+additional formal specification, in addition to the information required by
+ADV_FSP.5, all remaining error messages are included. The developer must
+
+
+Page 102 of 247 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+also provide a formal description of the TSFI. This provides an alternative
+view of the TSFI that may expose inconsistencies or incomplete specification.
+
+
+**ADV_FSP.1** **Basic 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.**
+
+
+**ADV_FSP.1.3C** **The functional specification shall provide rationale for the implicit**
+
+**categorisation 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.1.1E** **The evaluator** _**shall confirm**_ **that the information provided meets all**
+
+**requirements for content and presentation of evidence.**
+
+
+**ADV_FSP.1.2E** **The evaluator** _**shall determine**_ **that the functional specification is an**
+
+**accurate and complete instantiation of the SFRs.**
+
+
+**ADV_FSP.2** **Security-enforcing functional specification**
+
+
+Dependencies: ADV_TDS.1 Basic design
+
+
+Developer action elements:
+
+
+**ADV_FSP.2.1D** The developer shall provide a functional specification.
+
+
+**ADV_FSP.2.2D** The developer shall provide a tracing from the functional specification to the
+
+SFRs.
+
+
+Content and presentation elements:
+
+
+**ADV_FSP.2.1C** **The functional specification shall completely represent the TSF.**
+
+
+**ADV_FSP.2.2C** The functional specification shall describe the purpose and method of use for
+
+**all** TSFI.
+
+
+April 2017 Version 3.1 Page 103 of 247
+
+
+**Class ADV: Development**
+
+
+**ADV_FSP.2.3C** The functional specification shall identify **and** **describe** all parameters
+
+associated with each TSFI.
+
+
+**ADV_FSP.2.4C** **For** **each** **SFR-enforcing** **TSFI,** **the** functional specification shall **describe**
+
+**the** **SFR-enforcing** **actions** associated with **the** TSFI.
+
+
+**ADV_FSP.2.5C** **For each SFR-enforcing TSFI, the functional specification shall describe**
+
+**direct error messages resulting from processing associated with the**
+**SFR-enforcing actions.**
+
+
+**ADV_FSP.2.6C** 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.
+
+
+**ADV_FSP.3** **Functional specification with complete summary**
+
+
+Dependencies: ADV_TDS.1 Basic design
+
+
+Developer action elements:
+
+
+**ADV_FSP.3.1D** The developer shall provide a functional specification.
+
+
+**ADV_FSP.3.2D** The developer shall provide a tracing from the functional specification to the
+
+SFRs.
+
+
+Content and presentation elements:
+
+
+**ADV_FSP.3.1C** The functional specification shall completely represent the TSF.
+
+
+**ADV_FSP.3.2C** The functional specification shall describe the purpose and method of use for
+
+all TSFI.
+
+
+**ADV_FSP.3.3C** The functional specification shall identify and describe all parameters
+
+associated with each TSFI.
+
+
+**ADV_FSP.3.4C** For each SFR-enforcing TSFI, the functional specification shall describe the
+
+SFR-enforcing actions associated with the TSFI.
+
+
+**ADV_FSP.3.5C** For each SFR-enforcing TSFI, the functional specification shall describe
+
+direct error messages resulting from **SFR-enforcing** **actions** **and** **exceptions**
+associated with **invocation** **of** the **TSFI.**
+
+
+**ADV_FSP.3.6C** **The functional specification shall summarise the SFR-supporting and**
+
+**SFR-non-interfering actions associated with each TSFI.**
+
+
+Page 104 of 247 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+**ADV_FSP.3.7C** The tracing shall demonstrate that the SFRs trace to TSFIs in the functional
+
+specification.
+
+
+Evaluator action elements:
+
+
+**ADV_FSP.3.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+**ADV_FSP.3.2E** The evaluator _**shall determine**_ that the functional specification is an accurate
+
+and complete instantiation of the SFRs.
+
+
+**ADV_FSP.4** **Complete functional specification**
+
+
+Dependencies: ADV_TDS.1 Basic design
+
+
+Developer action elements:
+
+
+**ADV_FSP.4.1D** The developer shall provide a functional specification.
+
+
+**ADV_FSP.4.2D** The developer shall provide a tracing from the functional specification to the
+
+SFRs.
+
+
+Content and presentation elements:
+
+
+**ADV_FSP.4.1C** The functional specification shall completely represent the TSF.
+
+
+**ADV_FSP.4.2C** The functional specification shall describe the purpose and method of use for
+
+all TSFI.
+
+
+**ADV_FSP.4.3C** The functional specification shall identify and describe all parameters
+
+associated with each TSFI.
+
+
+**ADV_FSP.4.4C** The functional specification shall **describe** **all** actions associated with each
+
+TSFI.
+
+
+**ADV_FSP.4.5C** **The functional specification shall describe all direct error messages that**
+
+**may result from an invocation of each TSFI.**
+
+
+**ADV_FSP.4.6C** The tracing shall demonstrate that the SFRs trace to TSFIs in the functional
+
+specification.
+
+
+Evaluator action elements:
+
+
+**ADV_FSP.4.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+**ADV_FSP.4.2E** The evaluator _**shall determine**_ that the functional specification is an accurate
+
+and complete instantiation of the SFRs.
+
+
+April 2017 Version 3.1 Page 105 of 247
+
+
+**Class ADV: Development**
+
+
+**ADV_FSP.5** **Complete semi-formal functional specification with additional**
+
+**error information**
+
+
+Dependencies: ADV_TDS.1 Basic design
+ADV_IMP.1 Implementation representation of the
+TSF
+
+
+Developer action elements:
+
+
+**ADV_FSP.5.1D** The developer shall provide a functional specification.
+
+
+**ADV_FSP.5.2D** The developer shall provide a tracing from the functional specification to the
+
+SFRs.
+
+
+Content and presentation elements:
+
+
+**ADV_FSP.5.1C** The functional specification shall completely represent the TSF.
+
+
+**ADV_FSP.5.2C** **The functional specification shall describe the TSFI using a semi-formal**
+
+**style.**
+
+
+**ADV_FSP.5.3C** The functional specification shall describe the purpose and method of use for
+
+all TSFI.
+
+
+**ADV_FSP.5.4C** The functional specification shall identify and describe all parameters
+
+associated with each TSFI.
+
+
+**ADV_FSP.5.5C** The functional specification shall describe all actions associated with each
+
+TSFI.
+
+
+**ADV_FSP.5.6C** The functional specification shall describe all direct error messages that may
+
+result from an invocation of each TSFI.
+
+
+**ADV_FSP.5.7C** **The functional specification shall describe all error messages that do not**
+
+**result from an invocation of a TSFI.**
+
+
+**ADV_FSP.5.8C** **The functional specification shall provide a rationale for each error**
+
+**message contained in the TSF implementation yet does not result from**
+**an invocation of a TSFI.**
+
+
+**ADV_FSP.5.9C** The tracing shall demonstrate that the SFRs trace to TSFIs in the functional
+
+specification.
+
+
+Evaluator action elements:
+
+
+**ADV_FSP.5.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+**ADV_FSP.5.2E** The evaluator _**shall determine**_ that the functional specification is an accurate
+
+and complete instantiation of the SFRs.
+
+
+Page 106 of 247 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+**ADV_FSP.6** **Complete semi-formal functional specification with additional**
+
+**formal specification**
+
+
+Dependencies: ADV_TDS.1 Basic design
+ADV_IMP.1 Implementation representation of the
+TSF
+
+
+Developer action elements:
+
+
+**ADV_FSP.6.1D** The developer shall provide a functional specification.
+
+
+**ADV_FSP.6.2D** **The developer shall provide a formal presentation of the functional**
+
+**specification of the TSF.**
+
+
+**ADV_FSP.6.3D** The developer shall provide a tracing from the functional specification to the
+
+SFRs.
+
+
+Content and presentation elements:
+
+
+**ADV_FSP.6.1C** The functional specification shall completely represent the TSF.
+
+
+**ADV_FSP.6.2C** The functional specification shall describe the TSFI using a **formal** style.
+
+
+**ADV_FSP.6.3C** The functional specification shall describe the purpose and method of use for
+
+all TSFI.
+
+
+**ADV_FSP.6.4C** The functional specification shall identify and describe all parameters
+
+associated with each TSFI.
+
+
+**ADV_FSP.6.5C** The functional specification shall describe all actions associated with each
+
+TSFI.
+
+
+**ADV_FSP.6.6C** The functional specification shall describe all direct error messages that may
+
+result from an invocation of each TSFI.
+
+
+**ADV_FSP.6.7C** The functional specification shall describe all error messages **contained** **in**
+
+**the** **TSF** **implementation** **representation.**
+
+
+**ADV_FSP.6.8C** The functional specification shall provide a rationale for each error message
+
+contained in the TSF implementation **that** **is** not **otherwise** **described** **in** **the**
+**functional** **specification** **justifying** **why** **it** **is** **not** **associated** **with** a TSFI.
+
+
+**ADV_FSP.6.9C** **The formal presentation of the functional specification of the TSF shall**
+
+**describe the TSFI using a formal style, supported by informal,**
+**explanatory text where appropriate.**
+
+
+**ADV_FSP.6.10C** The tracing shall demonstrate that the SFRs trace to TSFIs in the functional
+
+specification.
+
+
+April 2017 Version 3.1 Page 107 of 247
+
+
+**Class ADV: Development**
+
+
+Evaluator action elements:
+
+
+**ADV_FSP.6.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+**ADV_FSP.6.2E** The evaluator _**shall determine**_ that the functional specification is an accurate
+
+and complete instantiation of the SFRs.
+
+
+Page 108 of 247 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+## **13.3 Implementation representation (ADV_IMP)**
+
+
+Objectives
+
+
+265 The function of the Implementation representation (ADV_IMP) family is for
+the developer to make available the implementation representation (and, at
+higher levels, the implementation itself) of the TOE in a form that can be
+analysed by the evaluator. The implementation representation is used in
+analysis activities for other families (analysing the TOE design, for instance)
+to demonstrate that the TOE conforms its design and to provide a basis for
+analysis in other areas of the evaluation (e.g., the search for vulnerabilities).
+The implementation representation is expected to be in a form that captures
+the detailed internal workings of the TSF. This may be software source code,
+firmware source code, hardware diagrams and/or IC hardware design
+language code or layout data.
+
+
+Component levelling
+
+
+266 The components in this family are levelled on the amount of implementation
+that is mapped to the TOE design description.
+
+
+Application notes
+
+
+267 Source code or hardware diagrams and/or IC hardware design language code
+or layout data that are used to build the actual hardware are examples of parts
+of an implementation representation. It is important to note that while the
+implementation representation must be made available to the evaluator, this
+does not imply that the evaluator needs to possess that representation. For
+instance, the developer may require that the evaluator review the
+implementation representation at a site of the developer's choosing.
+
+
+268 The entire implementation representation is made available to ensure that
+analysis activities are not curtailed due to lack of information. This does not,
+however, imply that all of the representation is examined when the analysis
+activities are being performed. This is likely impractical in almost all cases,
+in addition to the fact that it most likely will not result in a higher-assurance
+TOE vs. targeted sampling of the implementation representation. The
+implementation representation is made available to allow analysis of other
+TOE design decompositions (e.g., functional specification, TOE design), and
+to gain confidence that the security functionality described at a higher level
+in the design actually appear to be implemented in the TOE. Conventions in
+some forms of the implementation representation may make it difficult or
+impossible to determine from just the implementation representation itself
+what the actual result of the compilation or run-time interpretation will be.
+For example, compiler directives for C language compilers will cause the
+compiler to exclude or include entire portions of the code. For this reason, it
+is important that such โextraโ information or related tools (scripts, compilers,
+etc.) be provided so that the implementation representation can be accurately
+determined.
+
+
+April 2017 Version 3.1 Page 109 of 247
+
+
+**Class ADV: Development**
+
+
+269 The purpose of the mapping between the implementation representation and
+the TOE design description is to aid the evaluator's analysis. The internal
+workings of the TOE may be better understood when the TOE design is
+analysed with corresponding portions of the implementation representation.
+The mapping serves as an index into the implementation representation. At
+the lower component, only a subset of the implementation representation is
+mapped to the TOE design description. Because of the uncertainty of which
+portions of the implementation representation will need such a mapping, the
+developer may choose either to map the entire implementation representation
+beforehand, or to wait to see which portions of the implementation
+representation the evaluator requires to be mapped.
+
+
+270 The implementation representation is manipulated by the developer in a form
+that is suitable for transformation to the actual implementation. For instance,
+the developer may work with files containing source code, which is
+eventually compiled to become part of the TSF. The developer makes
+available the implementation representation in the form used by the
+developer, so that the evaluator may use automated techniques in the analysis.
+This also increases the confidence that the implementation representation
+examined is actually the one used in the production of the TSF (as opposed
+to the case where it is supplied in an alternate presentation format, such as a
+word processor document). It should be noted that other forms of the
+implementation representation may also be used by the developer; these
+forms are supplied as well. The overall goal is to supply the evaluator with
+the information that will maximise the effectiveness of the evaluator's
+analysis efforts.
+
+
+271 Some forms of the implementation representation may require additional
+information because they introduce significant barriers to understanding and
+analysis. Examples include โshroudedโ source code or source code that has
+been obfuscated in other ways such that it prevents understanding and/or
+analysis. These forms of implementation representation typically result from
+the TOE developer taking a version of the implementation representation and
+running a shrouding or obfuscation program on it. While the shrouded
+representation is what is compiled and may be closer to the implementation
+(in terms of structure) than the original, un-shrouded representation,
+supplying such obfuscated code may cause significantly more time to be
+spent in analysis tasks involving the representation. When such forms of
+representation are created, the components require details on the shrouding
+tools/algorithms used so that the un-shrouded representation can be supplied,
+and the additional information can be used to gain confidence that the
+shrouding process does not compromise any security functionality.
+
+
+**ADV_IMP.1** **Implementation representation of the TSF**
+
+
+Dependencies: ADV_TDS.3 Basic modular design
+ALC_TAT.1 Well-defined development tools
+
+
+Page 110 of 247 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+Developer action elements:
+
+
+**ADV_IMP.1.1D** **The developer shall make available the implementation representation**
+
+**for the entire TSF.**
+
+
+**ADV_IMP.1.2D** **The developer shall provide a mapping between the TOE design**
+
+**description and the sample of the implementation representation.**
+
+
+Content and presentation elements:
+
+
+**ADV_IMP.1.1C** **The implementation representation shall define the TSF to a level of**
+
+**detail such that the TSF can be generated without further design**
+**decisions.**
+
+
+**ADV_IMP.1.2C** **The implementation representation shall be in the form used by the**
+
+**development personnel.**
+
+
+**ADV_IMP.1.3C** **The mapping between the TOE design description and the sample of the**
+
+**implementation representation shall demonstrate their correspondence.**
+
+
+Evaluator action elements:
+
+
+**ADV_IMP.1.1E** **The evaluator** _**shall confirm**_ **that, for the selected sample of the**
+
+**implementation representation, the information provided meets all**
+**requirements for content and presentation of evidence.**
+
+
+**ADV_IMP.2** **Complete mapping of the implementation representation of the**
+
+**TSF**
+
+
+Dependencies: ADV_TDS.3 Basic modular design
+ALC_TAT.1 Well-defined development tools
+ALC_CMC.5 Advanced support
+
+
+Developer action elements:
+
+
+**ADV_IMP.2.1D** The developer shall make available the implementation representation for the
+
+entire TSF.
+
+
+**ADV_IMP.2.2D** The developer shall provide a mapping between the TOE design description
+
+and the **entire** implementation representation.
+
+
+Content and presentation elements:
+
+
+**ADV_IMP.2.1C** The implementation representation shall define the TSF to a level of detail
+
+such that the TSF can be generated without further design decisions.
+
+
+**ADV_IMP.2.2C** The implementation representation shall be in the form used by the
+
+development personnel.
+
+
+**ADV_IMP.2.3C** The mapping between the TOE design description and the **entire**
+
+implementation representation shall demonstrate their correspondence.
+
+
+April 2017 Version 3.1 Page 111 of 247
+
+
+**Class ADV: Development**
+
+
+Evaluator action elements:
+
+
+**ADV_IMP.2.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+Page 112 of 247 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+## **13.4 TSF internals (ADV_INT)**
+
+
+Objectives
+
+
+272 This family addresses the assessment of the internal structure of the TSF. A
+TSF whose internals are well-structured is easier to implement and less likely
+to contain flaws that could lead to vulnerabilities; it is also easier to maintain
+without the introduction of flaws.
+
+
+Component levelling
+
+
+273 The components in this family are levelled on the basis of the amount of
+structure and minimisation of complexity required. ADV_INT.1 Wellstructured subset of TSF internals places requirements for well-structured
+internals on only selected parts of the TSF. This component is not included
+in an EAL because this component is viewed for use in special circumstances
+(e.g., the sponsor has a specific concern regarding a cryptographic module,
+which is isolated from the rest of the TSF) and would not be widely
+applicable.
+
+
+274 At the next level, the requirements for well-structured internals are placed on
+the entire TSF. Finally, minimisation of complexity is introduced in the
+highest component.
+
+
+Application notes
+
+
+275 These requirements, when applied to the internal structure of the TSF,
+typically result in improvements that aid both the developer and the evaluator
+in understanding the TSF, and also provide the basis for designing and
+evaluating test suites. Further, improving understandability of the TSF
+should assist the developer in simplifying its maintainability.
+
+
+276 The requirements in this family are presented at a fairly abstract level. The
+wide variety of TOEs makes it impossible to codify anything more specific
+than โwell-structuredโ or โminimum complexityโ. Judgements on structure
+and complexity are expected to be derived from the specific technologies
+used in the TOE. For example, software is likely to be considered wellstructured if it exhibits the characteristics cited in the software engineering
+disciplines. The components within this family call for identifying the
+standards for measuring the characteristic of being well-structured and not
+overly-complex.
+
+
+**ADV_INT.1** **Well-structured subset of TSF internals**
+
+
+Dependencies: ADV_IMP.1 Implementation representation of the
+TSF
+ADV_TDS.3 Basic modular design
+ALC_TAT.1 Well-defined development tools
+
+
+April 2017 Version 3.1 Page 113 of 247
+
+
+**Class ADV: Development**
+
+
+Objectives
+
+
+277 The objective of this component is to provide a means for requiring specific
+portions of the TSF to be well-structured. The intent is that the entire TSF
+has been designed and implemented using sound engineering principles, but
+the analysis is performed upon only a specific subset.
+
+
+Application notes
+
+
+278 This component requires the PP or ST author to fill in an assignment with the
+subset of the TSF. This subset may be identified in terms of the internals of
+the TSF at any layer of abstraction. For example:
+
+
+a) the structural elements of the TSF as identified in the TOE design
+(e.g. โThe developer shall design and implement _the audit subsystem_
+such that it has well-structured internals.โ)
+
+
+b) the implementation (e.g. โThe developer shall design and implement
+_the encrypt.c and decrypt.c files_ such that it has well-structured
+internals.โ or โThe developer shall design and implement _the 6227 IC_
+_chip_ such that it has well-structured internals.โ)
+
+
+279 It is likely this would not be readily accomplished by referencing the claimed
+SFRs (e.g. โThe developer shall design and implement _the portion of the TSF_
+_that provide anonymity as defined in FPR_ANO.2_ such that it has wellstructured internals.โ) because this does not indicate where to focus the
+analysis.
+
+
+280 This component has limited value and would be suitable in cases where
+potentially-malicious users/subjects have limited or strictly controlled access
+to the TSFIs or where there is another means of protection (e.g., domain
+separation) that ensures the chosen subset of the TSF cannot be adversely
+affected by the rest of the TSF (e.g., the cryptographic functionality, which is
+isolated from the rest of the TSF, is well-structured).
+
+
+Developer action elements:
+
+
+**ADV_INT.1.1D** **The developer shall design and implement [assignment:** _**subset of the**_
+
+_**TSF**_ **] such that it has well-structured internals.**
+
+
+**ADV_INT.1.2D** **The developer shall provide an internals description and justification.**
+
+
+Content and presentation elements:
+
+
+**ADV_INT.1.1C** **The justification shall explain the characteristics used to judge the**
+
+**meaning of โwell-structuredโ.**
+
+
+**ADV_INT.1.2C** **The TSF internals description shall demonstrate that the assigned subset**
+
+**of the TSF is well-structured.**
+
+
+Page 114 of 247 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+Evaluator action elements:
+
+
+**ADV_INT.1.1E** **The evaluator** _**shall confirm**_ **that the information provided meets all**
+
+**requirements for content and presentation of evidence.**
+
+
+**ADV_INT.1.2E** **The evaluator** _**shall perform**_ **an internals analysis on the assigned subset**
+
+**of the TSF.**
+
+
+**ADV_INT.2** **Well-structured internals**
+
+
+Dependencies: ADV_IMP.1 Implementation representation of the
+TSF
+ADV_TDS.3 Basic modular design
+ALC_TAT.1 Well-defined development tools
+
+
+Objectives
+
+
+281 The objective of this component is to provide a means for requiring the TSF
+to be well-structured. The intent is that the entire TSF has been designed and
+implemented using sound engineering principles.
+
+
+Application notes
+
+
+282 Judgements on the adequacy of the structure are expected to be derived from
+the specific technologies used in the TOE. This component calls for
+identifying the standards for measuring the characteristic of being wellstructured.
+
+
+Developer action elements:
+
+
+**ADV_INT.2.1D** The developer shall design and implement the **entire** **TSF** such that it has
+
+well-structured internals.
+
+
+**ADV_INT.2.2D** The developer shall provide an internals description and justification.
+
+
+Content and presentation elements:
+
+
+**ADV_INT.2.1C** The justification shall **describe** the characteristics used to judge the meaning
+
+of โwell-structuredโ.
+
+
+**ADV_INT.2.2C** The TSF internals description shall demonstrate that the **entire** TSF is well
+structured.
+
+
+Evaluator action elements:
+
+
+**ADV_INT.2.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+**ADV_INT.2.2E** The evaluator _**shall perform**_ an internals analysis on the TSF.
+
+
+April 2017 Version 3.1 Page 115 of 247
+
+
+**Class ADV: Development**
+
+
+**ADV_INT.3** **Minimally complex internals**
+
+
+Dependencies: ADV_IMP.1 Implementation representation of the
+TSF
+ADV_TDS.3 Basic modular design
+ALC_TAT.1 Well-defined development tools
+
+
+Objectives
+
+
+283 The objective of this component is to provide a means for requiring the TSF
+to be well-structured and of minimal complexity. The intent is that the entire
+TSF has been designed and implemented using sound engineering principles.
+
+
+Application notes
+
+
+284 Judgements on the adequacy of the structure and complexity are expected to
+be derived from the specific technologies used in the TOE. This component
+calls for identifying the standards for measuring the structure and complexity.
+
+
+Developer action elements:
+
+
+**ADV_INT.3.1D** The developer shall design and implement the entire TSF such that it has
+
+well-structured internals.
+
+
+**ADV_INT.3.2D** The developer shall provide an internals description and justification.
+
+
+Content and presentation elements:
+
+
+**ADV_INT.3.1C** The justification shall describe the characteristics used to judge the meaning
+
+of โwell-structuredโ **and** **โcomplexโ.**
+
+
+**ADV_INT.3.2C** The TSF internals description shall demonstrate that the entire TSF is well
+structured **and** **is** **not** **overly** **complex.**
+
+
+Evaluator action elements:
+
+
+**ADV_INT.3.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+**ADV_INT.3.2E** The evaluator _**shall perform**_ an internals analysis on the **entire** TSF.
+
+
+Page 116 of 247 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+## **13.5 Security policy modelling (ADV_SPM)**
+
+
+Objectives
+
+
+285 It is the objective of this family to provide additional assurance from the
+development of a formal _security policy model_ of the TSF, and establishing a
+correspondence between the functional specification and this security policy
+model. Preserving internal consistency the security policy model is expected
+to formally establish the security principles from its characteristics by means
+of a mathematical proof.
+
+
+Component levelling
+
+
+286 This family contains only one component.
+
+
+Application notes
+
+
+287 Inadequacies in a TOE can result either from a failure in understanding the
+security requirements or from a flawed implementation of those security
+requirements. Defining the security requirements adequately to ensure their
+understanding may be problematic because the definition must be
+sufficiently precise to prevent undesired results or subtle flaws during
+implementation of the TOE. Throughout the design, implementation, and
+review processes, the modelled security requirements may be used as precise
+design and implementation guidance, thereby providing increased assurance
+that the modelled security requirements are satisfied by the TOE. The
+precision of the model and resulting guidance is significantly improved by
+casting the model in a formal language and verifying the security
+requirements by formal proof.
+
+
+288 The creation of a formal security policy model helps to identify and
+eliminate ambiguous, inconsistent, contradictory, or unenforceable security
+policy elements. Once the TOE has been built, the formal model serves the
+evaluation effort by contributing to the evaluator's judgement of how well
+the developer has understood the security functionality being implemented
+and whether there are inconsistencies between the security requirements and
+the TOE design. The confidence in the model is accompanied by a proof that
+it contains no inconsistencies.
+
+
+289 A formal security model is a precise formal presentation of the important
+aspects of security and their relationship to the behaviour of the TOE; it
+identifies the set of rules and practises that regulates how the TSF manages,
+protects, and otherwise controls the system resources. The model includes
+the set of restrictions and properties that specify how information and
+computing resources are prevented from being used to violate the SFRs,
+accompanied by a persuasive set of engineering arguments showing that
+these restrictions and properties play a key role in the enforcement of the
+SFRs. It consists both of the formalisms that express the security
+functionality, as well as ancillary text to explain the model and to provide it
+with context. The security behaviour of the TSF is modelled both in terms of
+
+
+April 2017 Version 3.1 Page 117 of 247
+
+
+**Class ADV: Development**
+
+
+external behaviour (i.e. how the TSF interacts with the rest of the TOE and
+with its operational environment), as well as its internal behaviour.
+
+
+290 The Security Policy Model of the TOE is informally abstracted from its
+realisation by considering the proposed security requirements of the ST. The
+informal abstraction is taken to be successful if the TOE's principles (also
+termed โinvariantsโ) turn out to be enforced by its characteristics. The
+purpose of formal methods lies within the enhancement of the rigour of
+enforcement. Informal arguments are always prone to fallacies; especially if
+relationships among subjects, objects and operations get more and more
+involved. In order to minimise the risk of insecure state arrivals the rules and
+characteristics of the security policy model are mapped to respective
+properties and features within some formal system, whose rigour and
+strength can afterwards be used to obtain the security properties by means of
+theorems and formal proof.
+
+
+291 While the term โformal security policy modelโ is used in academic circles,
+the CC's approach has no fixed definition of โsecurityโ; it would equate to
+whatever SFRs are being claimed. Therefore, the formal security policy
+model is merely a formal representation of the set of SFRs being claimed.
+
+
+292 The term _security policy_ has traditionally been associated with only access
+control policies, whether label-based (mandatory access control) or userbased (discretionary access control). However, a security policy is not
+limited to access control; there are also audit policies, identification policies,
+authentication policies, encryption policies, management policies, and any
+other security policies that are enforced by the TOE, as described in the
+PP/ST. **ADV_SPM.1.1D** contains an assignment for identifying these policies
+that are formally modelled.
+
+
+**ADV_SPM.1** **Formal TOE security policy model**
+
+
+Dependencies: ADV_FSP.4 Complete functional specification
+
+
+Developer action elements:
+
+
+**ADV_SPM.1.1D** **The developer shall provide a formal security policy model for the**
+
+**[assignment:** _**list of policies that are formally modelled**_ **].**
+
+
+**ADV_SPM.1.2D** **For each policy covered by the formal security policy model, the model**
+
+**shall identify the relevant portions of the statement of SFRs that make**
+**up that policy.**
+
+
+**ADV_SPM.1.3D** **The developer shall provide a formal proof of correspondence between**
+
+**the model and any formal functional specification.**
+
+
+**ADV_SPM.1.4D** **The developer shall provide a demonstration of correspondence between**
+
+**the model and the functional specification.**
+
+
+Page 118 of 247 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+Content and presentation elements:
+
+
+**ADV_SPM.1.1C** **The model shall be in a formal style, supported by explanatory text as**
+
+**required, and identify the security policies of the TSF that are modelled.**
+
+
+**ADV_SPM.1.2C** **For all policies that are modelled, the model shall define security for the**
+
+**TOE and provide a formal proof that the TOE cannot reach a state that**
+**is not secure.**
+
+
+**ADV_SPM.1.3C** **The correspondence between the model and the functional specification**
+
+**shall be at the correct level of formality.**
+
+
+**ADV_SPM.1.4C** **The correspondence shall show that the functional specification is**
+
+**consistent and complete with respect to the model.**
+
+
+Evaluator action elements:
+
+
+**ADV_SPM.1.1E** **The evaluator** _**shall confirm**_ **that the information provided meets all**
+
+**requirements for content and presentation of evidence.**
+
+
+April 2017 Version 3.1 Page 119 of 247
+
+
+**Class ADV: Development**
+
+## **13.6 TOE design (ADV_TDS)**
+
+
+Objectives
+
+
+293 The design description of a TOE provides both context for a description of
+the TSF, and a thorough description of the TSF. As assurance needs increase,
+the level of detail provided in the description also increases. As the size and
+complexity of the TSF increase, multiple levels of decomposition are
+appropriate. The design requirements are intended to provide information
+(commensurate with the given assurance level) so that a determination can be
+made that the security functional requirements are realised.
+
+
+Component levelling
+
+
+294 The components in this family are levelled on the basis of the amount of
+information that is required to be presented with respect to the TSF, and on
+the degree of formalism required of the design description.
+
+
+Application notes
+
+
+295 The goal of design documentation is to provide sufficient information to
+determine the TSF boundary, and to describe _how_ the TSF implements the
+Security Functional Requirements. The amount and structure of the design
+documentation will depend on the complexity of the TOE and the number of
+SFRs; in general, a very complex TOE with a large number of SFRs will
+require more design documentation than a very simple TOE implementing
+only a few SFRs. Very complex TOEs will benefit (in terms of the assurance
+provided) from the production of differing levels of decomposition in
+describing the design, while very simple TOEs do not require both high-level
+and low-level descriptions of its implementation.
+
+
+296 This family uses two levels of decomposition: the _subsystem_ and the _module_ .
+A module is the most specific description of functionality: it is a description
+of the implementation. A developer should be able to implement the part of
+the TOE described by the module with no further design decisions. A
+subsystem is a description of the design of the TOE; it helps to provide a
+high-level description of what a portion of the TOE is doing and how. As
+such, a subsystem may be further divided into lower-level subsystems, or
+into modules. Very complex TOEs might require several levels of
+subsystems in order to adequately convey a useful description of how the
+TOE works. Very simple TOEs, in contrast, might not require a subsystem
+level of description; the module might clearly describe how the TOE works.
+
+
+297 The general approach adopted for design documentation is that, as the level
+of assurance increases, the emphasis of description shifts from the general
+(subsystem level) to more (module level) detail. In cases where a modulelevel of abstraction is appropriate because the TOE is simple enough to be
+described at the module level, yet the level of assurance calls for a subsystem
+level of description, the module-level description alone will suffice. For
+complex TOEs, however, this is not the case: an enormous amount of
+
+
+Page 120 of 247 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+(module-level) detail would be incomprehensible without an accompanying
+subsystem level of description.
+
+
+298 This approach follows the general paradigm that providing additional detail
+about the implementation of the TSF will result in greater assurance that the
+SFRs are implemented correctly, and provide information that can be used to
+demonstrate this in testing (ATE: Tests).
+
+
+299 In the requirements for this family, the term _interface_ is used as the means of
+communication (between two modules). It describes how the communication
+is invoked; this is similar to the details of TSFI (see Functional specification
+(ADV_FSP)). The term _interaction_ is used to identify the purpose for
+communication; it identifies why two subsystems or modules are
+communicating.
+
+
+**13.6.1** **Detail about the Subsystems and Modules**
+
+
+300 The requirements define collections of details about subsystems and modules
+to be provided:
+
+
+a) The subsystems and modules are _identified_ with a simple list of what
+they are.
+
+
+b) Subsystems and modules may be _categorised_ (either implicitly or
+explicitly) as โSFR-enforcingโ, โSFR-supportingโ, or โSFR-noninterferingโ; these terms are used the same as they are used in
+Functional specification (ADV_FSP).
+
+
+c) A subsystem's _behaviour_ is what it does. The behaviour may also be
+categorised as SFR-enforcing, SFR-supporting, or SFR-noninterfering. The behaviour of the subsystem is never categorised as
+more SFR-relevant than the category of the subsystem itself. For
+example, an SFR-enforcing subsystem can have SFR-enforcing
+behaviour as well as SFR-supporting or SFR-non-interfering
+behaviour.
+
+
+d) A _behaviour summary_ of a subsystem is an overview of the actions it
+performs (e.g. โThe TCP subsystem assembles IP datagrams into
+reliable byte streamsโ).
+
+
+e) A _behaviour description_ of a subsystem is an explanation of
+everything it does. This description should be at a level of detail that
+one can readily determine whether the behaviour has any relevance to
+the enforcement of the SFRs.
+
+
+f) A _description of interactions_ among or between subsystems or
+modules identifies the reason that subsystems or modules
+communicate, and characterises the information that is passed. It need
+not define the information to the same level of detail as an interface
+specification. For example, it would be sufficient to say โsubsystem
+
+
+April 2017 Version 3.1 Page 121 of 247
+
+
+**Class ADV: Development**
+
+
+X requests a block of memory from the memory manager, which
+responds with the location of the allocated memory.
+
+
+g) A _description of interfaces_ provides the details of how the
+interactions among modules are achieved. Rather than describing the
+reason the modules are communicating or the purpose of their
+communication (that is, the description of interactions), the
+description of interfaces describes the details of how that
+communication is accomplished, in terms of the structure and
+contents of the messages, semaphores, internal process
+communications, etc.
+
+
+h) The _purpose_ describes how a module provides their functionality. It
+provides sufficient detail that no further design decisions are needed.
+The correspondence between the implementation representation that
+implements the module, and the purpose of the module should be
+readily apparent.
+
+
+i) A module is otherwise _described_ in terms of whatever is identified in
+the element.
+
+
+Subsystems and modules, and โSFR-enforcingโ, etc. are all further explained
+in greater detail in A.4, ADV_TDS: Subsystems and Modules.
+
+
+**ADV_TDS.1** **Basic design**
+
+
+Dependencies: ADV_FSP.2 Security-enforcing functional
+specification
+
+
+Developer action elements:
+
+
+**ADV_TDS.1.1D** **The developer shall provide the design of the TOE.**
+
+
+**ADV_TDS.1.2D** **The developer shall provide a mapping from the TSFI of the functional**
+
+**specification to the lowest level of decomposition available in the TOE**
+**design.**
+
+
+Content and presentation elements:
+
+
+**ADV_TDS.1.1C** **The design shall describe the structure of the TOE in terms of**
+
+**subsystems.**
+
+
+**ADV_TDS.1.2C** **The design shall identify all subsystems of the TSF.**
+
+
+**ADV_TDS.1.3C** **The design shall provide the behaviour summary of each SFR-**
+
+**supporting or SFR-non-interfering TSF subsystem.**
+
+
+**ADV_TDS.1.4C** **The design shall summarise the SFR-enforcing behaviour of the SFR-**
+
+**enforcing subsystems.**
+
+
+Page 122 of 247 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+**ADV_TDS.1.5C** **The design shall provide a description of the interactions among SFR-**
+
+**enforcing subsystems of the TSF, and between the SFR-enforcing**
+**subsystems of the TSF and other subsystems of the TSF.**
+
+
+**ADV_TDS.1.6C** **The mapping shall demonstrate that all TSFIs trace to the behaviour**
+
+**described in the TOE design that they invoke.**
+
+
+Evaluator action elements:
+
+
+**ADV_TDS.1.1E** **The evaluator** _**shall confirm**_ **that the information provided meets all**
+
+**requirements for content and presentation of evidence.**
+
+
+**ADV_TDS.1.2E** **The evaluator** _**shall determine**_ **that the design is an accurate and**
+
+**complete instantiation of all security functional requirements.**
+
+
+**ADV_TDS.2** **Architectural design**
+
+
+Dependencies: ADV_FSP.3 Functional specification with complete
+summary
+
+
+Developer action elements:
+
+
+**ADV_TDS.2.1D** The developer shall provide the design of the TOE.
+
+
+**ADV_TDS.2.2D** The developer shall provide a mapping from the TSFI of the functional
+
+specification to the lowest level of decomposition available in the TOE
+design.
+
+
+Content and presentation elements:
+
+
+**ADV_TDS.2.1C** The design shall describe the structure of the TOE in terms of subsystems.
+
+
+**ADV_TDS.2.2C** The design shall identify all subsystems of the TSF.
+
+
+**ADV_TDS.2.3C** **The design shall provide the behaviour summary of each SFR non-**
+
+**interfering subsystem of the TSF.**
+
+
+**ADV_TDS.2.4C** The design shall **describe** the SFR-enforcing behaviour of the SFR
+enforcing subsystems.
+
+
+**ADV_TDS.2.5C** The design shall summarise the **SFR-supporting** **and** **SFR-non-interfering**
+
+behaviour of the SFR-enforcing subsystems.
+
+
+**ADV_TDS.2.6C** The design shall summarise the behaviour of the **SFR-supporting**
+
+subsystems.
+
+
+**ADV_TDS.2.7C** **The design shall provide a description of the interactions among all**
+
+**subsystems of the TSF.**
+
+
+**ADV_TDS.2.8C** The mapping shall demonstrate that all TSFIs trace to the behaviour
+
+described in the TOE design that they invoke.
+
+
+April 2017 Version 3.1 Page 123 of 247
+
+
+**Class ADV: Development**
+
+
+Evaluator action elements:
+
+
+**ADV_TDS.2.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+**ADV_TDS.2.2E** The evaluator _**shall determine**_ that the design is an accurate and complete
+
+instantiation of all security functional requirements.
+
+
+**ADV_TDS.3** **Basic modular design**
+
+
+Dependencies: ADV_FSP.4 Complete functional specification
+
+
+Developer action elements:
+
+
+**ADV_TDS.3.1D** The developer shall provide the design of the TOE.
+
+
+**ADV_TDS.3.2D** The developer shall provide a mapping from the TSFI of the functional
+
+specification to the lowest level of decomposition available in the TOE
+design.
+
+
+Content and presentation elements:
+
+
+**ADV_TDS.3.1C** The design shall describe the structure of the TOE in terms of subsystems.
+
+
+**ADV_TDS.3.2C** **The design shall describe the TSF in terms of modules.**
+
+
+**ADV_TDS.3.3C** The design shall identify all subsystems of the TSF.
+
+
+**ADV_TDS.3.4C** The design shall **provide** **a** **description** of **each** **subsystem** **of** the **TSF.**
+
+
+**ADV_TDS.3.5C** The design shall provide a description of the interactions among all
+
+subsystems of the TSF.
+
+
+**ADV_TDS.3.6C** **The design shall provide a mapping from the subsystems of the TSF to**
+
+**the modules of the TSF.**
+
+
+**ADV_TDS.3.7C** The design shall describe **each** SFR-enforcing **module** **in** **terms** of **its**
+
+**purpose** **and** **relationship** **with** **other** **modules.**
+
+
+**ADV_TDS.3.8C** **The design shall describe each SFR-enforcing module in terms of its**
+
+**SFR-related interfaces, return values from those interfaces, interaction**
+**with other modules and called SFR-related interfaces to other SFR-**
+**enforcing modules.**
+
+
+**ADV_TDS.3.9C** The design shall **describe** each **SFR-supporting** **or** **SFR-non-interfering**
+
+**module** **in** **terms** of **its** **purpose** **and** **interaction** **with** **other** **modules.**
+
+
+**ADV_TDS.3.10C** The mapping shall demonstrate that all TSFIs trace to the behaviour
+
+described in the TOE design that they invoke.
+
+
+Page 124 of 247 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+Evaluator action elements:
+
+
+**ADV_TDS.3.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+**ADV_TDS.3.2E** The evaluator _**shall determine**_ that the design is an accurate and complete
+
+instantiation of all security functional requirements.
+
+
+**ADV_TDS.4** **Semiformal modular design**
+
+
+Dependencies: ADV_FSP.5 Complete semi-formal functional
+specification with additional error information
+
+
+Developer action elements:
+
+
+**ADV_TDS.4.1D** The developer shall provide the design of the TOE.
+
+
+**ADV_TDS.4.2D** The developer shall provide a mapping from the TSFI of the functional
+
+specification to the lowest level of decomposition available in the TOE
+design.
+
+
+Content and presentation elements:
+
+
+**ADV_TDS.4.1C** The design shall describe the structure of the TOE in terms of subsystems.
+
+
+**ADV_TDS.4.2C** The design shall describe the TSF in terms of modules, **designating** **each**
+
+**module** **as** **SFR-enforcing,** **SFR-supporting,** **or** **SFR-non-interfering.**
+
+
+**ADV_TDS.4.3C** The design shall identify all subsystems of the TSF.
+
+
+**ADV_TDS.4.4C** The design shall provide a **semiformal** description of each subsystem of the
+
+TSF, **supported** **by** **informal,** **explanatory** **text** **where** **appropriate.**
+
+
+**ADV_TDS.4.5C** The design shall provide a description of the interactions among all
+
+subsystems of the TSF.
+
+
+**ADV_TDS.4.6C** The design shall provide a mapping from the subsystems of the TSF to the
+
+modules of the TSF.
+
+
+**ADV_TDS.4.7C** The design shall describe each SFR-enforcing **and** **SFR-supporting** module
+
+in terms of its purpose and relationship with other modules.
+
+
+**ADV_TDS.4.8C** The design shall describe each SFR-enforcing **and** **SFR-supporting** module
+
+in terms of its SFR-related interfaces, return values from those interfaces,
+interaction with other modules and called SFR-related interfaces to other
+SFR-enforcing **or** **SFR-supporting** modules.
+
+
+**ADV_TDS.4.9C** The design shall describe each SFR-non-interfering module in terms of its
+
+purpose and interaction with other modules.
+
+
+**ADV_TDS.4.10C** The mapping shall demonstrate that all TSFIs trace to the behaviour
+
+described in the TOE design that they invoke.
+
+
+April 2017 Version 3.1 Page 125 of 247
+
+
+**Class ADV: Development**
+
+
+Evaluator action elements:
+
+
+**ADV_TDS.4.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+**ADV_TDS.4.2E** The evaluator _**shall determine**_ that the design is an accurate and complete
+
+instantiation of all security functional requirements.
+
+
+**ADV_TDS.5** **Complete semiformal modular design**
+
+
+Dependencies: ADV_FSP.5 Complete semi-formal functional
+specification with additional error information
+
+
+Developer action elements:
+
+
+**ADV_TDS.5.1D** The developer shall provide the design of the TOE.
+
+
+**ADV_TDS.5.2D** The developer shall provide a mapping from the TSFI of the functional
+
+specification to the lowest level of decomposition available in the TOE
+design.
+
+
+Content and presentation elements:
+
+
+**ADV_TDS.5.1C** The design shall describe the structure of the TOE in terms of subsystems.
+
+
+**ADV_TDS.5.2C** The design shall describe the TSF in terms of modules, designating each
+
+module as SFR-enforcing, SFR-supporting, or SFR-non-interfering.
+
+
+**ADV_TDS.5.3C** The design shall identify all subsystems of the TSF.
+
+
+**ADV_TDS.5.4C** The design shall provide a semiformal description of each subsystem of the
+
+TSF, supported by informal, explanatory text where appropriate.
+
+
+**ADV_TDS.5.5C** The design shall provide a description of the interactions among all
+
+subsystems of the TSF.
+
+
+**ADV_TDS.5.6C** The design shall provide a mapping from the subsystems of the TSF to the
+
+modules of the TSF.
+
+
+**ADV_TDS.5.7C** The design shall **provide** **a** **semiformal** **description** **of** each module in terms
+
+of its **purpose,** **interaction,** interfaces, return values from those interfaces,
+and called interfaces to other modules, **supported** **by** **informal,** **explanatory**
+**text** **where** **appropriate.**
+
+
+**ADV_TDS.5.8C** The mapping shall demonstrate that all TSFIs trace to the behaviour
+
+described in the TOE design that they invoke.
+
+
+Evaluator action elements:
+
+
+**ADV_TDS.5.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+Page 126 of 247 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+**ADV_TDS.5.2E** The evaluator _**shall determine**_ that the design is an accurate and complete
+
+instantiation of all security functional requirements.
+
+
+**ADV_TDS.6** **Complete semiformal modular design with formal high-level**
+
+**design presentation**
+
+
+Dependencies: ADV_FSP.6 Complete semi-formal functional
+specification with additional formal specification
+
+
+Developer action elements:
+
+
+**ADV_TDS.6.1D** The developer shall provide the design of the TOE.
+
+
+**ADV_TDS.6.2D** The developer shall provide a mapping from the TSFI of the functional
+
+specification to the lowest level of decomposition available in the TOE
+design.
+
+
+**ADV_TDS.6.3D** **The developer shall provide a formal specification of the TSF**
+
+**subsystems.**
+
+
+**ADV_TDS.6.4D** **The developer shall provide a proof of correspondence between the**
+
+**formal specifications of the TSF subsystems and of the functional**
+**specification.**
+
+
+Content and presentation elements:
+
+
+**ADV_TDS.6.1C** The design shall describe the structure of the TOE in terms of subsystems.
+
+
+**ADV_TDS.6.2C** The design shall describe the TSF in terms of modules, designating each
+
+module as SFR-enforcing, SFR-supporting, or SFR-non-interfering.
+
+
+**ADV_TDS.6.3C** The design shall identify all subsystems of the TSF.
+
+
+**ADV_TDS.6.4C** The design shall provide a semiformal description of each subsystem of the
+
+TSF, supported by informal, explanatory text where appropriate.
+
+
+**ADV_TDS.6.5C** The design shall provide a description of the interactions among all
+
+subsystems of the TSF.
+
+
+**ADV_TDS.6.6C** The design shall provide a mapping from the subsystems of the TSF to the
+
+modules of the TSF.
+
+
+**ADV_TDS.6.7C** The design shall **describe** each module in **semiformal** **style** **in** terms of its
+
+purpose, interaction, interfaces, return values from those interfaces, and
+called interfaces to other modules, supported by informal, explanatory text
+where appropriate.
+
+
+**ADV_TDS.6.8C** **The formal specification of the TSF subsystems shall describe the TSF**
+
+**using a formal style, supported by informal, explanatory text where**
+**appropriate.**
+
+
+April 2017 Version 3.1 Page 127 of 247
+
+
+**Class ADV: Development**
+
+
+**ADV_TDS.6.9C** The mapping shall demonstrate that all TSFIs trace to the behaviour
+
+described in the TOE design that they invoke.
+
+
+**ADV_TDS.6.10C** **The proof of correspondence between the formal specifications of the**
+
+**TSF subsystems and of the functional specification shall demonstrate**
+**that all behaviour described in the TOE design is a correct and complete**
+**refinement of the TSFI that invoked it.**
+
+
+Evaluator action elements:
+
+
+**ADV_TDS.6.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+**ADV_TDS.6.2E** The evaluator _**shall determine**_ that the design is an accurate and complete
+
+instantiation of all security functional requirements.
+
+
+Page 128 of 247 Version 3.1 April 2017
+
+
+**Class AGD: Guidance documents**
+
+# **14 Class AGD: Guidance documents**
+
+
+301 The guidance documents class provides the requirements for guidance
+documentation for all user roles. For the secure preparation and operation of
+the TOE it is necessary to describe all relevant aspects for the secure
+handling of the TOE. The class also addresses the possibility of unintended
+incorrect configuration or handling of the TOE.
+
+
+302 In many cases it may be appropriate that guidance is provided in separate
+documents for preparation and operation of the TOE, or even separate for
+different user roles as end-users, administrators, application programmers
+using software or hardware interfaces, etc.
+
+
+303 The guidance documents class is subdivided into two families which are
+concerned with the preparative user guidance (what has to be done to
+transform the delivered TOE into its evaluated configuration in the
+operational environment as described in the ST) and with the operational
+user guidance (what has to be done during the operation of the TOE in its
+evaluated configuration).
+
+
+304 Figure 13 shows the families within this class, and the hierarchy of
+components within the families.
+
+
+**Figure 13 - AGD: Guidance documents class decomposition**
+
+
+April 2017 Version 3.1 Page 129 of 247
+
+
+**Class AGD: Guidance documents**
+
+## **14.1 Operational user guidance (AGD_OPE)**
+
+
+Objectives
+
+
+305 Operational user guidance refers to written material that is intended to be
+used by all types of users of the TOE in its evaluated configuration: endusers, persons responsible for maintaining and administering the TOE in a
+correct manner for maximum security, and by others (e.g. programmers)
+using the TOE's external interfaces. Operational user guidance describes the
+security functionality provided by the TSF, provides instructions and
+guidelines (including warnings), helps to understand the TSF and includes
+the security-critical information, and the security-critical actions required, for
+its secure use. Misleading and unreasonable guidance should be absent from
+the guidance documentation, and secure procedures for all modes of
+operation should be addressed. Insecure states should be easy to detect.
+
+
+306 The operational user guidance provides a measure of confidence that nonmalicious users, administrators, application providers and others exercising
+the external interfaces of the TOE will understand the secure operation of the
+TOE and will use it as intended. The evaluation of the user guidance includes
+investigating whether the TOE can be used in a manner that is insecure but
+that the user of the TOE would reasonably believe to be secure. The
+objective is to minimise the risk of human or other errors in operation that
+may deactivate, disable, or fail to activate security functionality, resulting in
+an undetected insecure state.
+
+
+Component levelling
+
+
+307 This family contains only one component.
+
+
+Application notes
+
+
+308 There may be different user roles or groups that are recognised by the TOE
+and that can interact with the TSF. These user roles and groups should be
+taken into consideration by the operational user guidance. They may be
+roughly grouped into administrators and non-administrative users, or more
+specifically grouped into persons responsible for receiving, accepting,
+installing and maintaining the TOE, application programmers, revisors,
+auditors, daily-management, end-users. Each role can encompass an
+extensive set of capabilities, or can be a single one.
+
+
+309 The requirement **AGD_OPE.1.1C** encompasses the aspect that any warnings to
+the users during operation of a TOE with regard to the security problem
+definition and the security objectives for the operational environment
+described in the PP/ST are appropriately covered in the user guidance.
+
+
+310 The concept of secure values, as employed in **AGD_OPE.1.3C**, has relevance
+where a user has control over security parameters. Guidance needs to be
+provided on secure and insecure settings for such parameters.
+
+
+Page 130 of 247 Version 3.1 April 2017
+
+
+**Class AGD: Guidance documents**
+
+
+311 **AGD_OPE.1.4C** requires that the user guidance describes the appropriate
+reactions to all security-relevant events. Although many security-relevant
+events are the result of performing functions, this need not always be the
+case (e.g. the audit log fills up, an intrusion is detected). Furthermore, a
+security-relevant event may happen as a result of a specific chain of
+functions or, conversely, several security-relevant events may be triggered by
+one function.
+
+
+312 **AGD_OPE.1.7C** requires that the user guidance is clear and reasonable.
+Misleading or unreasonable guidance may result in a user of the TOE
+believing that the TOE is secure when it is not.
+
+
+313 An example of misleading guidance would be the description of a single
+guidance instruction that could be parsed in more than one way, one of
+which may result in an insecure state.
+
+
+314 An example of unreasonable guidance would be a recommendation to follow
+a procedure that is so complicated that it cannot reasonably be expected that
+users will follow this guidance.
+
+
+**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, in particular 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.**
+
+
+April 2017 Version 3.1 Page 131 of 247
+
+
+**Class AGD: Guidance documents**
+
+
+**AGD_OPE.1.6C** **The operational user guidance shall, for each user role, describe the**
+
+**security measures to be followed in order 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.**
+
+
+Page 132 of 247 Version 3.1 April 2017
+
+
+**Class AGD: Guidance documents**
+
+## **14.2 Preparative procedures (AGD_PRE)**
+
+
+Objectives
+
+
+315 Preparative procedures are useful for ensuring that the TOE has been
+received and installed in a secure manner as intended by the developer. The
+requirements for preparation call for a secure transition from the delivered
+TOE to its initial operational environment. This includes investigating
+whether the TOE can be configured or installed in a manner that is insecure
+but that the user of the TOE would reasonably believe to be secure.
+
+
+Component levelling
+
+
+316 This family contains only one component.
+
+
+Application notes
+
+
+317 It is recognised that the application of these requirements will vary
+depending on aspects such as whether the TOE is delivered in an operational
+state, or whether it has to be installed at the TOE owner's site, etc.
+
+
+318 The first process covered by the preparative procedures is the consumer's
+secure acceptance of the received TOE in accordance with the developer's
+delivery procedures. If the developer has not defined delivery procedures,
+security of the acceptance has to be ensured otherwise.
+
+
+319 Installation of the TOE includes transforming its operational environment
+into a state that conforms to the security objectives for the operational
+environment provided in the ST.
+
+
+320 It might also be the case that no installation is necessary, for example a smart
+card. In this case it may be inappropriate to require and analyse installation
+procedures.
+
+
+321 The requirements in this assurance family are presented separately from
+those in the Operational user guidance (AGD_OPE) family, due to the
+infrequent, possibly one-time use of the preparative procedures.
+
+
+**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.**
+
+
+April 2017 Version 3.1 Page 133 of 247
+
+
+**Class AGD: Guidance documents**
+
+
+**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.**
+
+
+Page 134 of 247 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+# **15 Class ALC: Life-cycle support**
+
+
+322 Life-cycle support is an aspect of establishing discipline and control in the
+processes of refinement of the TOE during its development and maintenance.
+Confidence in the correspondence between the TOE security requirements
+and the TOE is greater if security analysis and the production of the evidence
+are done on a regular basis as an integral part of the development and
+maintenance activities.
+
+
+323 In the product life-cycle it is distinguished whether the TOE is under the
+responsibility of the developer or the user rather than whether it is located in
+the development or user environment. The point of transition is the moment
+where the TOE is handed over to the user. This is also the point of transition
+from the ALC to the AGD class.
+
+
+324 The ALC class consists of seven families. Life-cycle definition (ALC_LCD)
+is the high-level description of the TOE life-cycle; CM capabilities
+(ALC_CMC) a more detailed description of the management of the
+configuration items. CM scope (ALC_CMS) requires a minimum set of
+configuration items to be managed in the defined way. Development security
+(ALC_DVS) is concerned with the developer's physical, procedural,
+personnel, and other security measures; Tools and techniques (ALC_TAT)
+with the development tools and implementation standards used by the
+developer; Flaw remediation (ALC_FLR) with the handling of security flaws.
+Delivery (ALC_DEL) defines the procedures used for the delivery of the
+TOE to the consumer. Delivery processes occurring during the development
+of the TOE are denoted rather as transportations, and are handled in the
+context of integration and acceptance procedures in other families of this
+class.
+
+
+325 Throughout this class, development and related terms (developer, develop)
+are meant in the more general sense to comprise development _and_
+_production_, whereas production specifically means the process of
+transforming the implementation representation into the final TOE.
+
+
+326 Figure 14 shows the families within this class, and the hierarchy of
+components within the families.
+
+
+April 2017 Version 3.1 Page 135 of 247
+
+
+**Class ALC: Life-cycle support**
+
+
+**Figure 14 - ALC: Life-cycle support class decomposition**
+
+
+Page 136 of 247 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+## **15.1 CM capabilities (ALC_CMC)**
+
+
+Objectives
+
+
+327 Configuration management (CM) is one means for increasing assurance that
+the TOE meets the SFRs. CM establishes this by requiring discipline and
+control in the processes of refinement and modification of the TOE and the
+related information. CM systems are put in place to ensure the integrity of
+the portions of the TOE that they control, by providing a method of tracking
+any changes, and by ensuring that all changes are authorised.
+
+
+328 The objective of this family is to require the developer's CM system to have
+certain capabilities. These are meant to reduce the likelihood that accidental
+or unauthorised modifications of the configuration items will occur. The CM
+system should ensure the integrity of the TOE from the early design stages
+through all subsequent maintenance efforts.
+
+
+329 The objective of introducing automated CM tools is to increase the
+effectiveness of the CM system. While both automated and manual CM
+systems can be bypassed, ignored, or proven insufficient to prevent
+unauthorised modification, automated systems are less susceptible to human
+error or negligence.
+
+
+330 The objectives of this family include the following:
+
+
+a) ensuring that the TOE is correct and complete before it is sent to the
+consumer;
+
+
+b) ensuring that no configuration items are missed during evaluation;
+
+
+c) preventing unauthorised modification, addition, or deletion of TOE
+configuration items.
+
+
+Component levelling
+
+
+331 The components in this family are levelled on the basis of the CM system
+capabilities, the scope of the CM documentation and the evidence provided
+by the developer.
+
+
+Application notes
+
+
+332 While it is desired that CM be applied from the early design stages and
+continue into the future, this family requires that CM be in place and in use
+prior to the end of the evaluation.
+
+
+333 In the case where the TOE is a subset of a product, the requirements of this
+family apply only to the TOE configuration items, not to the product as a
+whole.
+
+
+334 For developers that have separate CM systems for different life-cycle phases
+(for example development, production and/or the final product), it is required
+to document all of them. For evaluation purposes, the separate CM systems
+
+
+April 2017 Version 3.1 Page 137 of 247
+
+
+**Class ALC: Life-cycle support**
+
+
+should be regarded as parts of an overall CM system which is addressed in
+the criteria.
+
+
+335 Similarly, if parts of the TOE are produced by different developers or at
+different sites, the CM systems being in use at the different places should be
+regarded as parts of an overall CM system which is addressed in the criteria.
+In this situation, integration aspects have also to be taken into account.
+
+
+336 Several elements of this family refer to configuration items. These elements
+identify CM requirements to be imposed on all items identified in the
+configuration list, but leave the contents of the list to the discretion of the
+developer. CM scope (ALC_CMS) can be used to narrow this discretion by
+identifying specific items that must be included in the configuration list, and
+hence covered by CM.
+
+
+337 **ALC_CMC.2.3C** introduces a requirement that the CM system uniquely identify
+all configuration items. This also requires that modifications to configuration
+items result in a new, unique identifier being assigned to the configuration
+item.
+
+
+338 **ALC_CMC.3.8C** introduces the requirement that the evidence shall demonstrate
+that the CM system operates in accordance with the CM plan. Examples of
+such evidence might be documentation such as screen snapshots or audit trail
+output from the CM system, or a detailed demonstration of the CM system
+by the developer. The evaluator is responsible for determining that this
+evidence is sufficient to show that the CM system operates in accordance
+with the CM plan.
+
+
+339 **ALC_CMC.4.5C** introduces a requirement that the CM system provide an
+automated means to support the production of the TOE. This requires that the
+CM system provide an automated means to assist in determining that the
+correct configuration items are used in generating the TOE.
+
+
+340 **ALC_CMC.5.10C** introduces a requirement that the CM system provide an
+automated means to ascertain the changes between the TOE and its
+preceding version. If no previous version of the TOE exists, the developer
+still needs to provide an automated means to ascertain the changes between
+the TOE and a future version of the TOE.
+
+
+**ALC_CMC.1** **Labelling of the TOE**
+
+
+Dependencies: ALC_CMS.1 TOE CM coverage
+
+
+Objectives
+
+
+341 A unique reference is required to ensure that there is no ambiguity in terms
+of which instance of the TOE is being evaluated. Labelling the TOE with its
+reference ensures that users of the TOE can be aware of which instance of
+the TOE they are using.
+
+
+Page 138 of 247 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+Developer action elements:
+
+
+**ALC_CMC.1.1D** **The developer shall provide the TOE and a reference for the TOE.**
+
+
+Content and presentation elements:
+
+
+**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.**
+
+
+**ALC_CMC.2** **Use of a CM system**
+
+
+Dependencies: ALC_CMS.1 TOE CM coverage
+
+
+Objectives
+
+
+342 A unique reference is required to ensure that there is no ambiguity in terms
+of which instance of the TOE is being evaluated. Labelling the TOE with its
+reference ensures that users of the TOE can be aware of which instance of
+the TOE they are using.
+
+
+343 Unique identification of the configuration items leads to a clearer
+understanding of the composition of the TOE, which in turn helps to
+determine those items which are subject to the evaluation requirements for
+the TOE.
+
+
+344 The use of a CM system increases assurance that the configuration items are
+maintained in a controlled manner.
+
+
+Developer action elements:
+
+
+**ALC_CMC.2.1D** The developer shall provide the TOE and a reference for the TOE.
+
+
+**ALC_CMC.2.2D** **The developer shall provide the CM documentation.**
+
+
+**ALC_CMC.2.3D** **The developer shall use a CM system.**
+
+
+Content and presentation elements:
+
+
+**ALC_CMC.2.1C** The TOE shall be labelled with its unique reference.
+
+
+**ALC_CMC.2.2C** **The CM documentation shall describe the method used to uniquely**
+
+**identify the configuration items.**
+
+
+**ALC_CMC.2.3C** **The CM system shall uniquely identify all configuration items.**
+
+
+Evaluator action elements:
+
+
+**ALC_CMC.2.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+April 2017 Version 3.1 Page 139 of 247
+
+
+**Class ALC: Life-cycle support**
+
+
+**ALC_CMC.3** **Authorisation controls**
+
+
+Dependencies: ALC_CMS.1 TOE CM coverage
+ALC_DVS.1 Identification of security measures
+ALC_LCD.1 Developer defined life-cycle model
+
+
+Objectives
+
+
+345 A unique reference is required to ensure that there is no ambiguity in terms
+of which instance of the TOE is being evaluated. Labelling the TOE with its
+reference ensures that users of the TOE can be aware of which instance of
+the TOE they are using.
+
+
+346 Unique identification of the configuration items leads to a clearer
+understanding of the composition of the TOE, which in turn helps to
+determine those items which are subject to the evaluation requirements for
+the TOE.
+
+
+347 The use of a CM system increases assurance that the configuration items are
+maintained in a controlled manner.
+
+
+348 Providing controls to ensure that unauthorised modifications are not made to
+the TOE (โCM access controlโ), and ensuring proper functionality and use of
+the CM system, helps to maintain the integrity of the TOE.
+
+
+Developer action elements:
+
+
+**ALC_CMC.3.1D** The developer shall provide the TOE and a reference for the TOE.
+
+
+**ALC_CMC.3.2D** The developer shall provide the CM documentation.
+
+
+**ALC_CMC.3.3D** The developer shall use a CM system.
+
+
+Content and presentation elements:
+
+
+**ALC_CMC.3.1C** The TOE shall be labelled with its unique reference.
+
+
+**ALC_CMC.3.2C** The CM documentation shall describe the method used to uniquely identify
+
+the configuration items.
+
+
+**ALC_CMC.3.3C** The CM system shall uniquely identify all configuration items.
+
+
+**ALC_CMC.3.4C** **The CM system shall provide measures such that only authorised**
+
+**changes are made to the configuration items.**
+
+
+**ALC_CMC.3.5C** **The CM documentation shall include a CM plan.**
+
+
+**ALC_CMC.3.6C** **The CM plan shall describe how the CM system is used for the**
+
+**development of the TOE.**
+
+
+**ALC_CMC.3.7C** **The evidence shall demonstrate that all configuration items are being**
+
+**maintained under the CM system.**
+
+
+Page 140 of 247 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+**ALC_CMC.3.8C** **The evidence shall demonstrate that the CM system is being operated in**
+
+**accordance with the CM plan.**
+
+
+Evaluator action elements:
+
+
+**ALC_CMC.3.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+**ALC_CMC.4** **Production support, acceptance procedures and automation**
+
+
+Dependencies: ALC_CMS.1 TOE CM coverage
+ALC_DVS.1 Identification of security measures
+ALC_LCD.1 Developer defined life-cycle model
+
+
+Objectives
+
+
+349 A unique reference is required to ensure that there is no ambiguity in terms
+of which instance of the TOE is being evaluated. Labelling the TOE with its
+reference ensures that users of the TOE can be aware of which instance of
+the TOE they are using.
+
+
+350 Unique identification of the configuration items leads to a clearer
+understanding of the composition of the TOE, which in turn helps to
+determine those items which are subject to the evaluation requirements for
+the TOE.
+
+
+351 The use of a CM system increases assurance that the configuration items are
+maintained in a controlled manner.
+
+
+352 Providing controls to ensure that unauthorised modifications are not made to
+the TOE (โCM access controlโ), and ensuring proper functionality and use of
+the CM system, helps to maintain the integrity of the TOE.
+
+
+353 The purpose of the acceptance procedures is to ensure that the parts of the
+TOE are of adequate quality and to confirm that any creation or modification
+of configuration items is authorised. Acceptance procedures are an essential
+element in integration processes and in the life-cycle management of the
+TOE.
+
+
+354 In development environments where the configuration items are complex, it
+is difficult to control changes without the support of automated tools. In
+particular, these automated tools need to be able to support the numerous
+changes that occur during development and ensure that those changes are
+authorised. It is an objective of this component to ensure that the
+configuration items are controlled through automated means. If the TOE is
+developed by multiple developers, i.e. integration has to take place, the use
+of automatic tools is adequate.
+
+
+355 Production support procedures help to ensure that the generation of the TOE
+from a managed set of configuration items is correctly performed in an
+authorised manner, particularly in the case when different developers are
+involved and integration processes have to be carried out.
+
+
+April 2017 Version 3.1 Page 141 of 247
+
+
+**Class ALC: Life-cycle support**
+
+
+Developer action elements:
+
+
+**ALC_CMC.4.1D** The developer shall provide the TOE and a reference for the TOE.
+
+
+**ALC_CMC.4.2D** The developer shall provide the CM documentation.
+
+
+**ALC_CMC.4.3D** The developer shall use a CM system.
+
+
+Content and presentation elements:
+
+
+**ALC_CMC.4.1C** The TOE shall be labelled with its unique reference.
+
+
+**ALC_CMC.4.2C** The CM documentation shall describe the method used to uniquely identify
+
+the configuration items.
+
+
+**ALC_CMC.4.3C** The CM system shall uniquely identify all configuration items.
+
+
+**ALC_CMC.4.4C** The CM system shall provide **automated** measures such that only authorised
+
+changes are made to the configuration items.
+
+
+**ALC_CMC.4.5C** **The CM system shall support the production of the TOE by automated**
+
+**means.**
+
+
+**ALC_CMC.4.6C** The CM documentation shall include a CM plan.
+
+
+**ALC_CMC.4.7C** The CM plan shall describe how the CM system is used for the development
+
+of the TOE.
+
+
+**ALC_CMC.4.8C** **The CM plan shall describe the procedures used to accept modified or**
+
+**newly created configuration items as part of the TOE.**
+
+
+**ALC_CMC.4.9C** The evidence shall demonstrate that all configuration items are being
+
+maintained under the CM system.
+
+
+**ALC_CMC.4.10C** The evidence shall demonstrate that the CM system is being operated in
+
+accordance with the CM plan.
+
+
+Evaluator action elements:
+
+
+**ALC_CMC.4.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+**ALC_CMC.5** **Advanced support**
+
+
+Dependencies: ALC_CMS.1 TOE CM coverage
+ALC_DVS.2 Sufficiency of security measures
+ALC_LCD.1 Developer defined life-cycle model
+
+
+Objectives
+
+
+356 A unique reference is required to ensure that there is no ambiguity in terms
+of which instance of the TOE is being evaluated. Labelling the TOE with its
+
+
+Page 142 of 247 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+reference ensures that users of the TOE can be aware of which instance of
+the TOE they are using.
+
+
+357 Unique identification of the configuration items leads to a clearer
+understanding of the composition of the TOE, which in turn helps to
+determine those items which are subject to the evaluation requirements for
+the TOE.
+
+
+358 The use of a CM system increases assurance that the configuration items are
+maintained in a controlled manner.
+
+
+359 Providing controls to ensure that unauthorised modifications are not made to
+the TOE (โCM access controlโ), and ensuring proper functionality and use of
+the CM system, helps to maintain the integrity of the TOE.
+
+
+360 The purpose of the acceptance procedures is to ensure that the parts of the
+TOE are of adequate quality and to confirm that any creation or modification
+of configuration items is authorised. Acceptance procedures are an essential
+element in integration processes and in the life-cycle management of the
+TOE.
+
+
+361 In development environments where the configuration items are complex, it
+is difficult to control changes without the support of automated tools. In
+particular, these automated tools need to be able to support the numerous
+changes that occur during development and ensure that those changes are
+authorised. It is an objective of this component to ensure that the
+configuration items are controlled through automated means. If the TOE is
+developed by multiple developers, i.e. integration has to take place, the use
+of automatic tools is adequate.
+
+
+362 Production support procedures help to ensure that the generation of the TOE
+from a managed set of configuration items is correctly performed in an
+authorised manner, particularly in the case when different developers are
+involved and integration processes have to be carried out.
+
+
+363 Requiring that the CM system be able to identify the version of the
+implementation representation from which the TOE is generated helps to
+ensure that the integrity of this material is preserved by the appropriate
+technical, physical and procedural safeguards.
+
+
+364 Providing an automated means of ascertaining changes between versions of
+the TOE and identifying which configuration items are affected by
+modifications to other configuration items assists in determining the impact
+of the changes between successive versions of the TOE. This in turn can
+provide valuable information in determining whether changes to the TOE
+result in all configuration items being consistent with one another.
+
+
+Developer action elements:
+
+
+**ALC_CMC.5.1D** The developer shall provide the TOE and a reference for the TOE.
+
+
+April 2017 Version 3.1 Page 143 of 247
+
+
+**Class ALC: Life-cycle support**
+
+
+**ALC_CMC.5.2D** The developer shall provide the CM documentation.
+
+
+**ALC_CMC.5.3D** The developer shall use a CM system.
+
+
+Content and presentation elements:
+
+
+**ALC_CMC.5.1C** The TOE shall be labelled with its unique reference.
+
+
+**ALC_CMC.5.2C** The CM documentation shall describe the method used to uniquely identify
+
+the configuration items.
+
+
+**ALC_CMC.5.3C** **The CM documentation shall justify that the acceptance procedures**
+
+**provide for an adequate and appropriate review of changes to all**
+**configuration items.**
+
+
+**ALC_CMC.5.4C** The CM system shall uniquely identify all configuration items.
+
+
+**ALC_CMC.5.5C** The CM system shall provide automated measures such that only authorised
+
+changes are made to the configuration items.
+
+
+**ALC_CMC.5.6C** The CM system shall support the production of the TOE by automated
+
+means.
+
+
+**ALC_CMC.5.7C** **The CM system shall ensure that the person responsible for accepting a**
+
+**configuration item into CM is not the person who developed it.**
+
+
+**ALC_CMC.5.8C** **The CM system shall identify the configuration items that comprise the**
+
+**TSF.**
+
+
+**ALC_CMC.5.9C** **The CM system shall support the audit of all changes to the TOE by**
+
+**automated means, including the originator, date, and time in the audit**
+**trail.**
+
+
+**ALC_CMC.5.10C** **The CM system shall provide an automated means to identify all other**
+
+**configuration items that are affected by the change of a given**
+**configuration item.**
+
+
+**ALC_CMC.5.11C** **The CM system shall be able to identify the version of the**
+
+**implementation representation from which the TOE is generated.**
+
+
+**ALC_CMC.5.12C** The CM documentation shall include a CM plan.
+
+
+**ALC_CMC.5.13C** The CM plan shall describe how the CM system is used for the development
+
+of the TOE.
+
+
+**ALC_CMC.5.14C** The CM plan shall describe the procedures used to accept modified or newly
+
+created configuration items as part of the TOE.
+
+
+**ALC_CMC.5.15C** The evidence shall demonstrate that all configuration items are being
+
+maintained under the CM system.
+
+
+Page 144 of 247 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+**ALC_CMC.5.16C** The evidence shall demonstrate that the CM system is being operated in
+
+accordance with the CM plan.
+
+
+Evaluator action elements:
+
+
+**ALC_CMC.5.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+**ALC_CMC.5.2E** **The evaluator** _**shall determine**_ **that the application of the production**
+
+**support procedures results in a TOE as provided by the developer for**
+**testing activities.**
+
+
+April 2017 Version 3.1 Page 145 of 247
+
+
+**Class ALC: Life-cycle support**
+
+## **15.2 CM scope (ALC_CMS)**
+
+
+Objectives
+
+
+365 The objective of this family is to identify items to be included as
+configuration items and hence placed under the CM requirements of CM
+capabilities (ALC_CMC). Applying configuration management to these
+additional items provides additional assurance that the integrity of TOE is
+maintained.
+
+
+Component levelling
+
+
+366 The components in this family are levelled on the basis of which of the
+following are required to be included as configuration items: the TOE and
+the evaluation evidence required by the SARs; the parts of the TOE; the
+implementation representation; security flaws; and development tools and
+related information.
+
+
+Application notes
+
+
+367 While CM scope (ALC_CMS) mandates a list of configuration items and
+that each item on this list be under CM, CM capabilities (ALC_CMC) leaves
+the contents of the configuration list to the discretion of the developer. CM
+scope (ALC_CMS) narrows this discretion by identifying items that must be
+included in the configuration list, and hence come under the CM
+requirements of CM capabilities (ALC_CMC).
+
+
+**ALC_CMS.1** **TOE CM coverage**
+
+
+Dependencies: No dependencies.
+
+
+Objectives
+
+
+368 A CM system can control changes only to those items that have been placed
+under CM (i.e., the configuration items identified in the configuration list).
+Placing the TOE itself and the evaluation evidence required by the other
+SARs in the ST under CM provides assurance that they have been modified
+in a controlled manner with proper authorisations.
+
+
+Application notes
+
+
+369 **ALC_CMS.1.1C** introduces the requirement that the TOE itself and the
+evaluation evidence required by the other SARs in the ST be included in the
+configuration list and hence be subject to the CM requirements of CM
+capabilities (ALC_CMC).
+
+
+Developer action elements:
+
+
+**ALC_CMS.1.1D** **The developer shall provide a configuration list for the TOE.**
+
+
+Page 146 of 247 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+Content and presentation elements:
+
+
+**ALC_CMS.1.1C** **The configuration list shall include the following: 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.**
+
+
+**ALC_CMS.2** **Parts of the TOE CM coverage**
+
+
+Dependencies: No dependencies.
+
+
+Objectives
+
+
+370 A CM system can control changes only to those items that have been placed
+under CM (i.e., the configuration items identified in the configuration list).
+Placing the TOE itself, the parts that comprise the TOE, and the evaluation
+evidence required by the other SARs under CM provides assurance that they
+have been modified in a controlled manner with proper authorisations.
+
+
+Application notes
+
+
+371 **ALC_CMS.2.1C** introduces the requirement that the parts that comprise the TOE
+(all parts that are delivered to the consumer, for example hardware parts or
+executable files) be included in the configuration list and hence be subject to
+the CM requirements of CM capabilities (ALC_CMC).
+
+
+372 **ALC_CMS.2.3C** introduces the requirement that the configuration list indicate
+the developer of each TSF relevant configuration item. โDeveloperโ here
+does not refer to a person, but to the organisation responsible for the
+development of the item.
+
+
+Developer action elements:
+
+
+**ALC_CMS.2.1D** The developer shall provide a configuration list for the TOE.
+
+
+Content and presentation elements:
+
+
+**ALC_CMS.2.1C** The configuration list shall include the following: the TOE itself; the
+
+evaluation evidence required by the SARs; **and** **the** **parts** **that** **comprise** **the**
+**TOE.**
+
+
+**ALC_CMS.2.2C** The configuration list shall uniquely identify the configuration items.
+
+
+**ALC_CMS.2.3C** **For each TSF relevant configuration item, the configuration list shall**
+
+**indicate the developer of the item.**
+
+
+April 2017 Version 3.1 Page 147 of 247
+
+
+**Class ALC: Life-cycle support**
+
+
+Evaluator action elements:
+
+
+**ALC_CMS.2.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+**ALC_CMS.3** **Implementation representation CM coverage**
+
+
+Dependencies: No dependencies.
+
+
+Objectives
+
+
+373 A CM system can control changes only to those items that have been placed
+under CM (i.e., the configuration items identified in the configuration list).
+Placing the TOE itself, the parts that comprise the TOE, the TOE
+implementation representation and the evaluation evidence required by the
+other SARs under CM provides assurance that they have been modified in a
+controlled manner with proper authorisations.
+
+
+Application notes
+
+
+374 **ALC_CMS.3.1C** introduces the requirement that the TOE implementation
+representation be included in the list of configuration items and hence be
+subject to the CM requirements of CM capabilities (ALC_CMC).
+
+
+Developer action elements:
+
+
+**ALC_CMS.3.1D** The developer shall provide a configuration list for the TOE.
+
+
+Content and presentation elements:
+
+
+**ALC_CMS.3.1C** The configuration list shall include the following: the TOE itself; the
+
+evaluation evidence required by the SARs; the parts that comprise the TOE;
+**and** **the** **implementation** **representation.**
+
+
+**ALC_CMS.3.2C** The configuration list shall uniquely identify the configuration items.
+
+
+**ALC_CMS.3.3C** For each TSF relevant configuration item, the configuration list shall indicate
+
+the developer of the item.
+
+
+Evaluator action elements:
+
+
+**ALC_CMS.3.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+**ALC_CMS.4** **Problem tracking CM coverage**
+
+
+Dependencies: No dependencies.
+
+
+Objectives
+
+
+375 A CM system can control changes only to those items that have been placed
+under CM (i.e., the configuration items identified in the configuration list).
+Placing the TOE itself, the parts that comprise the TOE, the TOE
+
+
+Page 148 of 247 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+implementation representation and the evaluation evidence required by the
+other SARs under CM provides assurance that they have been modified in a
+controlled manner with proper authorisations.
+
+
+376 Placing security flaws under CM ensures that security flaw reports are not
+lost or forgotten, and allows a developer to track security flaws to their
+resolution.
+
+
+Application notes
+
+
+377 **ALC_CMS.4.1C** introduces the requirement that security flaws be included in
+the configuration list and hence be subject to the CM requirements of CM
+capabilities (ALC_CMC). This requires that information regarding previous
+security flaws and their resolution be maintained, as well as details regarding
+current security flaws.
+
+
+Developer action elements:
+
+
+**ALC_CMS.4.1D** The developer shall provide a configuration list for the TOE.
+
+
+Content and presentation elements:
+
+
+**ALC_CMS.4.1C** The configuration list shall include the following: the TOE itself; the
+
+evaluation evidence required by the SARs; the parts that comprise the TOE;
+the implementation representation; **and** **security** **flaw** **reports** **and**
+**resolution** **status.**
+
+
+**ALC_CMS.4.2C** The configuration list shall uniquely identify the configuration items.
+
+
+**ALC_CMS.4.3C** For each TSF relevant configuration item, the configuration list shall indicate
+
+the developer of the item.
+
+
+Evaluator action elements:
+
+
+**ALC_CMS.4.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+**ALC_CMS.5** **Development tools CM coverage**
+
+
+Dependencies: No dependencies.
+
+
+Objectives
+
+
+378 A CM system can control changes only to those items that have been placed
+under CM (i.e., the configuration items identified in the configuration list).
+Placing the TOE itself, the parts that comprise the TOE, the TOE
+implementation representation and the evaluation evidence required by the
+other SARs under CM provides assurance that they have been modified in a
+controlled manner with proper authorisations.
+
+
+April 2017 Version 3.1 Page 149 of 247
+
+
+**Class ALC: Life-cycle support**
+
+
+379 Placing security flaws under CM ensures that security flaw reports are not
+lost or forgotten, and allows a developer to track security flaws to their
+resolution.
+
+
+380 Development tools play an important role in ensuring the production of a
+quality version of the TOE. Therefore, it is important to control
+modifications to these tools.
+
+
+Application notes
+
+
+381 **ALC_CMS.5.1C** introduces the requirement that development tools and other
+related information be included in the list of configuration items and hence
+be subject to the CM requirements of CM capabilities (ALC_CMC).
+Examples of development tools are programming languages and compilers.
+Information pertaining to TOE generation items (such as compiler options,
+generation options, and build options) is an example of information relating
+to development tools.
+
+
+Developer action elements:
+
+
+**ALC_CMS.5.1D** The developer shall provide a configuration list for the TOE.
+
+
+Content and presentation elements:
+
+
+**ALC_CMS.5.1C** The configuration list shall include the following: the TOE itself; the
+
+evaluation evidence required by the SARs; the parts that comprise the TOE;
+the implementation representation; security flaw reports and resolution
+status; **and** **development** **tools** **and** **related** **information.**
+
+
+**ALC_CMS.5.2C** The configuration list shall uniquely identify the configuration items.
+
+
+**ALC_CMS.5.3C** For each TSF relevant configuration item, the configuration list shall indicate
+
+the developer of the item.
+
+
+Evaluator action elements:
+
+
+**ALC_CMS.5.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+Page 150 of 247 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+## **15.3 Delivery (ALC_DEL)**
+
+
+Objectives
+
+
+382 The concern of this family is the secure transfer of the finished TOE from the
+development environment into the responsibility of the user.
+
+
+383 The requirements for delivery call for system control and distribution
+facilities and procedures that detail the measures necessary to provide
+assurance that the security of the TOE is maintained during distribution of
+the TOE to the user. For a valid distribution of the TOE, the procedures used
+for the distribution of the TOE address the objectives identified in the PP/ST
+relating to the security of the TOE during delivery.
+
+
+Component levelling
+
+
+384 This family contains only one component. An increasing level of protection
+is established by requiring commensurability of the delivery procedures with
+the assumed attack potential in the family Vulnerability analysis
+(AVA_VAN).
+
+
+Application notes
+
+
+385 Transportations from subcontractors to the developer or between different
+development sites are not considered here, but in the family Development
+security (ALC_DVS).
+
+
+386 The end of the delivery phase is marked by the transfer of the TOE into the
+responsibility of the user. This does not necessarily coincide with the arrival
+of the TOE at the user's location.
+
+
+387 The delivery procedures should consider, if applicable, issues such as:
+
+
+a) ensuring that the TOE received by the consumer corresponds
+precisely to the evaluated version of the TOE;
+
+
+b) avoiding or detecting any tampering with the actual version of the
+TOE;
+
+
+c) preventing submission of a false version of the TOE;
+
+
+d) avoiding unwanted knowledge of distribution of the TOE to the
+consumer: there might be cases where potential attackers should not
+know when and how it is delivered;
+
+
+e) avoiding or detecting the TOE being intercepted during delivery; and
+
+
+f) avoiding the TOE being delayed or stopped during distribution.
+
+
+388 The delivery procedures should include the recipient's actions implied by
+these issues. The consistent description of these implied actions is examined
+in the Preparative procedures (AGD_PRE) family, if present.
+
+
+April 2017 Version 3.1 Page 151 of 247
+
+
+**Class ALC: Life-cycle support**
+
+
+**ALC_DEL.1** **Delivery procedures**
+
+
+Dependencies: No dependencies.
+
+
+Developer action elements:
+
+
+**ALC_DEL.1.1D** **The developer shall document and provide procedures for delivery of**
+
+**the TOE or parts of it to the consumer.**
+
+
+**ALC_DEL.1.2D** **The developer shall use the delivery procedures.**
+
+
+Content and presentation elements:
+
+
+**ALC_DEL.1.1C** **The delivery documentation shall describe all procedures that are**
+
+**necessary to maintain security when distributing versions of the TOE to**
+**the consumer.**
+
+
+Evaluator action elements:
+
+
+**ALC_DEL.1.1E** **The evaluator** _**shall confirm**_ **that the information provided meets all**
+
+**requirements for content and presentation of evidence.**
+
+
+Page 152 of 247 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+## **15.4 Development security (ALC_DVS)**
+
+
+Objectives
+
+
+389 Development security is concerned with physical, procedural, personnel, and
+other security measures that may be used in the development environment to
+protect the TOE and its parts. It includes the physical security of the
+development location and any procedures used to select development staff.
+
+
+Component levelling
+
+
+390 The components in this family are levelled on the basis of whether
+justification of the sufficiency of the security measures is required.
+
+
+Application notes
+
+
+391 This family deals with measures to remove or reduce threats existing at the
+developer's site.
+
+
+392 The evaluator should visit the site(s) in order to assess evidence for
+development security. This may include sites of subcontractors involved in
+the TOE development and production. Any decision not to visit shall be
+agreed with the evaluation authority.
+
+
+393 Although development security deals with the maintenance of the TOE and
+hence with aspects becoming relevant after the completion of the evaluation,
+the Development security (ALC_DVS) requirements specify only that the
+development security measures be in place at the time of evaluation.
+Furthermore, Development security (ALC_DVS) does not contain any
+requirements related to the sponsor's intention to apply the development
+security measures in the future, after completion of the evaluation.
+
+
+394 It is recognised that confidentiality may not always be an issue for the
+protection of the TOE in its development environment. The use of the word
+โnecessaryโ allows for the selection of appropriate safeguards.
+
+
+**ALC_DVS.1** **Identification of security measures**
+
+
+Dependencies: No dependencies.
+
+
+Developer action elements:
+
+
+**ALC_DVS.1.1D** **The developer shall produce and provide development security**
+
+**documentation.**
+
+
+Content and presentation elements:
+
+
+**ALC_DVS.1.1C** **The development security documentation shall describe all the physical,**
+
+**procedural, personnel, and other security measures that are necessary to**
+**protect the confidentiality and integrity of the TOE design and**
+**implementation in its development environment.**
+
+
+April 2017 Version 3.1 Page 153 of 247
+
+
+**Class ALC: Life-cycle support**
+
+
+Evaluator action elements:
+
+
+**ALC_DVS.1.1E** **The evaluator** _**shall confirm**_ **that the information provided meets all**
+
+**requirements for content and presentation of evidence.**
+
+
+**ALC_DVS.1.2E** **The evaluator** _**shall confirm**_ **that the security measures are being applied.**
+
+
+**ALC_DVS.2** **Sufficiency of security measures**
+
+
+Dependencies: No dependencies.
+
+
+Developer action elements:
+
+
+**ALC_DVS.2.1D** The developer shall produce and provide development security
+documentation.
+
+
+Content and presentation elements:
+
+
+**ALC_DVS.2.1C** The development security documentation shall describe all the physical,
+
+procedural, personnel, and other security measures that are necessary to
+protect the confidentiality and integrity of the TOE design and
+implementation in its development environment.
+
+
+**ALC_DVS.2.2C** **The development security documentation shall justify that the security**
+
+**measures provide the necessary level of protection to maintain the**
+**confidentiality and integrity of the TOE.**
+
+
+Evaluator action elements:
+
+
+**ALC_DVS.2.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+**ALC_DVS.2.2E** The evaluator _**shall confirm**_ that the security measures are being applied.
+
+
+Page 154 of 247 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+## **15.5 Flaw remediation (ALC_FLR)**
+
+
+Objectives
+
+
+395 Flaw remediation requires that discovered security flaws be tracked and
+corrected by the developer. Although future compliance with flaw
+remediation procedures cannot be determined at the time of the TOE
+evaluation, it is possible to evaluate the policies and procedures that a
+developer has in place to track and correct flaws, and to distribute the flaw
+information and corrections.
+
+
+Component levelling
+
+
+396 The components in this family are levelled on the basis of the increasing
+extent in scope of the flaw remediation procedures and the rigour of the flaw
+remediation policies.
+
+
+Application notes
+
+
+397 This family provides assurance that the TOE will be maintained and
+supported in the future, requiring the TOE developer to track and correct
+flaws in the TOE. Additionally, requirements are included for the
+distribution of flaw corrections. However, this family does not impose
+evaluation requirements beyond the current evaluation.
+
+
+398 The TOE user is considered to be the focal point in the user organisation that
+is responsible for receiving and implementing fixes to security flaws. This is
+not necessarily an individual user, but may be an organisational
+representative who is responsible for the handling of security flaws. The use
+of the term TOE user recognises that different organisations have different
+procedures for handling flaw reporting, which may be done either by an
+individual user, or by a central administrative body.
+
+
+399 The flaw remediation procedures should describe the methods for dealing
+with all types of flaws encountered. These flaws may be reported by the
+developer, by users of the TOE, or by other parties with familiarity with the
+TOE. Some flaws may not be reparable immediately. There may be some
+occasions where a flaw cannot be fixed and other (e.g. procedural) measures
+must be taken. The documentation provided should cover the procedures for
+providing the operational sites with fixes, and providing information on
+flaws where fixes are delayed (and what to do in the interim) or when fixes
+are not possible.
+
+
+400 Changes applied to a TOE after its release render it unevaluated; although
+some information from the original evaluation may still apply. The phrase
+โrelease of the TOEโ used in this family therefore refers to a version of a
+product that is a release of a certified TOE, to which changes have been
+applied.
+
+
+April 2017 Version 3.1 Page 155 of 247
+
+
+**Class ALC: Life-cycle support**
+
+
+**ALC_FLR.1** **Basic flaw remediation**
+
+
+Dependencies: No dependencies.
+
+
+Developer action elements:
+
+
+**ALC_FLR.1.1D** **The developer shall document and provide flaw remediation procedures**
+
+**addressed to TOE developers.**
+
+
+Content and presentation elements:
+
+
+**ALC_FLR.1.1C** **The flaw remediation procedures documentation shall describe the**
+
+**procedures used to track all reported security flaws in each release of**
+**the TOE.**
+
+
+**ALC_FLR.1.2C** **The flaw remediation procedures shall require that a description of the**
+
+**nature and effect of each security flaw be provided, as well as the status**
+**of finding a correction to that flaw.**
+
+
+**ALC_FLR.1.3C** **The flaw remediation procedures shall require that corrective actions be**
+
+**identified for each of the security flaws.**
+
+
+**ALC_FLR.1.4C** **The flaw remediation procedures documentation shall describe the**
+
+**methods used to provide flaw information, corrections and guidance on**
+**corrective actions to TOE users.**
+
+
+Evaluator action elements:
+
+
+**ALC_FLR.1.1E** **The evaluator** _**shall confirm**_ **that the information provided meets all**
+
+**requirements for content and presentation of evidence.**
+
+
+**ALC_FLR.2** **Flaw reporting procedures**
+
+
+Dependencies: No dependencies.
+
+
+Objectives
+
+
+401 In order for the developer to be able to act appropriately upon security flaw
+reports from TOE users, and to know to whom to send corrective fixes, TOE
+users need to understand how to submit security flaw reports to the developer.
+Flaw remediation guidance from the developer to the TOE user ensures that
+TOE users are aware of this important information.
+
+
+Developer action elements:
+
+
+**ALC_FLR.2.1D** The developer shall document and provide flaw remediation procedures
+
+addressed to TOE developers.
+
+
+**ALC_FLR.2.2D** **The developer shall establish a procedure for accepting and acting upon**
+
+**all reports of security flaws and requests for corrections to those flaws.**
+
+
+Page 156 of 247 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+**ALC_FLR.2.3D** **The developer shall provide flaw remediation guidance addressed to**
+
+**TOE users.**
+
+
+Content and presentation elements:
+
+
+**ALC_FLR.2.1C** The flaw remediation procedures documentation shall describe the
+
+procedures used to track all reported security flaws in each release of the
+TOE.
+
+
+**ALC_FLR.2.2C** The flaw remediation procedures shall require that a description of the nature
+
+and effect of each security flaw be provided, as well as the status of finding a
+correction to that flaw.
+
+
+**ALC_FLR.2.3C** The flaw remediation procedures shall require that corrective actions be
+
+identified for each of the security flaws.
+
+
+**ALC_FLR.2.4C** The flaw remediation procedures documentation shall describe the methods
+
+used to provide flaw information, corrections and guidance on corrective
+actions to TOE users.
+
+
+**ALC_FLR.2.5C** **The flaw remediation procedures shall describe a means by which the**
+
+**developer receives from TOE users reports and enquiries of suspected**
+**security flaws in the TOE.**
+
+
+**ALC_FLR.2.6C** **The procedures for processing reported security flaws shall ensure that**
+
+**any reported flaws are remediated and the remediation procedures**
+**issued to TOE users.**
+
+
+**ALC_FLR.2.7C** **The procedures for processing reported security flaws shall provide**
+
+**safeguards that any corrections to these security flaws do not introduce**
+**any new flaws.**
+
+
+**ALC_FLR.2.8C** **The flaw remediation guidance shall describe a means by which TOE**
+
+**users report to the developer any suspected security flaws in the TOE.**
+
+
+Evaluator action elements:
+
+
+**ALC_FLR.2.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+**ALC_FLR.3** **Systematic flaw remediation**
+
+
+Dependencies: No dependencies.
+
+
+Objectives
+
+
+402 In order for the developer to be able to act appropriately upon security flaw
+reports from TOE users, and to know to whom to send corrective fixes, TOE
+users need to understand how to submit security flaw reports to the developer,
+and how to register themselves with the developer so that they may receive
+these corrective fixes. Flaw remediation guidance from the developer to the
+TOE user ensures that TOE users are aware of this important information.
+
+
+April 2017 Version 3.1 Page 157 of 247
+
+
+**Class ALC: Life-cycle support**
+
+
+Developer action elements:
+
+
+**ALC_FLR.3.1D** The developer shall document and provide flaw remediation procedures
+
+addressed to TOE developers.
+
+
+**ALC_FLR.3.2D** The developer shall establish a procedure for accepting and acting upon all
+
+reports of security flaws and requests for corrections to those flaws.
+
+
+**ALC_FLR.3.3D** The developer shall provide flaw remediation guidance addressed to TOE
+
+users.
+
+
+Content and presentation elements:
+
+
+**ALC_FLR.3.1C** The flaw remediation procedures documentation shall describe the
+
+procedures used to track all reported security flaws in each release of the
+TOE.
+
+
+**ALC_FLR.3.2C** The flaw remediation procedures shall require that a description of the nature
+
+and effect of each security flaw be provided, as well as the status of finding a
+correction to that flaw.
+
+
+**ALC_FLR.3.3C** The flaw remediation procedures shall require that corrective actions be
+
+identified for each of the security flaws.
+
+
+**ALC_FLR.3.4C** The flaw remediation procedures documentation shall describe the methods
+
+used to provide flaw information, corrections and guidance on corrective
+actions to TOE users.
+
+
+**ALC_FLR.3.5C** The flaw remediation procedures shall describe a means by which the
+
+developer receives from TOE users reports and enquiries of suspected
+security flaws in the TOE.
+
+
+**ALC_FLR.3.6C** **The flaw remediation procedures shall include a procedure requiring**
+
+**timely response and the automatic distribution of security flaw reports**
+**and the associated corrections to registered users who might be affected**
+**by the security flaw.**
+
+
+**ALC_FLR.3.7C** The procedures for processing reported security flaws shall ensure that any
+
+reported flaws are remediated and the remediation procedures issued to TOE
+users.
+
+
+**ALC_FLR.3.8C** The procedures for processing reported security flaws shall provide
+
+safeguards that any corrections to these security flaws do not introduce any
+new flaws.
+
+
+**ALC_FLR.3.9C** The flaw remediation guidance shall describe a means by which TOE users
+
+report to the developer any suspected security flaws in the TOE.
+
+
+**ALC_FLR.3.10C** **The flaw remediation guidance shall describe a means by which TOE**
+
+**users may register with the developer, to be eligible to receive security**
+**flaw reports and corrections.**
+
+
+Page 158 of 247 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+**ALC_FLR.3.11C** **The flaw remediation guidance shall identify the specific points of**
+
+**contact for all reports and enquiries about security issues involving the**
+**TOE.**
+
+
+Evaluator action elements:
+
+
+**ALC_FLR.3.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+April 2017 Version 3.1 Page 159 of 247
+
+
+**Class ALC: Life-cycle support**
+
+## **15.6 Life-cycle definition (ALC_LCD)**
+
+
+Objectives
+
+
+403 Poorly controlled development and maintenance of the TOE can result in a
+TOE that does not meet all of its SFRs. Therefore, it is important that a
+model for the development and maintenance of a TOE be established as early
+as possible in the TOE's life-cycle.
+
+
+404 Using a model for the development and maintenance of a TOE does not
+guarantee that the TOE meets all of its SFRs. It is possible that the model
+chosen will be insufficient or inadequate and therefore no benefits in the
+quality of the TOE can be observed. Using a life-cycle model that has been
+approved by a group of experts (e.g. academic experts, standards bodies)
+improves the chances that the development and maintenance models will
+contribute to the TOE meeting its SFRs. The use of a life-cycle model
+including some quantitative valuation adds further assurance in the overall
+quality of the TOE development process.
+
+
+Component levelling
+
+
+405 The components in this family are levelled on the basis of increasing
+requirements for measurability of the life-cycle model, and for compliance
+with that model.
+
+
+Application notes
+
+
+406 A life-cycle model encompasses the procedures, tools and techniques used to
+develop and maintain the TOE. Aspects of the process that may be covered
+by such a model include design methods, review procedures, project
+management controls, change control procedures, test methods and
+acceptance procedures. An effective life-cycle model will address these
+aspects of the development and maintenance process within an overall
+management structure that assigns responsibilities and monitors progress.
+
+
+407 There are different types of acceptance situations that are dealt with at
+different locations in the criteria: acceptance of parts delivered by
+subcontractors (โintegrationโ) should be treated in this family Life-cycle
+definition (ALC_LCD), acceptance subsequent to internal transportations in
+Development security (ALC_DVS), acceptance of parts into the CM system
+in CM capabilities (ALC_CMC), and acceptance of the delivered TOE by
+the consumer in Delivery (ALC_DEL). The first three types may overlap.
+
+
+408 Although life-cycle definition deals with the maintenance of the TOE and
+hence with aspects becoming relevant after the completion of the evaluation,
+its evaluation adds assurance through an analysis of the life-cycle
+information for the TOE provided at the time of the evaluation.
+
+
+409 A life-cycle model provides for the necessary control over the development
+and maintenance of the TOE, if the model enables sufficient minimisation of
+the danger that the TOE will not meet its security requirement.
+
+
+Page 160 of 247 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+410 A measurable life-cycle model is a model using some quantitative valuation
+(arithmetic parameters and/or metrics) of the managed product in order to
+measure development properties of the product. Typical metrics are source
+code complexity metrics, defect density (errors per size of code) or mean
+time to failure. For the security evaluation all those metrics are of relevance,
+which are used to increase quality by decreasing the probability of faults and
+thereby in turn increasing assurance in the security of the TOE.
+
+
+411 One should take into account that there exist standardised life cycle models
+on the one hand (like the waterfall model) and standardised metrics on the
+other hand (like error density), which may be combined. The CC does not
+require the life cycle to follow exactly one standard defining both aspects.
+
+
+**ALC_LCD.1** **Developer defined life-cycle model**
+
+
+Dependencies: No dependencies.
+
+
+Developer action elements:
+
+
+**ALC_LCD.1.1D** **The developer shall establish a life-cycle model to be used in the**
+
+**development and maintenance of the TOE.**
+
+
+**ALC_LCD.1.2D** **The developer shall provide life-cycle definition documentation.**
+
+
+Content and presentation elements:
+
+
+**ALC_LCD.1.1C** **The life-cycle definition documentation shall describe the model used to**
+
+**develop and maintain the TOE.**
+
+
+**ALC_LCD.1.2C** **The life-cycle model shall provide for the necessary control over the**
+
+**development and maintenance of the TOE.**
+
+
+Evaluator action elements:
+
+
+**ALC_LCD.1.1E** **The evaluator** _**shall confirm**_ **that the information provided meets all**
+
+**requirements for content and presentation of evidence.**
+
+
+**ALC_LCD.2** **Measurable life-cycle model**
+
+
+Dependencies: No dependencies.
+
+
+Developer action elements:
+
+
+**ALC_LCD.2.1D** The developer shall establish a life-cycle model to be used in the
+
+development and maintenance of the TOE, **that** **is** **based** **on** **a** **measurable**
+**life-cycle** **model.**
+
+
+**ALC_LCD.2.2D** The developer shall provide life-cycle definition documentation.
+
+
+**ALC_LCD.2.3D** **The developer shall measure the TOE development using the**
+
+**measurable life-cycle model.**
+
+
+April 2017 Version 3.1 Page 161 of 247
+
+
+**Class ALC: Life-cycle support**
+
+
+**ALC_LCD.2.4D** **The developer shall provide life-cycle output documentation.**
+
+
+Content and presentation elements:
+
+
+**ALC_LCD.2.1C** The life-cycle definition documentation shall describe the model used to
+
+develop and maintain the TOE, **including** **the** **details** **of** **its** **arithmetic**
+**parameters** **and/or** **metrics** **used** **to** **measure** **the** **quality** **of** **the** **TOE**
+**and/or** **its** **development.**
+
+
+**ALC_LCD.2.2C** The life-cycle model shall provide for the necessary control over the
+
+development and maintenance of the TOE.
+
+
+**ALC_LCD.2.3C** **The life-cycle output documentation shall provide the results of the**
+
+**measurements of the TOE development using the measurable life-cycle**
+**model.**
+
+
+Evaluator action elements:
+
+
+**ALC_LCD.2.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+Page 162 of 247 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+## **15.7 Tools and techniques (ALC_TAT)**
+
+
+Objectives
+
+
+412 Tools and techniques is an aspect of selecting tools that are used to develop,
+analyse and implement the TOE. It includes requirements to prevent illdefined, inconsistent or incorrect development tools from being used to
+develop the TOE. This includes, but is not limited to, programming
+languages, documentation, implementation standards, and other parts of the
+TOE such as supporting runtime libraries.
+
+
+Component levelling
+
+
+413 The components in this family are levelled on the basis of increasing
+requirements on the description and scope of the implementation standards
+and the documentation of implementation-dependent options.
+
+
+Application notes
+
+
+414 There is a requirement for well-defined development tools. These are tools
+that are clearly and completely described. For example, programming
+languages and computer aided design (CAD) systems that are based on a
+standard published by standards bodies are considered to be well-defined.
+Self-made tools would need further investigation to clarify whether they are
+well-defined.
+
+
+415 The requirement in **ALC_TAT.1.2C** is especially applicable to programming
+languages so as to ensure that all statements in the source code have an
+unambiguous meaning.
+
+
+416 In ALC_TAT.2 and ALC_TAT.3, implementation guidelines may be
+accepted as an implementation standard if they have been approved by some
+group of experts (e.g. academic experts, standards bodies). Implementation
+standards are normally public, well accepted and common practise in a
+specific industry, but developer-specific implementation guidelines may also
+be accepted as a standard; the emphasis is on the expertise.
+
+
+417 Tools and techniques distinguishes between the implementation standards
+applied by the developer ( **ALC_TAT.2.3D** ) and the implementation standards
+for โall parts of the TOEโ ( **ALC_TAT.3.3D** ) which include third party software,
+hardware, or firmware. The configuration list introduced in CM scope
+(ALC_CMS) requires that for each TSF relevant configuration item to
+indicate if it has been generated by the TOE developer or by third party
+developers.
+
+
+April 2017 Version 3.1 Page 163 of 247
+
+
+**Class ALC: Life-cycle support**
+
+
+**ALC_TAT.1** **Well-defined development tools**
+
+
+Dependencies: ADV_IMP.1 Implementation representation of the
+TSF
+
+
+Developer action elements:
+
+
+**ALC_TAT.1.1D** **The developer shall provide the documentation identifying each**
+
+**development tool being used for the TOE.**
+
+
+**ALC_TAT.1.2D** **The developer shall document and provide the selected implementation-**
+
+**dependent options of each development tool.**
+
+
+Content and presentation elements:
+
+
+**ALC_TAT.1.1C** **Each development tool used for implementation shall be well-defined.**
+
+
+**ALC_TAT.1.2C** **The documentation of each development tool shall unambiguously**
+
+**define the meaning of all statements as well as all conventions and**
+**directives used in the implementation.**
+
+
+**ALC_TAT.1.3C** **The documentation of each development tool shall unambiguously**
+
+**define the meaning of all implementation-dependent options.**
+
+
+Evaluator action elements:
+
+
+**ALC_TAT.1.1E** **The evaluator** _**shall confirm**_ **that the information provided meets all**
+
+**requirements for content and presentation of evidence.**
+
+
+**ALC_TAT.2** **Compliance with implementation standards**
+
+
+Dependencies: ADV_IMP.1 Implementation representation of the
+TSF
+
+
+Developer action elements:
+
+
+**ALC_TAT.2.1D** The developer shall provide the documentation identifying each development
+
+tool being used for the TOE.
+
+
+**ALC_TAT.2.2D** The developer shall document and provide the selected implementation
+dependent options of each development tool.
+
+
+**ALC_TAT.2.3D** **The developer shall describe and provide the implementation standards**
+
+**that are being applied by the developer.**
+
+
+Content and presentation elements:
+
+
+**ALC_TAT.2.1C** Each development tool used for implementation shall be well-defined.
+
+
+**ALC_TAT.2.2C** The documentation of each development tool shall unambiguously define the
+
+meaning of all statements as well as all conventions and directives used in
+the implementation.
+
+
+Page 164 of 247 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+**ALC_TAT.2.3C** The documentation of each development tool shall unambiguously define the
+
+meaning of all implementation-dependent options.
+
+
+Evaluator action elements:
+
+
+**ALC_TAT.2.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+**ALC_TAT.2.2E** **The evaluator** _**shall confirm**_ **that the implementation standards have**
+
+**been applied.**
+
+
+**ALC_TAT.3** **Compliance with implementation standards - all parts**
+
+
+Dependencies: ADV_IMP.1 Implementation representation of the
+TSF
+
+
+Developer action elements:
+
+
+**ALC_TAT.3.1D** The developer shall provide the documentation identifying each development
+
+tool being used for the TOE.
+
+
+**ALC_TAT.3.2D** The developer shall document and provide the selected implementation
+dependent options of each development tool.
+
+
+**ALC_TAT.3.3D** The developer shall describe and provide the implementation standards that
+
+are being applied by the developer **and** **by** **any** **third-party** **providers** **for**
+**all** **parts** **of** **the** **TOE.**
+
+
+Content and presentation elements:
+
+
+**ALC_TAT.3.1C** Each development tool used for implementation shall be well-defined.
+
+
+**ALC_TAT.3.2C** The documentation of each development tool shall unambiguously define the
+
+meaning of all statements as well as all conventions and directives used in
+the implementation.
+
+
+**ALC_TAT.3.3C** The documentation of each development tool shall unambiguously define the
+
+meaning of all implementation-dependent options.
+
+
+Evaluator action elements:
+
+
+**ALC_TAT.3.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+**ALC_TAT.3.2E** The evaluator _**shall confirm**_ that the implementation standards have been
+
+applied.
+
+
+April 2017 Version 3.1 Page 165 of 247
+
+
+**Class ATE: Tests**
+
+# **16 Class ATE: Tests**
+
+
+418 The class โTestsโ encompasses four families: Coverage (ATE_COV), Depth
+(ATE_DPT), Independent testing (ATE_IND) (i.e. functional testing
+performed by evaluators), and Functional tests (ATE_FUN). Testing
+provides assurance that the TSF behaves as described (in the functional
+specification, TOE design, and implementation representation).
+
+
+419 The emphasis in this class is on confirmation that the TSF operates according
+to its design descriptions. This class does not address penetration testing,
+which is based upon an analysis of the TSF that specifically seeks to identify
+vulnerabilities in the design and implementation of the TSF. Penetration
+testing is addressed separately as an aspect of vulnerability assessment in the
+AVA: Vulnerability assessment class.
+
+
+420 The ATE: Tests class separates testing into developer testing and evaluator
+testing. The Coverage (ATE_COV) and Depth (ATE_DPT) families address
+the completeness of developer testing. Coverage (ATE_COV) addresses the
+rigour with which the functional specification is tested; Depth (ATE_DPT)
+addresses whether testing against other design descriptions (security
+architecture, TOE design, implementation representation) is required.
+
+
+421 Functional tests (ATE_FUN) addresses the performing of the tests by the
+developer and how this testing should be documented. Finally, Independent
+testing (ATE_IND) then addresses evaluator testing: whether the evaluator
+should repeat part or all of the developer testing and how much independent
+testing the evaluator should do.
+
+
+422 Figure 15 shows the families within this class, and the hierarchy of
+components within the families.
+
+
+**Figure 15 - ATE: Tests class decomposition**
+
+
+Page 166 of 247 Version 3.1 April 2017
+
+
+**Class ATE: Tests**
+
+## **16.1 Coverage (ATE_COV)**
+
+
+Objectives
+
+
+423 This family establishes that the TSF has been tested against its functional
+specification. This is achieved through an examination of developer evidence
+of correspondence.
+
+
+Component levelling
+
+
+424 The components in this family are levelled on the basis of specification.
+
+
+Application notes
+
+
+**ATE_COV.1** **Evidence of coverage**
+
+
+Dependencies: ADV_FSP.2 Security-enforcing functional
+specification
+ATE_FUN.1 Functional testing
+
+
+Objectives
+
+
+425 The objective of this component is to establish that some of the TSFIs have
+been tested.
+
+
+Application notes
+
+
+426 In this component the developer shows how tests in the test documentation
+correspond to TSFIs in the functional specification. This can be achieved by
+a statement of correspondence, perhaps using a table.
+
+
+Developer action elements:
+
+
+**ATE_COV.1.1D** **The developer shall provide evidence of the test coverage.**
+
+
+Content and presentation elements:
+
+
+**ATE_COV.1.1C** **The evidence of the test coverage shall show the correspondence between**
+
+**the tests in the test documentation and the TSFIs in the functional**
+**specification.**
+
+
+Evaluator action elements:
+
+
+**ATE_COV.1.1E** **The evaluator** _**shall confirm**_ **that the information provided meets all**
+
+**requirements for content and presentation of evidence.**
+
+
+**ATE_COV.2** **Analysis of coverage**
+
+
+Dependencies: ADV_FSP.2 Security-enforcing functional
+specification
+ATE_FUN.1 Functional testing
+
+
+April 2017 Version 3.1 Page 167 of 247
+
+
+**Class ATE: Tests**
+
+
+Objectives
+
+
+427 The objective of this component is to confirm that all of the TSFIs have been
+tested.
+
+
+Application notes
+
+
+428 In this component the developer confirms that tests in the test documentation
+correspond to all of the TSFIs in the functional specification. This can be
+achieved by a statement of correspondence, perhaps using a table, but the
+developer also provides an analysis of the test coverage.
+
+
+Developer action elements:
+
+
+**ATE_COV.2.1D** The developer shall provide **an** **analysis** of the test coverage.
+
+
+Content and presentation elements:
+
+
+**ATE_COV.2.1C** The **analysis** of the test coverage shall **demonstrate** the correspondence
+
+between the tests in the test documentation and the TSFIs in the functional
+specification.
+
+
+**ATE_COV.2.2C** **The analysis of the test coverage shall demonstrate that all TSFIs in the**
+
+**functional specification have been tested.**
+
+
+Evaluator action elements:
+
+
+**ATE_COV.2.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+**ATE_COV.3** **Rigorous analysis of coverage**
+
+
+Dependencies: ADV_FSP.2 Security-enforcing functional
+specification
+ATE_FUN.1 Functional testing
+
+
+Objectives
+
+
+429 In this component, the objective is to confirm that the developer performed
+exhaustive tests of all interfaces in the functional specification.
+
+
+430 The objective of this component is to confirm that all parameters of all of the
+TSFIs have been tested.
+
+
+Application notes
+
+
+431 In this component the developer is required to show how tests in the test
+documentation correspond to all of the TSFIs in the functional specification.
+This can be achieved by a statement of correspondence, perhaps using a table,
+but in addition the developer is required to demonstrate that the tests exercise
+all of the parameters of all TSFIs. This additional requirement includes
+bounds testing (i.e. verifying that errors are generated when stated limits are
+
+
+Page 168 of 247 Version 3.1 April 2017
+
+
+**Class ATE: Tests**
+
+
+exceeded) and negative testing (e.g. when access is given to User A,
+verifying not only that User A now has access, but also that User B did not
+suddenly gain access). This kind of testing is not, strictly speaking,
+_exhaustive_ because not every possible value of the parameters is expected to
+be checked.
+
+
+Developer action elements:
+
+
+**ATE_COV.3.1D** The developer shall provide an analysis of the test coverage.
+
+
+Content and presentation elements:
+
+
+**ATE_COV.3.1C** The analysis of the test coverage shall demonstrate the correspondence
+
+between the tests in the test documentation and the TSFIs in the functional
+specification.
+
+
+**ATE_COV.3.2C** The analysis of the test coverage shall demonstrate that all TSFIs in the
+
+functional specification have been **completely** tested.
+
+
+Evaluator action elements:
+
+
+**ATE_COV.3.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+April 2017 Version 3.1 Page 169 of 247
+
+
+**Class ATE: Tests**
+
+## **16.2 Depth (ATE_DPT)**
+
+
+Objectives
+
+
+432 The components in this family deal with the level of detail to which the TSF
+is tested by the developer. Testing of the TSF is based upon increasing depth
+of information derived from additional design representations and
+descriptions (TOE design, implementation representation, and security
+architecture description).
+
+
+433 The objective is to counter the risk of missing an error in the development of
+the TOE. Testing that exercises specific internal interfaces can provide
+assurance not only that the TSF exhibits the desired external security
+behaviour, but also that this behaviour stems from correctly operating
+internal functionality.
+
+
+Component levelling
+
+
+434 The components in this family are levelled on the basis of increasing detail
+provided in the TSF representations, from the TOE design to the
+implementation representation. This levelling reflects the TSF
+representations presented in the ADV class.
+
+
+Application notes
+
+
+435 The TOE design describes the internal components (e.g. subsystems) and,
+perhaps, modules of the TSF, together with a description of the interfaces
+among these components and modules. Evidence of testing of this TOE
+design must show that the internal interfaces have been exercised and seen to
+behave as described. This may be achieved through testing via the external
+interfaces of the TSF, or by testing of the TOE subsystem or module
+interfaces in isolation, perhaps employing a test harness. In cases where
+some aspects of an internal interface cannot be tested via the external
+interfaces, there should either be justification that these aspects need not be
+tested, or the internal interface needs to be tested directly. In the latter case
+the TOE design needs to be sufficiently detailed in order to facilitate direct
+testing.
+
+
+436 In cases where the description of the TSF's architectural soundness (in
+Security Architecture (ADV_ARC)) cites specific mechanisms, the tests
+performed by the developer must show that the mechanisms have been
+exercised and seen to behave as described.
+
+
+437 At the highest component of this family, the testing is performed not only
+against the TOE design, but also against the implementation representation.
+
+
+**ATE_DPT.1** **Testing: basic design**
+
+
+Dependencies: ADV_ARC.1 Security architecture description
+ADV_TDS.2 Architectural design
+ATE_FUN.1 Functional testing
+
+
+Page 170 of 247 Version 3.1 April 2017
+
+
+**Class ATE: Tests**
+
+
+Objectives
+
+
+438 The subsystem descriptions of the TSF provide a high-level description of
+the internal workings of the TSF. Testing at the level of the TOE subsystems
+provides assurance that the TSF subsystems behave and interact as described
+in the TOE design and the security architecture description.
+
+
+Developer action elements:
+
+
+**ATE_DPT.1.1D** **The developer shall provide the analysis of the depth of testing.**
+
+
+Content and presentation elements:
+
+
+**ATE_DPT.1.1C** **The analysis of the depth of testing shall demonstrate the**
+
+**correspondence between the tests in the test documentation and the TSF**
+**subsystems in the TOE design.**
+
+
+**ATE_DPT.1.2C** **The analysis of the depth of testing shall demonstrate that all TSF**
+
+**subsystems in the TOE design have been tested.**
+
+
+Evaluator action elements:
+
+
+**ATE_DPT.1.1E** **The evaluator** _**shall confirm**_ **that the information provided meets all**
+
+**requirements for content and presentation of evidence.**
+
+
+**ATE_DPT.2** **Testing: security enforcing modules**
+
+
+Dependencies: ADV_ARC.1 Security architecture description
+ADV_TDS.3 Basic modular design
+ATE_FUN.1 Functional testing
+
+
+Objectives
+
+
+439 The subsystem and module descriptions of the TSF provide a high-level
+description of the internal workings, and a description of the interfaces of the
+SFR-enforcing modules, of the TSF. Testing at this level of TOE description
+provides assurance that the TSF subsystems and SFR-enforcing modules
+behave and interact as described in the TOE design and the security
+architecture description.
+
+
+Developer action elements:
+
+
+**ATE_DPT.2.1D** The developer shall provide the analysis of the depth of testing.
+
+
+Content and presentation elements:
+
+
+**ATE_DPT.2.1C** The analysis of the depth of testing shall demonstrate the correspondence
+
+between the tests in the test documentation and the TSF subsystems **and**
+**SFR-enforcing** **modules** in the TOE design.
+
+
+**ATE_DPT.2.2C** The analysis of the depth of testing shall demonstrate that all TSF
+
+subsystems in the TOE design have been tested.
+
+
+April 2017 Version 3.1 Page 171 of 247
+
+
+**Class ATE: Tests**
+
+
+**ATE_DPT.2.3C** **The analysis of the depth of testing shall demonstrate that the SFR-**
+
+**enforcing modules in the TOE design have been tested.**
+
+
+Evaluator action elements:
+
+
+**ATE_DPT.2.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+**ATE_DPT.3** **Testing: modular design**
+
+
+Dependencies: ADV_ARC.1 Security architecture description
+ADV_TDS.4 Semiformal modular design
+ATE_FUN.1 Functional testing
+
+
+Objectives
+
+
+440 The subsystem and module descriptions of the TSF provide a high-level
+description of the internal workings, and a description of the interfaces of the
+modules, of the TSF. Testing at this level of TOE description provides
+assurance that the TSF subsystems and modules behave and interact as
+described in the TOE design and the security architecture description.
+
+
+Developer action elements:
+
+
+**ATE_DPT.3.1D** The developer shall provide the analysis of the depth of testing.
+
+
+Content and presentation elements:
+
+
+**ATE_DPT.3.1C** The analysis of the depth of testing shall demonstrate the correspondence
+
+between the tests in the test documentation and the TSF subsystems and
+modules in the TOE design.
+
+
+**ATE_DPT.3.2C** The analysis of the depth of testing shall demonstrate that all TSF
+
+subsystems in the TOE design have been tested.
+
+
+**ATE_DPT.3.3C** The analysis of the depth of testing shall demonstrate that **all** **TSF** modules
+
+in the TOE design have been tested.
+
+
+Evaluator action elements:
+
+
+**ATE_DPT.3.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+**ATE_DPT.4** **Testing: implementation representation**
+
+
+Dependencies: ADV_ARC.1 Security architecture description
+ADV_TDS.4 Semiformal modular design
+ADV_IMP.1 Implementation representation of the
+TSF
+ATE_FUN.1 Functional testing
+
+
+Page 172 of 247 Version 3.1 April 2017
+
+
+**Class ATE: Tests**
+
+
+Objectives
+
+
+441 The subsystem and module descriptions of the TSF provide a high-level
+description of the internal workings, and a description of the interfaces of the
+modules, of the TSF. Testing at this level of TOE description provides
+assurance that the TSF subsystems and modules behave and interact as
+described in the TOE design and the security architecture description, and in
+accordance with the implementation representation.
+
+
+Developer action elements:
+
+
+**ATE_DPT.4.1D** The developer shall provide the analysis of the depth of testing.
+
+
+Content and presentation elements:
+
+
+**ATE_DPT.4.1C** The analysis of the depth of testing shall demonstrate the correspondence
+
+between the tests in the test documentation and the TSF subsystems and
+modules in the TOE design.
+
+
+**ATE_DPT.4.2C** The analysis of the depth of testing shall demonstrate that all TSF
+
+subsystems in the TOE design have been tested.
+
+
+**ATE_DPT.4.3C** The analysis of the depth of testing shall demonstrate that all modules in the
+
+TOE design have been tested.
+
+
+**ATE_DPT.4.4C** **The analysis of the depth of testing shall demonstrate that the TSF**
+
+**operates in accordance with its implementation representation.**
+
+
+Evaluator action elements:
+
+
+**ATE_DPT.4.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+April 2017 Version 3.1 Page 173 of 247
+
+
+**Class ATE: Tests**
+
+## **16.3 Functional tests (ATE_FUN)**
+
+
+Objectives
+
+
+442 Functional testing performed by the developer provides assurance that the
+tests in the test documentation are performed and documented correctly. The
+correspondence of these tests to the design descriptions of the TSF is
+achieved through the Coverage (ATE_COV) and Depth (ATE_DPT)
+families.
+
+
+443 This family contributes to providing assurance that the likelihood of
+undiscovered flaws is relatively small.
+
+
+444 The families Coverage (ATE_COV), Depth (ATE_DPT) and Functional tests
+(ATE_FUN) are used in combination to define the evidence of testing to be
+supplied by a developer. Independent functional testing by the evaluator is
+specified by Independent testing (ATE_IND).
+
+
+Component levelling
+
+
+445 This family contains two components, the higher requiring that ordering
+dependencies are analysed.
+
+
+Application notes
+
+
+446 Procedures for performing tests are expected to provide instructions for using
+test programs and test suites, including the test environment, test conditions,
+test data parameters and values. The test procedures should also show how
+the test results are derived from the test inputs.
+
+
+447 Ordering dependencies are relevant when the successful execution of a
+particular test depends upon the existence of a particular state. For example,
+this might require that test A be executed immediately before test B, since
+the state resulting from the successful execution of test A is a prerequisite for
+the successful execution of test B. Thus, failure of test B could be related to a
+problem with the ordering dependencies. In the above example, test B could
+fail because test C (rather than test A) was executed immediately before it, or
+the failure of test B could be related to a failure of test A.
+
+
+**ATE_FUN.1** **Functional testing**
+
+
+Dependencies: ATE_COV.1 Evidence of coverage
+
+
+Objectives
+
+
+448 The objective is for the developer to demonstrate that the tests in the test
+documentation are performed and documented correctly.
+
+
+Developer action elements:
+
+
+**ATE_FUN.1.1D** **The developer shall test the TSF and document the results.**
+
+
+Page 174 of 247 Version 3.1 April 2017
+
+
+**Class ATE: Tests**
+
+
+**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 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.**
+
+
+**ATE_FUN.2** **Ordered functional testing**
+
+
+Dependencies: ATE_COV.1 Evidence of coverage
+
+
+Objectives
+
+
+449 The objectives are for the developer to demonstrate that the tests in the test
+documentation are performed and documented correctly, and to ensure that
+testing is structured such as to avoid circular arguments about the correctness
+of the interfaces being tested.
+
+
+Application notes
+
+
+450 Although the test procedures may state pre-requisite initial test conditions in
+terms of ordering of tests, they may not provide a rationale for the ordering.
+An analysis of test ordering is an important factor in determining the
+adequacy of testing, as there is a possibility of faults being concealed by the
+ordering of tests.
+
+
+Developer action elements:
+
+
+**ATE_FUN.2.1D** The developer shall test the TSF and document the results.
+
+
+**ATE_FUN.2.2D** The developer shall provide test documentation.
+
+
+Content and presentation elements:
+
+
+**ATE_FUN.2.1C** The test documentation shall consist of test plans, expected test results and
+
+actual test results.
+
+
+April 2017 Version 3.1 Page 175 of 247
+
+
+**Class ATE: Tests**
+
+
+**ATE_FUN.2.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.2.3C** The expected test results shall show the anticipated outputs from a successful
+
+execution of the tests.
+
+
+**ATE_FUN.2.4C** The actual test results shall be consistent with the expected test results.
+
+
+**ATE_FUN.2.5C** **The test documentation shall include an analysis of the test procedure**
+
+**ordering dependencies.**
+
+
+Evaluator action elements:
+
+
+**ATE_FUN.2.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+Page 176 of 247 Version 3.1 April 2017
+
+
+**Class ATE: Tests**
+
+## **16.4 Independent testing (ATE_IND)**
+
+
+Objectives
+
+
+451 The objectives of this family are built upon the assurances achieved in the
+ATE_FUN, ATE_COV, and ATE_DPT families by verifying the developer
+testing and performing additional tests by the evaluator.
+
+
+Component levelling
+
+
+452 Levelling is based upon the amount of developer test documentation and test
+support and the amount of evaluator testing.
+
+
+Application notes
+
+
+453 This family deals with the degree to which there is independent functional
+testing of the TSF. Independent functional testing may take the form of
+repeating the developer's functional tests (in whole or in part) or of extending
+the scope or the depth of the developer's tests. These activities are
+complementary, and an appropriate mix must be planned for each TOE,
+which takes into account the availability and coverage of test results, and the
+functional complexity of the TSF.
+
+
+454 Sampling of developer tests is intended to provide confirmation that the
+developer has carried out his planned test programme on the TSF, and has
+correctly recorded the results. The size of sample selected will be influenced
+by the detail and quality of the developer's functional test results. The
+evaluator will also need to consider the scope for devising additional tests,
+and the relative benefit that may be gained from effort in these two areas. It
+is recognised that repetition of all developer tests may be feasible and
+desirable in some cases, but may be very arduous and less productive in
+others. The highest component in this family should therefore be used with
+caution. Sampling will address the whole range of test results available,
+including those supplied to meet the requirements of both Coverage
+(ATE_COV) and Depth (ATE_DPT).
+
+
+455 There is also a need to consider the different configurations of the TOE that
+are included within the evaluation. The evaluator will need to assess the
+applicability of the results provided, and to plan his own testing accordingly.
+
+
+456 The suitability of the TOE for testing is based on the access to the TOE, and
+the supporting documentation and information required (including any test
+software or tools) to run tests. The need for such support is addressed by the
+dependencies to other assurance families.
+
+
+457 Additionally, suitability of the TOE for testing may be based on other
+considerations. For example, the version of the TOE submitted by the
+developer may not be the final version.
+
+
+458 The term _interfaces_ refers to interfaces described in the functional
+specification and TOE design, and parameters passed through invocations
+
+
+April 2017 Version 3.1 Page 177 of 247
+
+
+**Class ATE: Tests**
+
+
+identified in the implementation representation. The exact set of interfaces to
+be used is selected through Coverage (ATE_COV) and the Depth
+(ATE_DPT) components.
+
+
+459 References to a subset of the interfaces are intended to allow the evaluator to
+design an appropriate set of tests which is consistent with the objectives of
+the evaluation being conducted.
+
+
+**ATE_IND.1** **Independent testing - conformance**
+
+
+Dependencies: ADV_FSP.1 Basic functional specification
+AGD_OPE.1 Operational user guidance
+AGD_PRE.1 Preparative procedures
+
+
+Objectives
+
+
+460 In this component, the objective is to demonstrate that the TOE operates in
+accordance with its design representations and guidance documents.
+
+
+Application notes
+
+
+461 This component does not address the use of developer test results. It is
+applicable where such results are not available, and also in cases where the
+developer's testing is accepted without validation. The evaluator is required
+to devise and conduct tests with the objective of confirming that the TOE
+operates in accordance with its design representations, including but not
+limited to the functional specification. The approach is to gain confidence in
+correct operation through representative testing, rather than to conduct every
+possible test. The extent of testing to be planned for this purpose is a
+methodology issue, and needs to be considered in the context of a particular
+TOE and the balance of other evaluation activities.
+
+
+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.**
+
+
+Page 178 of 247 Version 3.1 April 2017
+
+
+**Class ATE: Tests**
+
+
+**ATE_IND.2** **Independent testing - sample**
+
+
+Dependencies: ADV_FSP.2 Security-enforcing functional
+specification
+AGD_OPE.1 Operational user guidance
+AGD_PRE.1 Preparative procedures
+ATE_COV.1 Evidence of coverage
+ATE_FUN.1 Functional testing
+
+
+Objectives
+
+
+462 In this component, the objective is to demonstrate that the TOE operates in
+accordance with its design representations and guidance documents.
+Evaluator testing confirms that the developer performed some tests of some
+interfaces in the functional specification.
+
+
+Application notes
+
+
+463 The intent is that the developer should provide the evaluator with materials
+necessary for the efficient reproduction of developer tests. This may include
+such things as machine-readable test documentation, test programs, etc.
+
+
+464 This component contains a requirement that the evaluator has available test
+results from the developer to supplement the programme of testing. The
+evaluator will repeat a sample of the developer's tests to gain confidence in
+the results obtained. Having established such confidence the evaluator will
+build upon the developer's testing by conducting additional tests that exercise
+the TOE in a different manner. By using a platform of validated developer
+test results the evaluator is able to gain confidence that the TOE operates
+correctly in a wider range of conditions than would be possible purely using
+the developer's own efforts, given a fixed level of resource. Having gained
+confidence that the developer has tested the TOE, the evaluator will also
+have more freedom, where appropriate, to concentrate testing in areas where
+examination of documentation or specialist knowledge has raised particular
+concerns.
+
+
+Developer action elements:
+
+
+**ATE_IND.2.1D** The developer shall provide the TOE for testing.
+
+
+Content and presentation elements:
+
+
+**ATE_IND.2.1C** The TOE shall be suitable for testing.
+
+
+**ATE_IND.2.2C** **The developer shall provide an equivalent set of resources to those that**
+
+**were used in the developer's functional testing of the TSF.**
+
+
+Evaluator action elements:
+
+
+**ATE_IND.2.1E** The evaluator _**shall confirm**_ that the information provided meets all
+requirements for content and presentation of evidence.
+
+
+April 2017 Version 3.1 Page 179 of 247
+
+
+**Class ATE: Tests**
+
+
+**ATE_IND.2.2E** **The evaluator** _**shall execute**_ **a sample of tests in the test documentation to**
+**verify the developer test results.**
+
+
+**ATE_IND.2.3E** The evaluator _**shall test**_ a subset of the TSF to confirm that the TSF operates
+as specified.
+
+
+**ATE_IND.3** **Independent testing - complete**
+
+
+Dependencies: ADV_FSP.4 Complete functional specification
+AGD_OPE.1 Operational user guidance
+AGD_PRE.1 Preparative procedures
+ATE_COV.1 Evidence of coverage
+ATE_FUN.1 Functional testing
+
+
+Objectives
+
+
+465 In this component, the objective is to demonstrate that the TOE operates in
+accordance with its design representations and guidance documents.
+Evaluator testing includes repeating all of the developer tests.
+
+
+Application notes
+
+
+466 The intent is that the developer should provide the evaluator with materials
+necessary for the efficient reproduction of developer tests. This may include
+such things as machine-readable test documentation, test programs, etc.
+
+
+467 In this component the evaluator must repeat all of the developer's tests as
+part of the programme of testing. As in the previous component the evaluator
+will also conduct tests that aim to exercise the TSF in a different manner
+from that achieved by the developer. In cases where developer testing has
+been exhaustive, there may remain little scope for this.
+
+
+Developer action elements:
+
+
+**ATE_IND.3.1D** The developer shall provide the TOE for testing.
+
+
+Content and presentation elements:
+
+
+**ATE_IND.3.1C** The TOE shall be suitable for testing.
+
+
+**ATE_IND.3.2C** The developer shall provide an equivalent set of resources to those that were
+
+used in the developer's functional testing of the TSF.
+
+
+Evaluator action elements:
+
+
+**ATE_IND.3.1E** The evaluator _**shall confirm**_ that the information provided meets all
+requirements for content and presentation of evidence.
+
+
+**ATE_IND.3.2E** The evaluator _**shall execute**_ **all** tests in the test documentation to verify the
+developer test results.
+
+
+Page 180 of 247 Version 3.1 April 2017
+
+
+**Class ATE: Tests**
+
+
+**ATE_IND.3.3E** The evaluator _**shall test**_ the TSF to confirm that the **entire** TSF operates as
+specified.
+
+
+April 2017 Version 3.1 Page 181 of 247
+
+
+**Class AVA: Vulnerability assessment**
+
+# **17 Class AVA: Vulnerability assessment**
+
+
+468 The AVA: Vulnerability assessment class addresses the possibility of
+exploitable vulnerabilities introduced in the development or the operation of
+the TOE.
+
+
+469 Figure 16 shows the families within this class, and the hierarchy of
+components within the families.
+
+
+**Figure 16 - AVA: Vulnerability assessment class decomposition**
+
+
+Application notes
+
+
+470 Generally, the vulnerability assessment activity covers various vulnerabilities
+in the development and operation of the TOE. Development vulnerabilities
+take advantage of some property of the TOE which was introduced during its
+development, e.g. defeating the TSF self protection through tampering, direct
+attack or monitoring of the TSF, defeating the TSF domain separation
+through monitoring or direct attack the TSF, or defeating non-bypassability
+through circumventing (bypassing) the TSF. Operational vulnerabilities take
+advantage of weaknesses in non-technical countermeasures to violate the
+TOE SFRs, e.g. misuse or incorrect configuration. Misuse investigates
+whether the TOE can be configured or used in a manner that is insecure, but
+that an administrator or user of the TOE would reasonably believe to be
+secure.
+
+
+471 Assessment of development vulnerabilities is covered by the assurance
+family AVA_VAN. Basically, all development vulnerabilities can be
+considered in the context of AVA_VAN due to the fact, that this family
+allows application of a wide range of assessment methodologies being
+unspecific to the kind of an attack scenario. These unspecific assessment
+methodologies comprise, among other, also the specific methodologies for
+those TSF where covert channels are to be considered (a channel capacity
+estimation can be done using informal engineering measurements, as well as
+actual test measurements) or can be overcome by the use of sufficient
+resources in the form of a direct attack (underlying technical concept of those
+TSF is based on probabilistic or permutational mechanisms; a qualification
+of their security behaviour and the effort required to overcome them can be
+made using a quantitative or statistical analysis).
+
+
+472 If there are security objectives specified in the ST to either to prevent one
+user of the TOE from observing activity associated with another user of the
+TOE, or to ensure that information flows cannot be used to achieve enforced
+illicit data signals, covert channel analysis should be considered during the
+conduct of the vulnerability analysis. This is often reflected by the inclusion
+of Unobservability (FPR_UNO) and multilevel access control policies
+
+
+Page 182 of 247 Version 3.1 April 2017
+
+
+**Class AVA: Vulnerability assessment**
+
+
+specified through Access control policy (FDP_ACC) and/or Information
+flow control policy (FDP_IFC) requirements in the ST.
+
+
+April 2017 Version 3.1 Page 183 of 247
+
+
+**Class AVA: Vulnerability assessment**
+
+## **17.1 Vulnerability analysis (AVA_VAN)**
+
+
+Objectives
+
+
+473 Vulnerability analysis is an assessment to determine whether potential
+vulnerabilities identified, during the evaluation of the development and
+anticipated operation of the TOE or by other methods (e.g. by flaw
+hypotheses or quantitative or statistical analysis of the security behaviour of
+the underlying security mechanisms), could allow attackers to violate the
+SFRs.
+
+
+474 Vulnerability analysis deals with the threats that an attacker will be able to
+discover flaws that will allow unauthorised access to data and functionality,
+allow the ability to interfere with or alter the TSF, or interfere with the
+authorised capabilities of other users.
+
+
+Component levelling
+
+
+475 Levelling is based on an increasing rigour of vulnerability analysis by the
+evaluator and increased levels of attack potential required by an attacker to
+identify and exploit the potential vulnerabilities.
+
+
+**AVA_VAN.1** **Vulnerability survey**
+
+
+Dependencies: ADV_FSP.1 Basic functional specification
+AGD_OPE.1 Operational user guidance
+AGD_PRE.1 Preparative procedures
+
+
+Objectives
+
+
+476 A vulnerability survey of information available in the public domain is
+performed by the evaluator to ascertain potential vulnerabilities that may be
+easily found by an attacker.
+
+
+477 The evaluator performs penetration testing, to confirm that the potential
+vulnerabilities cannot be exploited in the operational environment for the
+TOE. Penetration testing is performed by the evaluator assuming an attack
+potential of Basic.
+
+
+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**
+
+**requirements for content and presentation of evidence.**
+
+
+Page 184 of 247 Version 3.1 April 2017
+
+
+**Class AVA: Vulnerability assessment**
+
+
+**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 possessing Basic attack potential.**
+
+
+**AVA_VAN.2** **Vulnerability analysis**
+
+
+Dependencies: ADV_ARC.1 Security architecture description
+ADV_FSP.2 Security-enforcing functional
+specification
+ADV_TDS.1 Basic design
+AGD_OPE.1 Operational user guidance
+AGD_PRE.1 Preparative procedures
+
+
+Objectives
+
+
+478 A vulnerability analysis is performed by the evaluator to ascertain the
+presence of potential vulnerabilities.
+
+
+479 The evaluator performs penetration testing, to confirm that the potential
+vulnerabilities cannot be exploited in the operational environment for the
+TOE. Penetration testing is performed by the evaluator assuming an attack
+potential of Basic.
+
+
+Developer action elements:
+
+
+**AVA_VAN.2.1D** The developer shall provide the TOE for testing.
+
+
+Content and presentation elements:
+
+
+**AVA_VAN.2.1C** The TOE shall be suitable for testing.
+
+
+Evaluator action elements:
+
+
+**AVA_VAN.2.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+**AVA_VAN.2.2E** The evaluator _**shall perform**_ a search of public domain sources to identify
+
+potential vulnerabilities in the TOE.
+
+
+**AVA_VAN.2.3E** **The evaluator** _**shall perform**_ **an independent vulnerability analysis of the**
+
+**TOE using the guidance documentation, functional specification, TOE**
+**design and security architecture description to identify potential**
+**vulnerabilities in the TOE.**
+
+
+**AVA_VAN.2.4E** 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 possessing Basic attack potential.
+
+
+April 2017 Version 3.1 Page 185 of 247
+
+
+**Class AVA: Vulnerability assessment**
+
+
+**AVA_VAN.3** **Focused vulnerability analysis**
+
+
+Dependencies: ADV_ARC.1 Security architecture description
+ADV_FSP.4 Complete functional specification
+ADV_TDS.3 Basic modular design
+ADV_IMP.1 Implementation representation of the
+TSF
+AGD_OPE.1 Operational user guidance
+AGD_PRE.1 Preparative procedures
+ATE_DPT.1 Testing: basic design
+
+
+Objectives
+
+
+480 A vulnerability analysis is performed by the evaluator to ascertain the
+presence of potential vulnerabilities.
+
+
+481 The evaluator performs penetration testing, to confirm that the potential
+vulnerabilities cannot be exploited in the operational environment for the
+TOE. Penetration testing is performed by the evaluator assuming an attack
+potential of Enhanced-Basic.
+
+
+Developer action elements:
+
+
+**AVA_VAN.3.1D** The developer shall provide the TOE for testing.
+
+
+Content and presentation elements:
+
+
+**AVA_VAN.3.1C** The TOE shall be suitable for testing.
+
+
+Evaluator action elements:
+
+
+**AVA_VAN.3.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+**AVA_VAN.3.2E** The evaluator _**shall perform**_ a search of public domain sources to identify
+
+potential vulnerabilities in the TOE.
+
+
+**AVA_VAN.3.3E** The evaluator _**shall perform**_ an independent, **focused** vulnerability analysis
+
+of the TOE using the guidance documentation, functional specification, TOE
+design, security architecture description **and** **implementation**
+**representation** to identify potential vulnerabilities in the TOE.
+
+
+**AVA_VAN.3.4E** 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 possessing **Enhanced-Basic** attack potential.
+
+
+**AVA_VAN.4** **Methodical vulnerability analysis**
+
+
+Dependencies: ADV_ARC.1 Security architecture description
+ADV_FSP.4 Complete functional specification
+ADV_TDS.3 Basic modular design
+
+
+Page 186 of 247 Version 3.1 April 2017
+
+
+**Class AVA: Vulnerability assessment**
+
+
+ADV_IMP.1 Implementation representation of the
+TSF
+AGD_OPE.1 Operational user guidance
+AGD_PRE.1 Preparative procedures
+ATE_DPT.1 Testing: basic design
+
+
+Objectives
+
+
+482 A methodical vulnerability analysis is performed by the evaluator to
+ascertain the presence of potential vulnerabilities.
+
+
+483 The evaluator performs penetration testing, to confirm that the potential
+vulnerabilities cannot be exploited in the operational environment for the
+TOE. Penetration testing is performed by the evaluator assuming an attack
+potential of Moderate.
+
+
+Developer action elements:
+
+
+**AVA_VAN.4.1D** The developer shall provide the TOE for testing.
+
+
+Content and presentation elements:
+
+
+**AVA_VAN.4.1C** The TOE shall be suitable for testing.
+
+
+Evaluator action elements:
+
+
+**AVA_VAN.4.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+**AVA_VAN.4.2E** The evaluator _**shall perform**_ a search of public domain sources to identify
+
+potential vulnerabilities in the TOE.
+
+
+**AVA_VAN.4.3E** The evaluator _**shall perform**_ an independent, **methodical** vulnerability
+
+analysis of the TOE using the guidance documentation, functional
+specification, TOE design, security architecture description and
+implementation representation to identify potential vulnerabilities in the TOE.
+
+
+**AVA_VAN.4.4E** 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 possessing **Moderate** attack potential.
+
+
+**AVA_VAN.5** **Advanced methodical vulnerability analysis**
+
+
+Dependencies: ADV_ARC.1 Security architecture description
+ADV_FSP.4 Complete functional specification
+ADV_TDS.3 Basic modular design
+ADV_IMP.1 Implementation representation of the
+TSF
+AGD_OPE.1 Operational user guidance
+AGD_PRE.1 Preparative procedures
+ATE_DPT.1 Testing: basic design
+
+
+April 2017 Version 3.1 Page 187 of 247
+
+
+**Class AVA: Vulnerability assessment**
+
+
+Objectives
+
+
+484 A methodical vulnerability analysis is performed by the evaluator to
+ascertain the presence of potential vulnerabilities.
+
+
+485 The evaluator performs penetration testing, to confirm that the potential
+vulnerabilities cannot be exploited in the operational environment for the
+TOE. Penetration testing is performed by the evaluator assuming an attack
+potential of High.
+
+
+Developer action elements:
+
+
+**AVA_VAN.5.1D** The developer shall provide the TOE for testing.
+
+
+Content and presentation elements:
+
+
+**AVA_VAN.5.1C** The TOE shall be suitable for testing.
+
+
+Evaluator action elements:
+
+
+**AVA_VAN.5.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+**AVA_VAN.5.2E** The evaluator _**shall perform**_ a search of public domain sources to identify
+
+potential vulnerabilities in the TOE.
+
+
+**AVA_VAN.5.3E** The evaluator _**shall perform**_ an independent, methodical vulnerability
+
+analysis of the TOE using the guidance documentation, functional
+specification, TOE design, security architecture description and
+implementation representation to identify potential vulnerabilities in the TOE.
+
+
+**AVA_VAN.5.4E** 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 possessing **High** attack potential.
+
+
+Page 188 of 247 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+# **18 Class ACO: Composition**
+
+
+486 The class ACO: Composition encompasses five families. These families
+specify assurance requirements that are designed to provide confidence that a
+composed TOE will operate securely when relying upon security
+functionality provided by previously evaluated software, firmware or
+hardware components.
+
+
+487 Composition involves taking two or more IT entities successfully evaluated
+against CC security assurance requirements packages (base components and
+dependent components, see Annex B) and combining them for use, with no
+further development of either IT entity. The development of additional IT
+entities is not included (entities that have not previously been the subject of a
+component evaluation). The composed TOE forms a new product that can be
+installed and integrated into any specific environment instance that meets the
+objectives for the environment.
+
+
+488 This approach does not provide an alternative approach for the evaluation of
+components. Composition under ACO provides a composed TOE integrator
+a method, which can be used as an alternative to other assurance levels
+specified in the CC, to gain confidence in a TOE that is the combination of
+two or more successfully evaluated components without having to reevaluate the composite TSF. (The composed TOE integrator is referred to as
+โdeveloperโ throughout the ACO class, with any references to the developer
+of the base or dependent components clarified as such.)
+
+
+489 Composed Assurance Packages, as defined in Chapters 9 and 7.3, is an
+assurance scale for composed TOEs. This assurance scale is required in
+addition to EALs because to combine components evaluated against EALs
+and gain a resulting EAL assurance, all SARs in the EAL have to be applied
+to the composed TOE. Although reuse can be made of the component TOE
+evaluation results, there are often additional aspects of the components that
+have to be considered in the composed TOE, as described in Annex B.3. Due
+to the different parties involved in a composed TOE evaluation activity it is
+generally not possible to gain all necessary evidence about these additional
+aspects of the components to apply the appropriate EAL. Hence, CAPs have
+been defined to address the issue of combining evaluated components and
+gaining a meaningful result. This is discussed further in Annex B.
+
+
+April 2017 Version 3.1 Page 189 of 247
+
+
+**Class ACO: Composition**
+
+
+**Figure 17 - Relationship between ACO families and interactions between**
+
+**components**
+
+
+490 In a composed TOE it is generally the case that one component relies on the
+services provided by another component. The component requiring services
+is termed the dependent component and the component providing the
+services is termed the base component. This interaction and distinct is
+discussed further in Annex B. It is assumed to be the case that the developer
+of the dependent component is supporting the composed TOE evaluation in
+some manner (as developer, sponsor, or just cooperating and providing the
+necessary evaluation evidence from the dependent component evaluation)
+The ACO components included in the CAP assurance packages should not
+be used as augmentations for component TOE evaluations, as this would
+provide no meaningful assurance for the component.
+
+
+491 The families within the ACO class interact in a similar manner to the ADV,
+ATE and AVA classes in a component TOE evaluation and hence leverage
+from the specification of requirements from those classes where applicable.
+There are however a few items specific to composed TOE evaluations. To
+determine how the components interact and identify any deviations from the
+evaluations of the components, the dependencies that the dependent
+component has upon the underlying base component are identified
+(ACO_REL). This reliance on the base component is specified in terms of
+the interfaces through which the dependent component makes calls for
+services in support of the dependent component SFRs. The interfaces, and at
+higher levels the supporting behaviour, provided by the base component in
+response to those service requests are analysed in ACO_DEV. The
+ACO_DEV family is based on the ADV_TDS family, as at the simplest level
+the TSF of each component can be viewed as a subsystem of the composed
+TOE, with additional portions of each component seen as additional
+subsystems. Therefore, the interfaces between the components are seen as
+interactions between subsystems in a component TOE evaluation.
+
+
+Page 190 of 247 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+
+492 It is possible that the interfaces and supporting behaviour descriptions
+provided for ACO_DEV are incomplete. This is determined during the
+conduct of ACO_COR. The ACO_COR family takes the outputs of
+ACO_REL and ACO_DEV and determines whether the components are
+being used in their evaluated configuration and identifies where any
+specifications are incomplete, which are then identified as inputs into testing
+(ACO_CTT) and vulnerability analysis (ACO_VUL) activities of the
+composed TOE.
+
+
+493 Testing of the composed TOE is performed to determine that the composed
+TOE exhibits the expected behaviour as determined by the composed TOE
+SFRs, and at higher levels demonstrates the compatibility of the interfaces
+between the components of the composed TOE.
+
+
+494 The vulnerability analysis of the composed TOE leverages from the outputs
+of the vulnerability analysis of the component evaluations. The composed
+TOE vulnerability analysis considers any residual vulnerabilities from the
+component evaluations to determine that the residual vulnerabilities are not
+applicable to the composed TOE. A search of publicly available information
+relating to the components is also performed to identify any issues reported
+in the components since the completion of the respective evaluations.
+
+
+495 The interaction between the ACO families is depicted in Figure 18 below.
+This shows by solid arrowed lines where the evidence and understanding
+gained in one family feeds into the next activity and the dashed arrows
+identify where an activity explicitly traces back to the composed TOE SFRs,
+as described above.
+
+
+**Figure 18 - Relationship between ACO families**
+
+
+496 Further discussion of the definition and interactions within composed TOEs
+is provided in Annex B.
+
+
+497 Figure 19 shows the families within this class, and the hierarchy of
+components within the families.
+
+
+April 2017 Version 3.1 Page 191 of 247
+
+
+**Class ACO: Composition**
+
+
+**Figure 19 - ACO: Composition class decomposition**
+
+
+Page 192 of 247 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+## **18.1 Composition rationale (ACO_COR)**
+
+
+Objectives
+
+
+498 This family addresses the requirement to demonstrate that the base
+component can provide an appropriate level of assurance for use in
+composition.
+
+
+Component levelling
+
+
+499 There is only a single component in this family.
+
+
+**ACO_COR.1** **Composition rationale**
+
+
+Dependencies: ACO_DEV.1 Functional Description
+ALC_CMC.1 Labelling of the TOE
+ACO_REL.1 Basic reliance information
+
+
+Developer action elements:
+
+
+**ACO_COR.1.1D** **The developer shall provide composition rationale for the base**
+
+**component.**
+
+
+Content and presentation elements:
+
+
+**ACO_COR.1.1C** **The composition rationale shall demonstrate that a level of assurance at**
+
+**least as high as that of the dependent component has been obtained for**
+**the support functionality of the base component, when the base**
+**component is configured as required to support the TSF of the**
+**dependent component.**
+
+
+Evaluator action elements:
+
+
+**ACO_COR.1.1E** **The evaluator** _**shall confirm**_ **that the information meets all requirements**
+
+**for content and presentation of evidence.**
+
+
+April 2017 Version 3.1 Page 193 of 247
+
+
+**Class ACO: Composition**
+
+## **18.2 Development evidence (ACO_DEV)**
+
+
+Objectives
+
+
+500 This family sets out requirements for a specification of the base component
+in increasing levels of detail. Such information is required to gain confidence
+that the appropriate security functionality is provided to support the
+requirements of the dependent component (as identified in the reliance
+information).
+
+
+Component levelling
+
+
+501 The components are levelled on the basis of increasing amounts of detail
+about the interfaces provided, and how they are implemented.
+
+
+Application notes
+
+
+502 The TSF of the base component is often defined without knowledge of the
+dependencies of the possible applications with which it may by composed.
+The TSF of this base component is defined to include all parts of the base
+component that have to be relied upon for enforcement of the base
+component SFRs. This will include all parts of the base component required
+to implement the base component SFRs.
+
+
+503 The functional specification of the base component will describe the TSFI in
+terms of the interfaces the base component provides to allow an external
+entity to invoke operations of the TSF. This includes interfaces to the human
+user to permit interaction with the operation of the TSF invoking SFRs and
+also interfaces allowing an external IT entity to make calls into the TSF.
+
+
+504 The functional specification only provides a description of what the TSF
+provides at its interface and the means by which that TSF functionality are
+invoked. Therefore, the functional specification does not necessarily provide
+a complete interface specification of all possible interfaces available between
+an external entity and the base component. It does not include what the TSF
+expects/requires from the operational environment. The description of what a
+dependent component TSF relies upon of a base component is considered in
+Reliance of dependent component (ACO_REL) and the development
+information evidence provides a response to the interfaces specified.
+
+
+505 The development information evidence includes a specification of the base
+component. This may be the evidence used during evaluation of the base
+component to satisfy the ADV requirements, or may be another form of
+evidence produced by either the base component developer or the composed
+TOE developer. This specification of the base component is used during
+Development evidence (ACO_DEV) to gain confidence that the appropriate
+security functionality is provided to support the requirements of the
+dependent component. The level of detail required of this evidence increases
+to reflect the level of required assurance in the composed TOE. This is
+expected to broadly reflect the increasing confidence gained from the
+application of the assurance packages to the components. The evaluator
+
+
+Page 194 of 247 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+
+determines that this description of the base component is consistent with the
+reliance information provided for the dependent component.
+
+
+**ACO_DEV.1** **Functional Description**
+
+
+Dependencies: ACO_REL.1 Basic reliance information
+
+
+Objectives
+
+
+506 A description of the interfaces in the base component, on which the
+dependent component relies, is required. This is examined to determine
+whether or not it is consistent with the description of interfaces on which the
+dependent component relies, as provided in the reliance information.
+
+
+Developer action elements:
+
+
+**ACO_DEV.1.1D** **The developer shall provide development information for the base**
+
+**component.**
+
+
+Content and presentation elements:
+
+
+**ACO_DEV.1.1C** **The development information shall describe the purpose of each**
+
+**interface of the base component used in the composed TOE.**
+
+
+**ACO_DEV.1.2C** **The development information shall show correspondence between the**
+
+**interfaces, used in the composed TOE, of the base component and the**
+**dependent component to support the TSF of the dependent component.**
+
+
+Evaluator action elements:
+
+
+**ACO_DEV.1.1E** **The evaluator** _**shall confirm**_ **that the information meets all requirements**
+
+**for content and presentation of evidence.**
+
+
+**ACO_DEV.1.2E** **The evaluator** _**shall determine**_ **that the interface description provided is**
+
+**consistent with the reliance information provided for the dependent**
+**component.**
+
+
+**ACO_DEV.2** **Basic evidence of design**
+
+
+Dependencies: ACO_REL.1 Basic reliance information
+
+
+Objectives
+
+
+507 A description of the interfaces in the base component, on which the
+dependent component relies, is required. This is examined to determine
+whether or not it is consistent with the description of interfaces on which the
+dependent component relies, as provided in the reliance information.
+
+
+508 In addition, the security behaviour of the base component that supports the
+dependent component TSF is described.
+
+
+April 2017 Version 3.1 Page 195 of 247
+
+
+**Class ACO: Composition**
+
+
+Developer action elements:
+
+
+**ACO_DEV.2.1D** The developer shall provide development information for the base
+
+component.
+
+
+Content and presentation elements:
+
+
+**ACO_DEV.2.1C** The development information shall describe the purpose **and** **method** of **use**
+
+**of** each interface of the base component used in the composed TOE.
+
+
+**ACO_DEV.2.2C** **The development information shall provide a high-level description of**
+
+**the behaviour of the base component, which supports the enforcement of**
+**the dependent component SFRs.**
+
+
+**ACO_DEV.2.3C** The development information shall show correspondence between the
+
+interfaces, used in the composed TOE, of the base component and the
+dependent component to support the TSF of the dependent component.
+
+
+Evaluator action elements:
+
+
+**ACO_DEV.2.1E** The evaluator _**shall confirm**_ that the information meets all requirements for
+
+content and presentation of evidence.
+
+
+**ACO_DEV.2.2E** The evaluator _**shall determine**_ that the interface description provided is
+
+consistent with the reliance information provided for the dependent
+component.
+
+
+**ACO_DEV.3** **Detailed evidence of design**
+
+
+Dependencies: ACO_REL.2 Reliance information
+
+
+Objectives
+
+
+509 A description of the interfaces in the base component, on which the
+dependent component relies, is required. This is examined to determine
+whether or not it is consistent with the description of interfaces on which the
+dependent component relies, as provided in the reliance information.
+
+
+510 The interface description of the architecture of the base component is
+provided to enable the evaluator to determine whether or not that interface
+formed part of the TSF of the base component.
+
+
+Developer action elements:
+
+
+**ACO_DEV.3.1D** The developer shall provide development information for the base
+
+component.
+
+
+Content and presentation elements:
+
+
+**ACO_DEV.3.1C** The development information shall describe the purpose and method of use
+
+of each interface of the base component used in the composed TOE.
+
+
+Page 196 of 247 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+
+**ACO_DEV.3.2C** **The development information shall identify the subsystems of the base**
+
+**component that provide interfaces of the base component used in the**
+**composed TOE.**
+
+
+**ACO_DEV.3.3C** The development information shall provide a high-level description of the
+
+behaviour of the base component **subsystems,** which **support** the
+enforcement of the dependent component SFRs.
+
+
+**ACO_DEV.3.4C** **The development information shall provide a mapping from the**
+
+**interfaces to the subsystems of the base component.**
+
+
+**ACO_DEV.3.5C** The development information shall show correspondence between the
+
+interfaces, used in the composed TOE, of the base component and the
+dependent component to support the TSF of the dependent component.
+
+
+Evaluator action elements:
+
+
+**ACO_DEV.3.1E** The evaluator _**shall confirm**_ that the information meets all requirements for
+
+content and presentation of evidence.
+
+
+**ACO_DEV.3.2E** The evaluator _**shall determine**_ that the interface description provided is
+
+consistent with the reliance information provided for the dependent
+component.
+
+
+April 2017 Version 3.1 Page 197 of 247
+
+
+**Class ACO: Composition**
+
+## **18.3 Reliance of dependent component (ACO_REL)**
+
+
+Objectives
+
+
+511 The purpose of this family is to provide evidence that describes the reliance
+that a dependent component has upon the base component. This information
+is useful to persons responsible for integrating the component with other
+evaluated IT components to form the composed TOE, and for providing
+insight into the security properties of the resulting composition.
+
+
+512 This provides a description of the interface between the dependent and base
+components of the composed TOE that may not have been analysed during
+evaluation of the individual components, as the interfaces were not TSFIs of
+the individual component TOEs.
+
+
+Component levelling
+
+
+513 The components in this family are levelled according to the amount of detail
+provided in the description of the reliance by the dependent component upon
+the base component.
+
+
+Application notes
+
+
+514 The Reliance of dependent component (ACO_REL) family considers the
+interactions between the components where the dependent component relies
+upon a service from the base component to support the operation of security
+functionality of the dependent component. The interfaces into these services
+of the base component may not have been considered during evaluation of
+the base component because the service in the base component was not
+considered security-relevant in the component evaluation, either because of
+the inherent purpose of the service (e.g., adjust type font) or because
+associated CC SFRs are not being claimed in the base component's ST (e.g.
+the login interface when no FIA: Identification and authentication SFRs are
+claimed). These interfaces into the base component are often viewed as
+functional interfaces in the evaluation of the base component, and are in
+addition to the security interfaces (TSFI) considered in the functional
+specification.
+
+
+515 In summary, the TSFIs described in the functional specification only include
+the calls made into a TSF by external entities and responses to those calls.
+Calls made by a TSF, which were not explicitly considered during evaluation
+of the components, are described by the reliance information provided to
+satisfy Reliance of dependent component (ACO_REL).
+
+
+Page 198 of 247 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+
+**ACO_REL.1** **Basic reliance information**
+
+
+Dependencies: No dependencies.
+
+
+Developer action elements:
+
+
+**ACO_REL.1.1D** **The developer shall provide reliance information of the dependent**
+
+**component.**
+
+
+Content and presentation elements:
+
+
+**ACO_REL.1.1C** **The reliance information shall describe the functionality of the base**
+
+**component hardware, firmware and/or software that is relied upon by**
+**the dependent component TSF.**
+
+
+**ACO_REL.1.2C** **The reliance information shall describe all interactions through which**
+
+**the dependent component TSF requests services from the base**
+**component.**
+
+
+**ACO_REL.1.3C** **The reliance information shall describe how the dependent TSF protects**
+
+**itself from interference and tampering by the base component.**
+
+
+Evaluator action elements:
+
+
+**ACO_REL.1.1E** **The evaluator** _**shall confirm**_ **that the information provided meets all**
+
+**requirements for content and presentation of evidence.**
+
+
+**ACO_REL.2** **Reliance information**
+
+
+Dependencies: No dependencies.
+
+
+Developer action elements:
+
+
+**ACO_REL.2.1D** The developer shall provide reliance information of the dependent
+
+component.
+
+
+Content and presentation elements:
+
+
+**ACO_REL.2.1C** The reliance information shall describe the functionality of the base
+
+component hardware, firmware and/or software that is relied upon by the
+dependent component TSF.
+
+
+**ACO_REL.2.2C** The reliance information shall describe all interactions through which the
+
+dependent component TSF requests services from the base component.
+
+
+**ACO_REL.2.3C** **The reliance information shall describe each interaction in terms of the**
+
+**interface used and the return values from those interfaces.**
+
+
+**ACO_REL.2.4C** The reliance information shall describe how the dependent TSF protects
+
+itself from interference and tampering by the base component.
+
+
+April 2017 Version 3.1 Page 199 of 247
+
+
+**Class ACO: Composition**
+
+
+Evaluator action elements:
+
+
+**ACO_REL.2.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+Page 200 of 247 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+## **18.4 Composed TOE testing (ACO_CTT)**
+
+
+Objectives
+
+
+516 This family requires that testing of composed TOE and testing of the base
+component, as used in the composed TOE, is performed.
+
+
+Component levelling
+
+
+517 The components in this family are levelled on the basis of increasing rigour
+of interface testing and increasing rigour of the analysis of the sufficiency of
+the tests to demonstrate that the composed TSF operates in accordance with
+the reliance information and the composed TOE SFRs.
+
+
+Application notes
+
+
+518 There are two distinct aspects of testing associated with this family:
+
+
+a) testing of the interfaces between the base component and the
+dependent component, which the dependent component rely upon for
+enforcement of security functionality, to demonstrate their
+compatibility;
+
+
+b) testing of the composed TOE to demonstrate that the TOE behaves in
+accordance with the SFRs for the composed TOE.
+
+
+519 If the test configurations used during evaluation of the dependent component
+included use of the base component as a โplatformโ and the test analysis
+sufficiently demonstrates that the TSF behaves in accordance with the SFRs,
+the developer need perform no further testing of the composed TOE
+functionality. However, if the base component was not used in the testing of
+the dependent component, or the configuration of either component varied,
+then the developer is to perform testing of the composed TOE. This may take
+the form of repeating the dependent component developer testing of the
+dependent component, provided this adequately demonstrates the composed
+TOE TSF behaves in accordance with the SFRs.
+
+
+520 The developer is to provide evidence of testing the base component
+interfaces used in the composition. The operation of base component TSFIs
+would have been tested as part of the ATE: Tests activities during evaluation
+of the base component. Therefore, provided the appropriate interfaces were
+included within the test sample of the base component evaluation and it was
+determined in Composition rationale (ACO_COR) that the base component
+is operating in accordance with the base component evaluated configuration,
+with all security functionality required by the dependent component included
+in the TSF, the evaluator action **ACO_CTT.1.1E** may be met through reuse of
+the base component ATE: Tests verdicts.
+
+
+521 If this is not the case, the base component interfaces used relevant to the
+composition that are affected by any variations to the evaluated configuration
+and any additional security functionally will be tested to ensure they
+
+
+April 2017 Version 3.1 Page 201 of 247
+
+
+**Class ACO: Composition**
+
+
+demonstrate the expected behaviour. The expected behaviour to be tested is
+that described in the reliance information (Reliance of dependent component
+(ACO_REL) evidence).
+
+
+**ACO_CTT.1** **Interface testing**
+
+
+Dependencies: ACO_REL.1 Basic reliance information
+ACO_DEV.1 Functional Description
+
+
+Objectives
+
+
+522 The objective of this component is to ensure that each interface of the base
+component, on which the dependent component relies, is tested.
+
+
+Developer action elements:
+
+
+**ACO_CTT.1.1D** **The developer shall provide composed TOE test documentation.**
+
+
+**ACO_CTT.1.2D** **The** **developer** **shall** **provide** **base** **component** **interface** **test**
+**documentation.**
+
+
+**ACO_CTT.1.3D** **The developer shall provide the composed TOE for testing.**
+
+
+**ACO_CTT.1.4D** **The developer shall provide an equivalent set of resources to those that**
+
+**were used in the base component developer's functional testing of the**
+**base component.**
+
+
+Content and presentation elements:
+
+
+**ACO_CTT.1.1C** **The composed TOE and base component interface test documentation**
+
+**shall consist of test plans, expected test results and actual test results.**
+
+
+**ACO_CTT.1.2C** **The test documentation from the developer execution of the composed**
+
+**TOE tests shall demonstrate that the TSF behaves as specified.**
+
+
+**ACO_CTT.1.3C** **The test documentation from the developer execution of the base**
+
+**component interface tests shall demonstrate that the base component**
+**interface relied upon by the dependent component behaves as specified.**
+
+
+**ACO_CTT.1.4C** **The base component shall be suitable for testing.**
+
+
+Evaluator action elements:
+
+
+**ACO_CTT.1.1E** **The evaluator** _**shall confirm**_ **that the information provided meets all**
+
+**requirements for content and presentation of evidence.**
+
+
+**ACO_CTT.1.2E** **The evaluator** _**shall execute**_ **a sample of test in the test documentation to**
+
+**verify the developer test results.**
+
+
+**ACO_CTT.1.3E** **The evaluator** _**shall test**_ **a subset of the TSF interfaces of the composed**
+
+**TOE to confirm that the composed TSF operates as specified.**
+
+
+Page 202 of 247 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+
+**ACO_CTT.2** **Rigorous interface testing**
+
+
+Dependencies: ACO_REL.2 Reliance information
+ACO_DEV.2 Basic evidence of design
+
+
+Objectives
+
+
+523 The objective of this component is to ensure that each interface of the base
+component, on which the dependent component relies, is tested.
+
+
+Developer action elements:
+
+
+**ACO_CTT.2.1D** The developer shall provide composed TOE test documentation.
+
+
+**ACO_CTT.2.2D** The developer shall provide base component interface test documentation.
+
+
+**ACO_CTT.2.3D** The developer shall provide the composed TOE for testing.
+
+
+**ACO_CTT.2.4D** The developer shall provide an equivalent set of resources to those that were
+
+used in the base component developer's functional testing of the base
+component.
+
+
+Content and presentation elements:
+
+
+**ACO_CTT.2.1C** The composed TOE and base component interface test documentation shall
+
+consist of test plans, expected test results and actual test results.
+
+
+**ACO_CTT.2.2C** The test documentation from the developer execution of the composed TOE
+
+tests shall demonstrate that the TSF behaves as specified **and** **is** **complete.**
+
+
+**ACO_CTT.2.3C** The test documentation from the developer execution of the base component
+
+interface tests shall demonstrate that the base component interface relied
+upon by the dependent component behaves as specified **and** **is** **complete.**
+
+
+**ACO_CTT.2.4C** The base component shall be suitable for testing.
+
+
+Evaluator action elements:
+
+
+**ACO_CTT.2.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+**ACO_CTT.2.2E** The evaluator _**shall execute**_ a sample of test in the test documentation to
+
+verify the developer test results.
+
+
+**ACO_CTT.2.3E** The evaluator _**shall test**_ a subset of the TSF interfaces of the composed TOE
+
+to confirm that the composed TSF operates as specified.
+
+
+April 2017 Version 3.1 Page 203 of 247
+
+
+**Class ACO: Composition**
+
+## **18.5 Composition vulnerability analysis (ACO_VUL)**
+
+
+Objectives
+
+
+524 This family calls for an analysis of vulnerability information available in the
+public domain and of vulnerabilities that may be introduced as a result of the
+composition.
+
+
+Component levelling
+
+
+525 The components in this family are levelled on the basis of increasing scrutiny
+of vulnerability information from the public domain and independent
+vulnerability analysis.
+
+
+Application notes
+
+
+526 The developer will provide details of any residual vulnerabilities reported
+during evaluation of the components. These may be gained from the
+component developers or evaluation reports for the components. These will
+be used as inputs into the evaluator's vulnerability analysis of the composed
+TOE in the operational environment.
+
+
+527 The operational environment of the composed TOE is examined to ensure
+that the assumptions and objectives for the component operational
+environment (specified in each component ST) are satisfied in the composed
+TOE. An initial analysis of the consistency of assumptions and objectives
+between the components and the composed TOE STs will have been
+performed during the conduct of the ASE activities for the composed TOE.
+However, this analysis is revisited with the knowledge acquired during the
+ACO_REL, ACO_DEV and the ACO_COR activities to ensure that, for
+example, assumptions of the dependent component that were addressed by
+the environment in the dependent component ST are not reintroduced as a
+result of composition (i.e. that the base component adequately addresses the
+assumptions of the dependent component ST in the composed TOE).
+
+
+528 A search by the evaluator for issues in each component will identify potential
+vulnerabilities reported in the public domain since completion of the
+evaluation of the components. Any potential vulnerabilities will then be
+subject to testing.
+
+
+529 If the base component used in the composed TOE has been the subject of
+assurance continuity activities since certification, the evaluator will consider
+during the composed TOE vulnerability analysis activities the changes made
+in base component.
+
+
+**ACO_VUL.1** **Composition vulnerability review**
+
+
+Dependencies: ACO_DEV.1 Functional Description
+
+
+Developer action elements:
+
+
+**ACO_VUL.1.1D** **The developer shall provide the composed TOE for testing.**
+
+
+Page 204 of 247 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+
+Content and presentation elements:
+
+
+**ACO_VUL.1.1C** **The composed TOE shall be suitable for testing.**
+
+
+Evaluator action elements:
+
+
+**ACO_VUL.1.1E** **The evaluator** _**shall confirm**_ **that the information provided meets all**
+
+**requirements for content and presentation of evidence.**
+
+
+**ACO_VUL.1.2E** **The evaluator** _**shall perform**_ **an analysis to determine that any residual**
+
+**vulnerabilities identified for the base and dependent components are not**
+**exploitable in the composed TOE in its operational environment.**
+
+
+**ACO_VUL.1.3E** **The evaluator** _**shall perform**_ **a search of public domain sources to**
+
+**identify possible vulnerabilities arising from use of the base and**
+**dependent components in the composed TOE operational environment.**
+
+
+**ACO_VUL.1.4E** **The evaluator** _**shall conduct**_ **penetration testing, based on the identified**
+
+**vulnerabilities, to demonstrate that the composed TOE is resistant to**
+**attacks by an attacker with basic attack potential.**
+
+
+**ACO_VUL.2** **Composition vulnerability analysis**
+
+
+Dependencies: ACO_DEV.2 Basic evidence of design
+
+
+Developer action elements:
+
+
+**ACO_VUL.2.1D** The developer shall provide the composed TOE for testing.
+
+
+Content and presentation elements:
+
+
+**ACO_VUL.2.1C** The composed TOE shall be suitable for testing.
+
+
+Evaluator action elements:
+
+
+**ACO_VUL.2.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+**ACO_VUL.2.2E** The evaluator _**shall perform**_ an analysis to determine that any residual
+
+vulnerabilities identified for the base and dependent components are not
+exploitable in the composed TOE in its operational environment.
+
+
+**ACO_VUL.2.3E** The evaluator _**shall perform**_ a search of public domain sources to identify
+
+possible vulnerabilities arising from use of the base and dependent
+components in the composed TOE operational environment.
+
+
+**ACO_VUL.2.4E** **The evaluator** _**shall perform**_ **an independent vulnerability analysis of the**
+
+**composed TOE, using the guidance documentation, reliance information**
+**and composition rationale to identify potential vulnerabilities in the**
+**composed TOE.**
+
+
+April 2017 Version 3.1 Page 205 of 247
+
+
+**Class ACO: Composition**
+
+
+**ACO_VUL.2.5E** The evaluator _**shall conduct**_ penetration testing, based on the identified
+
+vulnerabilities, to demonstrate that the composed TOE is resistant to attacks
+by an attacker with basic attack potential.
+
+
+**ACO_VUL.3** **Enhanced-Basic Composition vulnerability analysis**
+
+
+Dependencies: ACO_DEV.3 Detailed evidence of design
+
+
+Developer action elements:
+
+
+**ACO_VUL.3.1D** The developer shall provide the composed TOE for testing.
+
+
+Content and presentation elements:
+
+
+**ACO_VUL.3.1C** The composed TOE shall be suitable for testing.
+
+
+Evaluator action elements:
+
+
+**ACO_VUL.3.1E** The evaluator _**shall confirm**_ that the information provided meets all
+
+requirements for content and presentation of evidence.
+
+
+**ACO_VUL.3.2E** The evaluator _**shall perform**_ an analysis to determine that any residual
+
+vulnerabilities identified for the base and dependent components are not
+exploitable in the composed TOE in its operational environment.
+
+
+**ACO_VUL.3.3E** The evaluator _**shall perform**_ a search of public domain sources to identify
+
+possible vulnerabilities arising from use of the base and dependent
+components in the composed TOE operational environment.
+
+
+**ACO_VUL.3.4E** The evaluator _**shall perform**_ an independent vulnerability analysis of the
+
+composed TOE, using the guidance documentation, reliance information and
+composition rationale to identify potential vulnerabilities in the composed
+TOE.
+
+
+**ACO_VUL.3.5E** The evaluator _**shall conduct**_ penetration testing, based on the identified
+
+vulnerabilities, to demonstrate that the composed TOE is resistant to attacks
+by an attacker with **Enhanced-Basic** attack potential.
+
+
+Page 206 of 247 Version 3.1 April 2017
+
+
+**Development (ADV)**
+
+# **A Development (ADV)** **(informative)**
+
+
+530 This annex contains ancillary material to further explain and provide
+additional examples for the topics brought up in families of the ADV:
+Development class.
+
+## **A.1 ADV_ARC: Supplementary material on security** **architectures**
+
+
+531 A security architecture is a set of properties that the TSF exhibits; these
+properties include self-protection, domain separation, and non-bypassability.
+Having these properties provides a basis of confidence that the TSF is
+providing its security services. This annex provides additional material on
+these properties, as well as discussion on contents of a security architecture
+description.
+
+
+532 The remainder of this section first explains these properties, then discusses
+the kinds of information that are needed to describe how the TSF exhibits
+those properties.
+
+
+**A.1.1** **Security architecture properties**
+
+
+533 _Self-protection_ refers to the ability of the TSF to protect itself from
+manipulation from external entities that may result in changes to the TSF.
+Without these properties, the TSF might be disabled from performing its
+security services.
+
+
+534 It is oftentimes the case that a TOE uses services or resources supplied by
+other IT entities in order to perform its functions (e.g. an application that
+relies upon its underlying operating system). In these cases, the TSF does not
+protect itself entirely on its own, because it depends on the other IT entities
+to protect the services it uses.
+
+
+535 _Domain separation_ is a property whereby the TSF creates separate _security_
+_domains_ for each untrusted active entity to operate on its resources, and then
+keeps those domains separated from one another so that no entity can run in
+the domain of any other. For example, an operating system TOE supplies a
+domain (address space, per-process environment variables) for each process
+associated with untrusted entities.
+
+
+536 For some TOEs such domains do not exist because all of the actions of the
+untrusted entities are brokered by the TSF. A packet-filter firewall is an
+example of such a TOE, where there are no untrusted entity domains; there
+are only data structures maintained by the TSF. The existence of domains,
+then, is dependant upon 1) the type of TOE and 2) the SFRs levied on the
+TOE. In the cases where the TOE does provide domains for untrusted entities,
+this family requires that those domains are isolated from one another such
+
+
+April 2017 Version 3.1 Page 207 of 247
+
+
+**Development (ADV)**
+
+
+that untrusted entities in one domain are prevented from tampering (affecting
+without brokering by the TSF) from another untrusted entity's domain.
+
+
+537 _Non-bypassability_ is a property that the security functionality of the TSF (as
+specified by the SFRs) is always invoked and cannot be circumvented when
+appropriate for that specific mechanism. For example, if access control to
+files is specified as a capability of the TSF via an SFR, there must be no
+interfaces through which files can be accessed without invoking the TSF's
+access control mechanism (an interface through which a raw disk access
+takes place might be an example of such an interface).
+
+
+538 As is the case with self-protection, the very nature of some TOEs might
+depend upon their environments to play a role in non-bypassability of the
+TSF. For example, a security application TOE requires that it be invoked by
+the underlying operating system. Similarly, a firewall depends upon the fact
+that there are no direct connections between the internal and external
+networks and that all traffic between them must go through the firewall.
+
+
+**A.1.2** **Security architecture descriptions**
+
+
+539 The security architecture description explains how the properties described
+above are exhibited by the TSF. It describes how domains are defined and
+how the TSF keeps them separate. It describes what prevents untrusted
+processes from getting to the TSF and modifying it. It describes what ensures
+that all resources under the TSF's control are adequately protected and that
+all actions related to the SFRs are mediated by the TSF. It explains any role
+the environment plays in any of these (e.g. presuming it gets correctly
+invoked by its underlying environment, how are its security functions
+invoked?).
+
+
+540 The security architecture description presents the TSF's properties of selfprotection, domain separation, and non-bypassability in terms of the
+decomposition descriptions. The level of this description is commensurate
+with the TSF description required by the ADV_FSP, ADV_TDS and
+ADV_IMP requirements that are being claimed. For example, if ADV_FSP
+is the only TSF description available, it would be difficult to provide any
+meaningful security architecture description because none of the details of
+any internal workings of the TSF would be available.
+
+
+541 However, if the TOE design were also available, even at the most basic level
+(ADV_TDS.1), there would be some information available concerning the
+subsystems that make up the TSF, and there would be a description of how
+they work to implement self-protection, domain separation, and nonbypassability. For example, perhaps all user interaction with the TOE is
+constrained through a process that acts on that user's behalf, adopting all of
+the user's security attributes; the security architecture description would
+describe how such a process comes into being, how the process's behaviour
+is constrained by the TSF (so it cannot corrupt the TSF), how all actions of
+that process are mediated by the TSF (thereby explaining why the TSF
+cannot be bypassed), etc.
+
+
+Page 208 of 247 Version 3.1 April 2017
+
+
+**Development (ADV)**
+
+
+542 If the available TOE design is more detailed (e.g. at the modular level), or
+the implementation representation is also available, then the security
+architecture description would be correspondingly more detailed, explaining
+how the user's process communicate with the TSF processes, how different
+requests are processed by the TSF, what parameters are passed, what
+programmatic protections (buffer overflow prevention, parameter bounds
+checking, time of check/time of use checking, etc.) are in place. Similarly, a
+TOE whose ST claimed the ADV_IMP component would go into
+implementation-specific detail.
+
+
+543 The explanations provided in the security architecture description are
+expected to be of sufficient detail that one would be able to test their
+accuracy. That is, simple assertions (e.g. "The TSF keeps domains separateโ)
+provide no useful information to convince the reader that the TSF does
+indeed create and separate domains.
+
+
+**A.1.2.1** Domain Separation
+
+
+544 In cases where the TOE exhibits domain separation entirely on its own, there
+would be a straightforward description of how this is attained. The security
+architecture description would explain the different kinds of domains that are
+defined by the TSF, how they are defined (i.e. what resources are allocated to
+each domain), how no resources are left unprotected, and how the domains
+are kept separated so that active entities in one domain cannot tamper with
+resources in another domain.
+
+
+545 For cases where the TOE depends upon other IT entities to play a role in
+domain separation, that sharing of roles must be made clear. For example, a
+TOE that is solely application software relies upon the underlying operating
+system to correctly instantiate the domains that the TOE defines; if the TOE
+defines separate processing space, memory space, etc, for each domain, it
+depends upon the underlying operating system to operate correctly and
+benignly (e.g. allow the process to execute only in the execution space that is
+requested by the TOE software).
+
+
+546 For example, mechanisms that implement domain separation (e.g., memory
+management, protected processing modes provided by the hardware, etc.)
+would be identified and described. Or, the TSF might implement software
+protection constructs or coding conventions that contribute to implementing
+separation of software domains, perhaps by delineating user address space
+from system address space.
+
+
+547 The vulnerability analysis and testing (see AVA_VAN) activities will likely
+include attempts to defeat the described TSF domain separation through the
+use of monitoring or direct attack the TSF.
+
+
+**A.1.2.2** TSF Self-protection
+
+
+548 In cases where the TOE exhibits self-protection entirely on its own, there
+would be a straightforward description of how this self-protection is attained.
+
+
+April 2017 Version 3.1 Page 209 of 247
+
+
+**Development (ADV)**
+
+
+Mechanisms that provide domain separation to define a TSF domain that is
+protected from other (user) domains would be identified and described.
+
+
+549 For cases where the TOE depends upon other IT entities to play a role in
+protecting itself, that sharing of roles must be made clear. For example, a
+TOE that is solely application software relies upon the underlying operating
+system to operate correctly and benignly; the application cannot protect itself
+against a malicious operating system that subverts it (for example, by
+overwriting its executable code or TSF data).
+
+
+550 The security architecture description also covers how user input is handled
+by the TSF in such a way that the TSF does not subject itself to being
+corrupted by that user input. For example, the TSF might implement the
+notion of privilege and protect itself by using privileged-mode routines to
+handle user data. The TSF might make use of processor-based separation
+mechanisms (e.g. privilege levels or rings) to separate TSF code and data
+from user code and data. The TSF might implement software protection
+constructs or coding conventions that contribute to implementing separation
+of software, perhaps by delineating user address space from system address
+space.
+
+
+551 For TOEs that start up in a low-function mode (for example, a single-user
+mode accessible only to installers or administrators) and then transition to the
+evaluated secure configuration (a mode whereby untrusted users are able to
+login and use the services and resources of the TOE), the security
+architecture description also includes an explanation of how the TSF is
+protected against this initialisation code that does not run in the evaluated
+configuration. For such TOEs, the security architecture description would
+explain what prevents those services that should be available only during
+initialisation (e.g. direct access to resources) from being accessible in the
+evaluated configuration. It would also explain what prevents initialisation
+code from running while the TOE is in the evaluated configuration.
+
+
+552 There must also be an explanation of how the trusted initialisation code will
+maintain the integrity of the TSF (and of its initialisation process) such that
+the initialisation process is able to detect any modification that would result
+in the TSF being spoofed into believe it was in an initial secure state.
+
+
+553 The vulnerability analysis and testing (see AVA_VAN) activities will likely
+include attempts to defeat the described TSF self protection through the use
+of tampering, direct attack, or monitoring of the TSF.
+
+
+**A.1.2.3** TSF Non-Bypassability
+
+
+554 The property of non-bypassability is concerned with interfaces that permit
+the bypass of the enforcement mechanisms. In most cases this is a
+consequence of the implementation, where if a programmer is writing an
+interface that accesses or manipulates an object, it is that programmer's
+responsibility to use interfaces that are part of the SFR enforcement
+mechanism for the object and not to try to circumvent those interfaces. For
+
+
+Page 210 of 247 Version 3.1 April 2017
+
+
+**Development (ADV)**
+
+
+the description pertaining to non-bypassability, then, there are two broad
+areas that have to be covered.
+
+
+555 The first consists of those interfaces to the SFR-enforcement. The property
+for these interfaces is that they contain no operations or modes that allow
+them to be used to bypass the TSF. It is likely that the evidence for
+ADV_FSP and ADV_TDS can be used in large part to make this
+determination. Because non-bypassability is the concern, if only certain
+operations available through these TSFIs are documented (because they are
+SFR-enforcing) and others are not, the developer should consider whether
+additional information (to that presented in ADV_FSP and ADV_TDS) is
+necessary to make a determination that the SFR-supporting and SFR-noninterfering operations of the TSFI do not afford an untrusted entity the ability
+to bypass the policy being enforced. If such information is necessary, it is
+included in the security architecture description.
+
+
+556 The second area of non-bypassability is concerned with those interfaces
+whose interactions are not associated with SFR-enforcement. Depending on
+the ADV_FSP and ADV_TDS components claimed, some information about
+these interfaces may or may not exist in the functional specification and TOE
+design documentation. The information presented for such interfaces (or
+groups of interfaces) should be sufficient so that a reader can make a
+determination (at the level of detail commensurate with the rest of the
+evidence supplied in the ADV: Development class) that the enforcement
+mechanisms cannot be bypassed.
+
+
+557 The property that the security functionality cannot be bypassed applies to all
+security functionality equally. That is, the design description should cover
+objects that are protected under the SFRs (e.g. FDP_* components) and
+functionality (e.g., audit) that is provided by the TSF. The description should
+also identify the interfaces that are associated with security functionality; this
+might make use of the information in the functional specification. This
+description should also describe any design constructs, such as object
+managers, and their method of use. For instance, if routines are to use a
+standard macro to produce an audit record, this convention is a part of the
+design that contributes to the non-bypassability of the audit mechanism. It is
+important to note that _non-bypassability_ in this context is not an attempt to
+answer the question โcould a part of the TSF implementation, if malicious,
+bypass the security functionalityโ, but rather to document how the
+implementation does not bypass the security functionality.
+
+
+558 The vulnerability analysis and testing (see AVA_VAN) activities will likely
+include attempts to defeat the described non-bypassability by circumventing
+the TSF.
+
+## **A.2 ADV_FSP: Supplementary material on TSFIs**
+
+
+559 The purpose in specifying the TSFIs is to provide the necessary information
+to conduct testing; without knowing the possible means interact with the TSF,
+one cannot adequately test the behaviour of the TSF.
+
+
+April 2017 Version 3.1 Page 211 of 247
+
+
+**Development (ADV)**
+
+
+560 There are two parts to specifying the TSFIs: identifying them and describing
+them. Because of the diversity of possible TOEs, and of different TSFs
+therein, there is no standard set of interfaces that constitute โTSFIsโ. This
+annex provides guidance on the factors that determine which interfaces are
+TSFIs.
+
+
+**A.2.1** **Determining the TSFI**
+
+
+561 In order to identify the interfaces to the TSF, the parts of the TOE that make
+up the TSF must first be identified. This identification is actually a part of
+the TOE design (ADV_TDS) analysis, but is also performed implicitly
+(through identification and description of the TSFI) by the developer in cases
+where TOE design (ADV_TDS) is not included in the assurance package. In
+this analysis, a portion of the TOE must be considered to be in the TSF if it
+contributes to the satisfaction of an SFR in the ST (in whole or in part). This
+includes, for example, everything in the TOE that contributes to TSF runtime initialisation, such as software that runs prior to the TSF being able to
+protect itself because enforcement of the SFRs has not yet begun (e.g., while
+booting up). Also included in the TSF are all parts of the TOE that contribute
+to the architectural principles of TSF self-protection, domain separation, and
+non-bypassability (see Security Architecture (ADV_ARC)).
+
+
+562 Once the TSF has been defined, the TSFI are identified. The TSFI consists of
+all means by which external entities (or subjects in the TOE but outside of
+the TSF) supply data to the TSF, receive data from the TSF and invoke
+services from the TSF. These service invocations and responses are the
+means of crossing the TSF boundary. While many of these are readily
+apparent, others might not be as obvious. The question that should be asked
+when determining the TSFIs is: โHow can a potential attacker interact with
+the TSF in an attempt to subvert the SFRs?โ The following discussions
+illustrate the application of the TSFI definition in different contexts.
+
+
+**A.2.1.1** Electrical interfaces
+
+
+563 In TOEs such as smart cards, where the adversary has not only logical access
+to the TOE, but also complete physical access to the TOE, the TSF boundary
+is the physical boundary. Therefore, the exposed electrical interfaces are
+considered TSFI because their manipulation could affect the behaviour of the
+TSF. As such, all these interfaces (electrical contacts) need to be described:
+various voltages that might be applied, etc.
+
+
+**A.2.1.2** Network protocol stack
+
+
+564 The TSFIs of a TOE that performs protocol processing would be those
+protocol layers to which a potential attacker has direct access. This need not
+be the entire protocol stack, but it might be.
+
+
+565 For example, if the TOE were some sort of a network appliance that allowed
+potential attackers to affect every level of the protocol stack (i.e. to send
+arbitrary signals, arbitrary voltages, arbitrary packets, arbitrary datagrams,
+etc.), then the TSF boundary exists at each layer of the stack. Therefore, the
+
+
+Page 212 of 247 Version 3.1 April 2017
+
+
+**Development (ADV)**
+
+
+functional specification would have to address every protocol at every layer
+of the stack.
+
+
+566 If, however, the TOE were a firewall that protects an internal network from
+the Internet, a potential attacker would have no means of directly
+manipulating the voltages that enter the TOE; any extreme voltages would
+simply not be passed though the Internet. That is, the attacker would have
+access only to those protocols at the Internet layer or above. The TSF
+boundary exists at each layer of the stack. Therefore, the functional
+specification would have to address only those protocols at or above the
+Internet layer: it would describe each of the different communication layers
+at which the firewall is exposed in terms of what constitutes well-formed
+input for what might appear on the line, and the result of both well-formed
+and malformed inputs. For example, the description of the Internet protocol
+layer would describe what constitutes a well-formed IP packet and what
+happens when both correctly-formed and malformed packets are received.
+Likewise, the description of the TCP layer would describe a successful TCP
+connection and what happens both when successful connections are
+established and when connections cannot be established or are inadvertently
+dropped. Presuming the firewall's purpose is to filter application-level
+commands (like FTP or telnet), the description of the application layer would
+describe the application-level commands that are recognised and filtered by
+the firewall, as well as the results of encountering unknown commands.
+
+
+567 The descriptions of these layers would likely reference published
+communication standards (telnet, FTP, TCP, etc.) that are used, noting which
+user-defined options are chosen.
+
+
+**A.2.1.3** Wrappers
+
+
+**Figure 20 - Wrappers**
+
+
+April 2017 Version 3.1 Page 213 of 247
+
+
+**Development (ADV)**
+
+
+568 โWrappersโ translate complex series of interactions into simplified common
+services, such as when Operating Systems create APIs for use by
+applications (as shown in Figure 20). Whether the TSFIs would be the
+system calls or the APIs depends upon what is available to the application: if
+the application can use the system calls directly, then the system calls are the
+TSFIs. If, however, there were something that prohibits their direct use and
+requires all communication through the APIs, then the APIs would be the
+TSFIs.
+
+
+569 A Graphical User interface is similar: it translates between machineunderstandable commands and user-friendly graphics. Similarly, the TSFIs
+would be the commands if users have access to them, or the graphics (pulldown menus, check-boxes, text fields) if the users are constrained to using
+them.
+
+
+570 It is worth noting that, in both of these examples, if the user is prohibited
+from using the more primitive interfaces (i.e. the system calls or the
+commands), the description of this restriction and of its enforcement would
+be included in the Security Architecture Description (see A.1). Also, the
+wrapper would be part of the TSF.
+
+
+**A.2.1.4** Inaccessible interfaces
+
+
+571 For a given TOE, not all of the interfaces may be _accessible_ . That is, the
+security objectives for the operational environment (in the Security Target)
+may prevent access to these interfaces or limit access in such a way that they
+are practically inaccessible. Such interfaces would not be considered TSFIs.
+Some examples:
+
+
+a) If the security objectives for the operational environment for the
+stand-alone firewall state that โthe firewall will be operational in a
+server room environment to which only trusted and trained personnel
+will have access, and which will be equipped with an interruptible
+power supply (against power failure)โ, physical and power interfaces
+will not be accessible, since trusted and trained personnel will not
+attempt to dismantle the firewall and/or disable its power supply.
+
+
+b) If the security objectives for the operational environment for the
+software firewall (application) state that โthe OS and the hardware
+will provide a security domain for the application free from
+tampering by other programsโ, the interfaces through which the
+firewall can be accessed by other applications on the OS (e.g.
+deleting or modifying the firewall executable, direct reading or
+writing to the memory space of the firewall) will not be accessible,
+since the OS/hardware part of the operational environment makes this
+interface inaccessible.
+
+
+c) If the security objectives for the operational environment for the
+software firewall additionally state that the OS and hardware will
+faithfully execute the commands of the TOE, and will not tamper
+with the TOE in any manner, interfaces through which the firewall
+
+
+Page 214 of 247 Version 3.1 April 2017
+
+
+**Development (ADV)**
+
+
+obtains primitive functionality from the OS and hardware (executing
+machine code instructions, OS APIs, such as creating, reading,
+writing or deleting files, graphical APIs etc.) will not be accessible,
+since the OS/hardware are the only entities that can access that
+interface, and they are completely trusted.
+
+
+For all of these examples, these inaccessible interfaces would not be TSFIs.
+
+
+**A.2.2** **Example: A complex DBMS**
+
+
+572 Figure 21 illustrates a complex TOE: a database management system that
+relies on hardware and software that is outside the TOE boundary (referred
+to as the _IT environment_ in the rest of this discussion). To simplify this
+example, the TOE is identical to the TSF. The shaded boxes represent the
+TSF, while the unshaded boxes represent IT entities in the environment. The
+TSF comprises the database engine and management GUIs (represented by
+the box labelled _DB_ ) and a kernel module that runs as part of the OS that
+performs some security function (represented by the box labelled _PLG_ ). The
+TSF kernel module has entry points defined by the OS specification that the
+OS will call to invoke some function (this could be a device driver, or an
+authentication module, etc.). The key is that this pluggable kernel module is
+providing security services specified by functional requirements in the ST.
+
+
+**Figure 21 - Interfaces in a DBMS system**
+
+
+573 The IT environment consists of the operating system itself (represented by
+the box labelled _OS_ ), as well as an external server (labelled _SRV_ ). This
+external server, like the OS, provides a service that the TSF depends on, and
+thus needs to be in the IT environment. Interfaces in the figure are labelled
+_Ax_ for TSFI, and _Bx_ for other interfaces that would be documented in ACO:
+Composition. Each of these groups of interfaces is now discussed.
+
+
+574 Interface group A1 represents the most obvious set of TSFI. These are
+interfaces used by users to directly access the database and its security
+functionality and resources.
+
+
+April 2017 Version 3.1 Page 215 of 247
+
+
+**Development (ADV)**
+
+
+575 Interface group A2 represent the TSFI that the OS invokes to obtain the
+functionality provided by the pluggable module. These are contrasted with
+interface group B3, which represent calls that the pluggable module makes to
+obtain services from the IT environment.
+
+
+576 Interface group A3 represent TSFI that pass through the IT environment. In
+this case, the DBMS communicates over the network using a proprietary
+application-level protocol. While the IT environment is responsible for
+providing various supporting protocols (e.g., Ethernet, IP, TCP), the
+application layer protocol that is used to obtain services from the DBMS is a
+TSFI and must be documented as such. The dotted line indicates return
+values/services from the TSF over the network connection.
+
+
+577 The interfaces labelled _Bx_ represent interfaces to functionality in the IT
+Environment. These interfaces are not TSFI and need only be discussed and
+analysed when the TOE is being used in a composite evaluation as part of the
+activities associated with the ACO class.
+
+
+**A.2.3** **Example Functional Specification**
+
+
+578 The Example firewall is used between an internal network and an external
+network. It verifies the source address of data received (to ensure that
+external data is not attempting to masquerade as originating from the internal
+data); if it detects any such attempts, it saves the offending attempt to the
+audit log. The administrator connects to the firewall by establishing a telnet
+connection to the firewall from the internal network. Administrator actions
+consist of authenticating, changing passwords, reviewing the audit log, and
+setting or changing the addresses of the internal and external networks.
+
+
+579 The Example firewall presents the following interfaces to the internal
+network:
+
+
+a) IP datagrams
+
+
+b) Administrator Commands
+
+
+and the following interfaces to the external network:
+
+
+a) IP datagrams
+
+
+580 **Interfaces Descriptions: IP Datagrams**
+
+
+581 The datagrams are in the format specified by RFC 791.
+
+
+๏ญ Purpose - to transmit blocks of data (โdatagramsโ) from source hosts
+to destination hosts identified by fixed length addresses; also
+provides for fragmentation and reassembly of long datagrams, if
+necessary, for transmission through small-packet networks.
+
+
+๏ญ Method of Use - they arrive from the lower-level (e.g. data link)
+protocol.
+
+
+Page 216 of 247 Version 3.1 April 2017
+
+
+**Development (ADV)**
+
+
+๏ญ Parameters - the following fields of the IP datagram header: source
+address, destination address, don't-fragment flag.
+
+
+๏ญ Parameter description - [As defined by RFC 791, section 3.1
+(โInternet Header Formatโ)]
+
+
+๏ญ Actions - Transmits datagrams that are not masquerading; fragments
+large datagrams if necessary; reassembles fragments into datagrams.
+
+
+๏ญ Error messages - (none). No reliability guaranteed (reliability to be
+provided by upper-level protocols) Undeliverable datagrams (e.g.
+must be fragmented for transmission, but don't-fragment flag is set)
+dropped.
+
+
+582 **Interfaces Descriptions: Administrator Commands**
+
+
+583 The administrator commands provide a means for the administrator to
+interact with the firewall. These commands and responses ride atop a telnet
+(RFC 854) connection established from any host on the internal network.
+Available commands are:
+
+
+๏ญ **Passwd**
+
+
+๏ญ Purpose - sets administrator password
+
+
+๏ญ Method of Use - **Passwd** < _password_
+
+๏ญ Parameters - password
+
+
+๏ญ Parameter description - value of new password
+
+
+๏ญ Actions - changes password to new value supplied. There are
+no restrictions.
+
+
+๏ญ Error messages - none.
+
+
+๏ญ **Readaudit**
+
+
+๏ญ Purpose - presents the audit log to the administrator
+
+
+๏ญ Method of Use - **Readaudit**
+
+
+๏ญ Parameters - none
+
+
+๏ญ Parameter description - none
+
+
+๏ญ Actions - provides the text of the audit log
+
+
+๏ญ Error messages - none.
+
+
+๏ญ **Setintaddr**
+
+
+April 2017 Version 3.1 Page 217 of 247
+
+
+**Development (ADV)**
+
+
+๏ญ Purpose - sets the address of the internal address.
+
+
+๏ญ Method of Use - **Setintaddr** < _address_
+
+๏ญ Parameters - address
+
+
+๏ญ Parameter description - first three fields of an IP address (as
+defined in RFC 791). For example: 123.123.123.
+
+
+๏ญ Actions - changes the internal value of the variable defining
+the internal network, the value of which is used to judge
+attempted masquerades.
+
+
+๏ญ Error messages - โaddress in useโ: indicates the identified
+internal network is the same as the external network.
+
+
+๏ญ **Setextaddr**
+
+
+๏ญ Purpose - sets the address of the external address
+
+
+๏ญ Method of Use - **Setextaddr** < _address_
+
+๏ญ Parameters - address
+
+
+๏ญ Parameter description - first three fields of an IP address (as
+defined in RFC 791). For example: 123.123.123.
+
+
+๏ญ Actions - changes the internal value of the variable defining
+the external network.
+
+
+๏ญ Error messages - โaddress in useโ: indicates the identified
+external network is the same as the internal network.
+
+## **A.3 ADV_INT: Supplementary material on TSF internals**
+
+
+584 The wide variety of TOEs makes it impossible to codify anything more
+specific than โwell-structuredโ or โminimum complexityโ. Judgements on
+structure and complexity are expected to be derived from the specific
+technologies used in the TOE. For example, software is likely to be
+considered well-structured if it exhibits the characteristics cited in the
+software engineering disciplines.
+
+
+585 This annex provides supplementary material on assessing the structure and
+complexity of procedure-based software portions of the TSF. This material is
+based on information readily available in software engineering literature. For
+other kinds of internals (e.g. hardware, non-procedural software such as
+object-oriented code, etc.), corresponding literature on good practises should
+be consulted.
+
+
+Page 218 of 247 Version 3.1 April 2017
+
+
+**Development (ADV)**
+
+
+**A.3.1** **Structure of procedural software**
+
+
+586 The structure of procedural software is traditionally assessed according to its
+_modularity_ . Software written with a modular design aids in achieving
+understandability by clarifying what dependencies a module has on other
+modules ( _coupling_ ) and by including in a module only tasks that are strongly
+related to each other ( _cohesion_ ). The use of modular design reduces the
+interdependence between elements of the TSF and thus reduces the risk that
+a change or error in one module will have effects throughout the TOE. Its use
+enhances clarity of design and provides for increased assurance that
+unexpected effects do not occur. Additional desirable properties of modular
+decomposition are a reduction in the amount of redundant or unneeded code.
+
+
+587 Minimising the amount of functionality in the TSF allows the evaluator as
+well as the developer to focus only on that functionality which is necessary
+for SFR enforcement, contributing further to understandability and further
+lowering the likelihood of design or implementation errors.
+
+
+588 The incorporation of modular decomposition, layering and minimisation into
+the design and implementation process must be accompanied by sound
+software engineering considerations. A practical, useful software system will
+usually entail some undesirable coupling among modules, some modules that
+include loosely-related functions, and some subtlety or complexity in a
+module's design. These deviations from the ideals of modular decomposition
+are often deemed necessary to achieve some goal or constraint, be it related
+to performance, compatibility, future planned functionality, or some other
+factors, and may be acceptable, based on the developer's justification for
+them. In applying the requirements of this class, due consideration must be
+given to sound software engineering principles; however, the overall
+objective of achieving understandability must be achieved.
+
+
+**A.3.1.1** Cohesion
+
+
+589 Cohesion is the manner and degree to which the tasks performed by a single
+software module are related to one another; types of cohesion include
+coincidental, communicational, functional, logical, sequential, and temporal.
+These types of cohesion are characterised below, listed in the order of
+decreasing desirability.
+
+
+a) _functional_ cohesion - a module with functional cohesion performs
+activities related to a single purpose. A functionally cohesive module
+transforms a single type of input into a single type of output, such as
+a stack manager or a queue manager.
+
+
+b) _sequential_ cohesion - a module with sequential cohesion contains
+functions each of whose output is input for the following function in
+the module. An example of a sequentially cohesive module is one
+that contains the functions to write audit records and to maintain a
+running count of the accumulated number of audit violations of a
+specified type.
+
+
+April 2017 Version 3.1 Page 219 of 247
+
+
+**Development (ADV)**
+
+
+c) _communicational_ cohesion - a module with communicational
+cohesion contains functions that produce output for, or use output
+from, other functions within the module. An example of a
+communicationally cohesive module is an access check module that
+includes mandatory, discretionary, and capability checks.
+
+
+d) _temporal_ cohesion - a module with temporal cohesion contains
+functions that need to be executed at about the same time. Examples
+of temporally cohesive modules include initialisation, recovery, and
+shutdown modules.
+
+
+e) _logical_ (or _procedural_ ) cohesion - a module with logical cohesion
+performs similar activities on different data structures. A module
+exhibits logical cohesion if its functions perform related, but different,
+operations on different inputs.
+
+
+f) _coincidental_ cohesion - a module with coincidental cohesion
+performs unrelated, or loosely related, activities.
+
+
+**A.3.1.2** Coupling
+
+
+590 Coupling is the manner and degree of interdependence between software
+modules; types of coupling include call, common and content coupling.
+These types of coupling are characterised below, listed in the order of
+decreasing desirability:
+
+
+a) call: two modules are call coupled if they communicate strictly
+through the use of their documented function calls; examples of call
+coupling are data, stamp, and control, which are defined below.
+
+
+1. _data_ : two modules are data coupled if they communicate
+strictly through the use of call parameters that represent single
+data items.
+
+
+2. _stamp_ : two modules are stamp coupled if they communicate
+through the use of call parameters that comprise multiple
+fields or that have meaningful internal structures.
+
+
+3. _control_ : two modules are control coupled if one passes
+information that is intended to influence the internal logic of
+the other.
+
+
+b) _common_ : two modules are common coupled if they share a common
+data area or a common system resource. Global variables indicate that
+modules using those global variables are common coupled. Common
+coupling through global variables is generally allowed, but only to a
+limited degree. For example, variables that are placed into a global
+area, but are used by only a single module, are inappropriately placed,
+and should be removed. Other factors that need to be considered in
+assessing the suitability of global variables are:
+
+
+Page 220 of 247 Version 3.1 April 2017
+
+
+**Development (ADV)**
+
+
+1. The number of modules that modify a global variable: In
+general, only a single module should be allocated the
+responsibility for controlling the contents of a global variable,
+but there may be situations in which a second module may
+share that responsibility; in such a case, sufficient justification
+must be provided. It is unacceptable for this responsibility to
+be shared by more than two modules. (In making this
+assessment, care should be given to determining the module
+actually responsible for the contents of the variable; for
+example, if a single routine is used to modify the variable, but
+that routine simply performs the modification requested by its
+caller, it is the calling module that is responsible, and there
+may be more than one such module). Further, as part of the
+complexity determination, if two modules are responsible for
+the contents of a global variable, there should be clear
+indications of how the modifications are coordinated between
+them.
+
+
+2. The number of modules that reference a global variable:
+Although there is generally no limit on the number of
+modules that reference a global variable, cases in which many
+modules make such a reference should be examined for
+validity and necessity.
+
+
+c) _content_ : two modules are content coupled if one can make direct
+reference to the internals of the other (e.g. modifying code of, or
+referencing labels internal to, the other module). The result is that
+some or all of the content of one module are effectively included in
+the other. Content coupling can be thought of as using unadvertised
+module interfaces; this is in contrast to call coupling, which uses only
+advertised module interfaces.
+
+
+**A.3.2** **Complexity of procedural software**
+
+
+591 Complexity is the measure of the decision points and logical paths of
+execution that code takes. Software engineering literature cites complexity as
+a negative characteristic of software because it impedes understanding of the
+logic and flow of the code. Another impediment to the understanding of code
+is the presence of code that is unnecessary, in that it is unused or redundant.
+
+
+592 The use of layering to separate levels of abstraction and minimise circular
+dependencies further enables a better understanding of the TSF, providing
+more assurance that the TOE security functional requirements are accurately
+and completely instantiated in the implementation.
+
+
+593 Reducing complexity also includes reducing or eliminating mutual
+dependencies, which pertains both to modules in a single layer and to those
+in separate layers. Modules that are mutually dependent may rely on one
+another to formulate a single result, which could result in a deadlock
+condition, or worse yet, a race condition (e.g., time of check vs. time of use
+
+
+April 2017 Version 3.1 Page 221 of 247
+
+
+**Development (ADV)**
+
+
+concern), where the ultimate conclusion could be indeterminate and subject
+to the computing environment at the given instant in time.
+
+
+594 Design complexity minimisation is a key characteristic of a reference
+validation mechanism, the purpose of which is to arrive at a TSF that is
+easily understood so that it can be completely analysed. (There are other
+important characteristics of a reference validation mechanism, such as TSF
+self-protection and non-bypassability; these other characteristics are covered
+by requirements in the ADV_ARC family.)
+
+## **A.4 ADV_TDS: Subsystems and Modules**
+
+
+595 This Section provides additional guidance on the TDS family, and its use of
+the terms โsubsystemโ and โmoduleโ. This is followed by a discussion of
+how, as more-detailed becomes available, the requirement for the lessdetailed is reduced.
+
+
+**A.4.1** **Subsystems**
+
+
+596 Figure 22 shows that, depending on the complexity of the TSF, the design
+may be described in terms of subsystems _and_ modules (where subsystems
+are at a higher level of abstraction than modules); or it may just be described
+in terms of one level of abstraction (e.g., _subsystems_ at lower assurance
+levels, _modules_ at higher levels). In cases where a lower level of abstraction
+(modules) is presented, requirements levied on higher-level abstractions
+(subsystems) are essentially met by default. This concept is further
+elaborated in the discussion on subsystems and modules below.
+
+
+**Figure 22 - Subsystems and Modules**
+
+
+597 The developer is expected to describe the design of the TOE in terms of
+_subsystems_ . The term โsubsystemโ was chosen to be specifically vague so
+that it could refer to units appropriate to the TOE (e.g., subsystems, modules).
+subsystems can even be uneven in scope, as long as the requirements for
+description of subsystems are met.
+
+
+Page 222 of 247 Version 3.1 April 2017
+
+
+**Development (ADV)**
+
+
+598 The first use of subsystems is to distinguish the TSF boundary; that is, the
+portions of the TOE that comprise the TSF. In general, a subsystem is part of
+the TSF if it has the capability (whether by design or implementation) to
+affect the correct operation of any of the SFRs. For example, for software
+that depends on different hardware execution modes to provide domain
+separation (see A.1) where SFR-enforcing code is executed in one domain,
+then all subsystems that execute in that domain would be considered part of
+the TSF. Likewise, if a server outside that domain implemented an SFR (e.g.
+enforced an access control policy over objects it managed), then it too would
+be considered part of the TSF.
+
+
+599 The second use of subsystems is to provide a structure for describing the
+TSF at a level of description that, while describing how the TSF works, does
+not necessarily contain low-level implementation detail found in module
+descriptions (discussed later). subsystems are described at either a high level
+(lacking an abundance of implementation detail) or a detailed level
+(providing more insight into the implementation). The level of description
+provided for a subsystem is determined by the degree to which that
+subsystem is responsible for implementing an SFR.
+
+
+600 An _SFR-enforcing_ subsystem is a subsystem that provides mechanisms for
+enforcing an element of any SFR, or directly supports a subsystem that is
+responsible for enforcing an SFR. If a subsystem provides (implements) an
+SFR-enforcing TSFI, then the subsystem is SFR-enforcing.
+
+
+601 Subsystems can also be identified as _SFR-supporting_ and _SFR-non-_
+_interfering_ . An SFR-supporting subsystem is one that is depended on by an
+SFR-enforcing subsystem in order to implement an SFR, but does not play as
+direct a role as an SFR-enforcing subsystem. An SFR-non-interfering
+subsystem is one that is not depended upon, in either a supporting or
+enforcing role, to implement an SFR.
+
+
+**A.4.2** **Modules**
+
+
+602 A module is generally a relatively small architectural unit that can be
+characterised in terms of the properties discussed in TSF internals
+(ADV_INT). When both ADV_TDS.3 Basic modular design (or above)
+requirements and TSF internals (ADV_INT) requirements are present in a PP
+or ST, a โmoduleโ in terms of the TOE design (ADV_TDS) requirements
+refers to the same entity as a โmoduleโ for the TSF internals (ADV_INT)
+requirements. Unlike subsystems, modules describe the implementation in a
+level of detail that can serve as a guide to reviewing the implementation
+representation.
+
+
+603 It is important to note that, depending on the TOE, modules and subsystems
+may refer to the same abstraction. For ADV_TDS.1 Basic design and
+ADV_TDS.2 Architectural design (which do not require description at the
+module level) the subsystem description provides the lowest level detail
+available about the TSF. For ADV_TDS.3 Basic modular design (which
+require module descriptions) these descriptions provide the lowest level of
+detail, while the subsystem descriptions (if they exist as separate entities)
+
+
+April 2017 Version 3.1 Page 223 of 247
+
+
+**Development (ADV)**
+
+
+merely serve to put to the module descriptions in context. That is, it is not
+necessary to provide detailed subsystem descriptions if module descriptions
+exist. In TOEs that are sufficiently simple, a separate โsubsystem
+descriptionโ is not necessary; the requirements can be met through
+documentation provided by modules. For complex TOEs, the purpose of the
+subsystem description (with respect to the TSF) is to provide the reader
+context so they can focus their analysis appropriately. This difference is
+illustrated in Figure 22.
+
+
+604 An SFR-enforcing module is a module that completely or partially
+implements a security functional requirement (SFR) in the ST. Such modules
+may implement an SFR-enforcing TSFI, but some functionality expressed in
+an SFR (for example, audit and object re-use functionality) may not be
+directly tied to a single TSFI. As was the case with subsystems, SFRsupporting modules are those modules that are depended upon by an SFRenforcing module, but are not responsible for directly implementing an SFR.
+SFR-non-interfering modules are those modules that do not deal, directly or
+indirectly, with the enforcement of SFRs.
+
+
+605 It is important to note that the determination of what โdirectly implementsโ
+means is somewhat subjective. In the narrowest sense of the term, it could be
+interpreted to mean the one or two lines of code that actually perform a
+comparison, zeroing operation, etc. that implements a requirement. A
+broader interpretation might be that it includes the module that is invoked in
+response to a SFR-enforcing TSFI, and all modules that may be invoked in
+turn by that module (and so on until the completion of the call). Neither of
+these interpretations is particularly satisfying, since the narrowness of the
+first interpretation may lead to important modules being incorrectly
+categorised as SFR supporting, while the second leads to modules that are
+actually not SFR-enforcing being classified as such.
+
+
+606 A description of a module should be such that one could create an
+implementation of the module from the description, and the resulting
+implementation would be 1) identical to the actual TSF implementation in
+terms of the interfaces presented, 2) identical in the use of interfaces that are
+mentioned in the design, and 3) functionally equivalent to the description of
+the purpose of the TSF module. For instance, RFC 793 provides a high-level
+description of the TCP protocol. It is necessarily implementation
+independent. While it provides a wealth of detail, it is _**not**_ a suitable design
+description because it is not specific to an implementation. An actual
+implementation can add to the protocol specified in the RFC, and
+implementation choices (for example, the use of global data vs. local data in
+various parts of the implementation) may have an impact on the analysis that
+is performed. The design description of the TCP module would list the
+interfaces presented by the implementation (rather than just those defined in
+RFC 793), as well as an algorithm description of the processing associated
+with the modules implementing TCP (assuming they were part of the TSF).
+
+
+607 In the design, modules are described in detail in terms of the function they
+provide (the purpose); the interfaces they present (when required by the
+criteria); the return values from such interfaces; the interfaces (presented by
+
+
+Page 224 of 247 Version 3.1 April 2017
+
+
+**Development (ADV)**
+
+
+other modules) they use (provided those interfaces are required to be also
+described); and a description of how they provide their functionality using a
+technique appropriate to the method used to implement the module.
+
+
+608 The purpose of a module should be described indicating what function the
+module is providing. It should be sufficient so that the reader could get a
+general idea of what the module's function is in the architecture.
+
+
+609 The interfaces presented by a module are those interfaces used by other
+modules to invoke the functionality provided. Interfaces include both _explicit_
+interfaces (e.g., a calling sequence invoked by other modules) as well as
+_implicit_ interfaces (e.g., global data manipulated by the module). Interfaces
+are described in terms of how they are invoked, and any values that are
+returned. This description would include a list of parameters, and
+descriptions of these parameters. If a parameter were expected to take on a
+set of values (e.g., a โflagโ parameter), the complete set of values the
+parameter could take on that would have an effect on module processing
+would be specified. Likewise, parameters representing data structures are
+described such that each field of the data structure is identified and described.
+Global data should be described to the extent required to understand their
+purpose. The level of description required for a global data structure needs to
+be identical to the one for module interfaces, where the input parameter and
+return values correspond to the individual fields and their possible values in
+the data structure. Global data structures may be described separate from the
+modules that manipulate or read them as long as the design of the modules
+contain sufficient information about the global data structures updated or the
+information extracted from global data structures.
+
+
+610 Note that different programming languages may have additional โinterfacesโ
+that would be non-obvious; an example would be operator/function
+overloading in C++. This โimplicit interfaceโ in the class description would
+also be described as part of the module design. Note that although a module
+could present only one interface, it is more common that a module presents a
+small set of related interfaces.
+
+
+611 When it is required to describe the interfaces used by a module, it must be
+clear from either the design description of the module or the purpose of the
+module called, what service is expected from the module called. For example
+if Module A is being described, and it uses Module B's bubble sort routine,
+the description of the interaction between modules must allow to identify
+why Module B's bubble sort routine is called and what this call contributes to
+the implementation of the SFRs. The interface and purpose of Module B's
+bubble sort routine must be described as part of the interfaces of Module B
+(provided the level of ADV_TDS and the classification of Module B require
+a description its interfaces) and so Module A just needs to identify what data
+it needs to have sorted using this routine. An adequate description would be:
+"Module A invokes Module B's interface _double_bubble()_ to sort the
+usernames in alphabetical order".
+
+
+612 Note that if this sorting of the user names is not important for the
+enforcement of any SFR (e. g. it is just done to speed up things and an
+
+
+April 2017 Version 3.1 Page 225 of 247
+
+
+**Development (ADV)**
+
+
+algorithmically identical implementation of Module A could also avoid to
+have the usernames sorted), the use of Module B's bubble sort routine is not
+SFR-enforcing and it is suffcient to explain in the description of Module A
+that the usernames are sorted in alphabetical order to enhance performance.
+Module B may be classified as "SFR-supporting" only and the level of
+ADV_TDS chosen indicates if the interfaces of SFR-supporting modules
+need to be described or if its is sufficient to just describe the purpose of
+Module B.
+
+
+613 As discussed previously, the algorithmic description of the module should
+describe in an algorithmic fashion the implementation of the module. This
+can be done in pseudo-code, through flow charts, or (at ADV_TDS.3 Basic
+modular design) informal text. It discusses how the module inputs and called
+functions are used to accomplish the module's function. It notes changes to
+global data, system state, and return values produced by the module. It is at
+the level of detail that an implementation could be derived that would be
+very similar to the actual implementation of the TOE.
+
+
+614 It should be noted that source code does not meet the module documentation
+requirements. Although the module design describes the implementation, it
+is _not_ the implementation. The comments surrounding the source code might
+be sufficient documentation if they provide an explanation of the intent of
+the source code. In-line comments that merely state what each line of code is
+doing are useless because they provide no explanation of what the module is
+meant to accomplish.
+
+
+615 In the elements below, the labels (SFR-enforcing, SFR-supporting, and SFRnon-interfering) discussed for subsystems and modules are used to describe
+the amount and type of information that needs to be made available by the
+developer. The elements have been structured so that there is no expectation
+that the developer provide _only_ the information specified. That is, if the
+developer's documentation of the TSF provides the information in the
+requirements below, there is no expectation that the developer update their
+documentation and label subsystems and modules as SFR-enforcing, SFRsupporting, and SFR-non-interfering. The primary purpose of this labelling is
+to allow developers with less mature development methodologies (and
+associated artifacts, such as detailed interface and design documentation) to
+provide the necessary evidence without undue cost.
+
+
+**A.4.3** **Levelling Approach**
+
+
+616 Because there is subjectivity in determining what is SFR-enforcing vs. SFRsupporting (and in some cases, even determining what is SFR-noninterfering) the following paradigm has been adopted in this family. In early
+components of the family, the developer makes a determination about the
+classification of the subsystems into SFR-enforcing, etc., supplying the
+appropriate information, and there is little additional evidence for the
+evaluator to examine to support this claim. As the level of desired assurance
+increases, while the developer still makes a classification determination, the
+evaluator obtains more and more evidence that is used to confirm the
+developer's classification.
+
+
+Page 226 of 247 Version 3.1 April 2017
+
+
+**Development (ADV)**
+
+
+617 In order to focus the evaluator's analysis on the SFR-related portions of the
+TOE, especially at lower levels of assurance, the components of the family
+are levelled such that initially detailed information is required only for SFRenforcing architectural entities. As the level of assurance increases, more
+information is required for SFR-supporting and (eventually) SFR-noninterfering entities. It should be noted that even when complete information
+is required, it is not required that all of this information be analysed in the
+same level of detail. The focus should be in all cases on whether the
+_necessary_ information has been provided and analysed.
+
+
+618 Table 14 summarises the information required at each of the family
+components for the architectural entities to be described.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+|Col1|TSF subsystem|Col3|Col4|TSF Module|Col6|Col7|
+|---|---|---|---|---|---|---|
+||SFR Enforce|SFR
Support|SFR NI|SFR
Enforce|SFR
Support|SFR NI|
+|ADV_TDS.1
Basic design
(informal
presentation)|structure,
summary of
SFR-Enf.
behaviour,
interactions|designation
support(1)|designation
support||||
+|ADV_TDS.2
Architectural
design (informal
presentation)|structure,
detailed
description of
SFR-Enf.
behaviour,
summary of
other
behaviour,
interactions|structure,
summary of
other
behaviour,
interactions|designation
support,
interactions||||
+|ADV_TDS.3
Basic modular
design (informal
presentation)|description,
interactions|description,
interactions|description,
interactions|purpose,
SFR
interfaces(2)|interaction,
purpose|interaction,
purpose|
+|ADV_TDS.4
Semiformal
modular design
(semiformal
presentation)|description,
interactions|description,
interactions|description,
interactions|purpose,
SFR
interfaces|purpose,
SFR
interfaces|interaction,
purpose|
+|ADV_TDS.5
Complete
semiformal
modular design
(semiformal
presentation)|description,
interactions|description,
interactions|description,
interactions|purpose, all
interfaces(3)|purpose, all
interfaces|purpose,
all
interfaces|
+|ADV_TDS.6
Complete
semiformal
modular design
with formal
high-level
design
presentation
(semiformal|description,
interactions|description,
interactions|description,
interactions|purpose, all
interfaces|purpose, all
interfaces|purpose,
all
interfaces|
+
+
+
+April 2017 Version 3.1 Page 227 of 247
+
+
+**Development (ADV)**
+
+
+
+
+
+
+
+|Col1|TSF subsystem|Col3|Col4|TSF Module|Col6|Col7|
+|---|---|---|---|---|---|---|
+||SFR Enforce|SFR
Support|SFR NI|SFR
Enforce|SFR
Support|SFR NI|
+|presentation;
additional formal
presentation)
|||||||
+
+
+/ module is needed.
+(2) _SFR interfaces_ means that the module description contains, for each SFR-related interface, the returned
+values and the called interfaces to other modules.
+(3) _All interfaces_ means that the module description contains, for each interface, the returned values and the
+called interfaces to other modules.
+
+
+**Table 14 Description Detail Levelling**
+
+## **A.5 Supplementary material on formal methods**
+
+
+619 Formal methods provide a mathematical representation of the TSF and its
+behaviour and are required by the ADV_FSP.6 Complete semi-formal
+functional specification with additional formal specification, ADV_SPM.1
+Formal TOE security policy model, and ADV_TDS.6 Complete semiformal
+modular design with formal high-level design presentation components.
+There are two aspects of formal methods: the _specification language_ that is
+used for formal expression, and the _theorem prover_ that mathematically
+proves the completeness and correctness of the formal specification.
+
+
+620 A formal specification is expressed within a formal system based upon wellestablished mathematical concepts. These mathematical concepts are used to
+define well-defined semantics, syntax and rules of inference. A formal
+system is an abstract system of identities and relations that can be described
+by specifying a formal alphabet, a formal language over that alphabet which
+is based on a formal syntax, and a set of formal rules of inference for
+constructing derivations of sentences in the formal language.
+
+
+621 The evaluator should examine the identified formal systems to make sure
+that:
+
+
+๏ญ The semantics, syntax and inference rules of the formal system are
+defined or a definition is referenced.
+
+
+๏ญ Each formal system is accompanied by explanatory text that provides
+defined **semantics** so that:
+
+
+1. the explanatory text provides defined meanings of terms,
+abbreviations and acronyms that are used in a context other
+than that accepted by normal usage,
+
+
+2. the use of a formal system and semiformal notation use is
+accompanied by supporting explanatory text in informal style
+appropriate for unambiguous meaning,
+
+
+3. the formal system is able to express rules and characteristics
+of applicable SFPs, security functionality and interfaces
+
+
+Page 228 of 247 Version 3.1 April 2017
+
+
+**Development (ADV)**
+
+
+(providing details of effects, exceptions and error messages)
+of TSF, their subsystems or modules to be specified for the
+assurance family for which the notations are used.
+
+
+4. the notation provides rules to determine the meaning of
+syntactical valid constructs.
+
+
+๏ญ Each formal system uses a formal syntax that provides rules to
+unambiguously recognise constructs.
+
+
+๏ญ Each formal system provides proof rules which
+
+
+1. support logical reasoning of well-established mathematical
+concepts,
+
+
+2. help to prevent derivation of contradictions
+
+
+622 If the developer uses a formal system which is already accepted by the
+evaluation authority the evaluator can rely on the level of formality and
+strength of the system and focus on the instantiation of the formal system to
+the TOE specifications and correspondence proofs.
+
+
+623 The formal style supports mathematical proofs of the security properties
+based on the security features, the consistency of refinements and the
+correspondence of the representations. Formal tool support seems adequate
+whenever manual derivations would otherwise become long winded and
+incomprehensible. Formal tools are also apt to reduce the error probability
+inherent in manual derivations.
+
+
+624 Examples of formal systems:
+
+
+๏ญ The **Z specification language** is highly expressive, and supports
+many different methods or styles of formal specification. The use of
+Z has been predominantly for model-oriented specification, using
+_schemas_ [to formally specify operations. See http://vl.zuser.org/ for](http://vl.zuser.org/)
+more information.
+
+
+๏ญ **ACL2** is an open-source formal system comprising a LISP-based
+specification language and a theorem prover. See
+[http://www.cs.utexas.edu/users/moore/acl2/ for further information.](http://www.cs.utexas.edu/users/moore/acl2/)
+
+
+๏ญ **Isabelle** is a popular generic theorem proving environment that
+allows mathematical formulae to be expressed in a formal language
+and provides tools for proving those formulae within a logical
+[calculus (see e.g. http://www.cl.cam.ac.uk/Research/HVG/Isabelle/](http://www.cl.cam.ac.uk/Research/HVG/Isabelle/)
+for additional information)
+
+
+๏ญ The **B method** is a formal system based on the propositional calculus,
+the first order predicate calculus with inference rules and set theory
+[(see e.g. http://vl.fmnet.info/b/ for further information).](http://vl.fmnet.info/b/)
+
+
+April 2017 Version 3.1 Page 229 of 247
+
+
+**Composition (ACO)**
+
+# **B Composition (ACO)** **(informative)**
+
+
+625 The goal of this annex is to explain the concepts behind composition
+evaluations and the ACO criteria. This annex does not define the ASE
+criteria; this definition can be found in chapter 12.
+
+## **B.1 Necessity for composed TOE evaluations**
+
+
+626 The IT market is, on the whole, made up of vendors offering a particular type
+of product/technology. Although there is some overlap, where a PC hardware
+vendor may also offer application software and/or operating systems or a
+chip manufacturer may also develop a dedicated operating system for their
+own chipset, it is often the case that an IT solution is implemented by a
+variety of vendors.
+
+
+627 There is sometimes a need for assurance in the combination (composition) of
+components in addition to the assurance of the individual components.
+Although there is cooperation between these vendors, in the dissemination of
+certain material required for the technical integration of the components, the
+agreements rarely stretch to the extent of providing detailed design
+information and development process/procedure evidence. This lack of
+information from the developer of a component on which another component
+relies means that the dependent component developer does not have access to
+the type of information necessary to perform an evaluation of both the
+dependent and base components at EAL2 or above. Therefore, while an
+evaluation of the dependent component can still be performed at any
+assurance level, to compose components with assurance at EAL2 or above it
+is necessary to reuse the evaluation evidence and results of evaluations
+performed for the component developer.
+
+
+628 It is intended that the ACO criteria are applicable in the situation where one
+IT entity is dependent on another for the provision of security services. The
+entity providing the services is termed the โbase componentโ, and that
+receiving the services is termed the โdependent componentโ. This
+relationship may exist in a number of contexts. For example, an application
+(dependent component) may use services provided by an operating system
+(base component). Alternatively, the relationship may be peer-to-peer, in the
+sense of two linked applications, either running in a common operating
+system environment, or on separate hardware platforms. If there is a
+dominant peer providing the services to the minor peer, the dominant peer is
+considered to be the base component and the minor peer the dependent
+component. If the peers provide services to each other in a mutual manner,
+each peer will be considered to be the base component for the services
+offered and dependent component for the services required. This will require
+iterations of the ACO components applying all requirements to each type of
+component peer.
+
+
+Page 230 of 247 Version 3.1 April 2017
+
+
+**Composition (ACO)**
+
+
+629 The criteria are also intended to be more broadly applicable, stepwise (where
+a composed TOE comprised of a dependent component and a base
+component itself becomes the base component of another composed TOE),
+in more complex relationships, but this may require further interpretation.
+
+
+630 It is still required for composed TOE evaluations that the individual
+components are evaluated independently, as the composition evaluation
+builds on the results of the individual component evaluations. The evaluation
+of the dependent component may still be in progress when the composed
+TOE evaluation commences. However, the dependent component evaluation
+must complete before the composed TOE evaluation completes.
+
+
+631 The composed evaluation activities may take place at the same time as the
+dependent component evaluation. This is due to two factors:
+
+
+a) Economic/business drivers - the dependent component developer will
+either be sponsoring the composition evaluation activities or
+supporting these activities as the evaluation deliverables from the
+dependent component evaluation are required for composed
+evaluation activities.
+
+
+b) Technical drivers - the components consider whether the requisite
+assurance is provided by the base component (e.g. considering the
+changes to the base component since completion of the component
+evaluation) with the understanding that the dependent component has
+recently undergone (is undergoing) component evaluation and all
+evaluation deliverables associated with the evaluation are available.
+Therefore, there are no activities during composition requesting the
+dependent component evaluation activities to be re-verified. Also, it
+is verified that the base component forms (one of) the test
+configurations for the testing of the dependent component during the
+dependent component evaluation, leaving ACO_CTT to consider the
+base component in this configuration.
+
+
+632 The evaluation evidence from the evaluation of the dependent component is
+required input into the composed TOE evaluation activities. The only
+evaluation material from the evaluation of the base component that is
+required as input into the composed TOE evaluation activities:
+
+
+a) Residual vulnerabilities in the base component, as reported during the
+base component evaluation. This is required for the ACO_VUL
+activities.
+
+
+633 No other evaluation evidence from the base component activities should be
+required for the composed TOE evaluation, as the evaluation results from the
+component evaluation of the base component should be reused. Additional
+information about the base component may be required if the composed TOE
+TSF includes more of the base component than was considered to be TSF
+during component evaluation of the base component.
+
+
+April 2017 Version 3.1 Page 231 of 247
+
+
+**Composition (ACO)**
+
+
+634 The component evaluation of the base and dependent components are
+assumed to be complete by the time final verdicts are assigned for the ACO
+components.
+
+
+635 The ACO_VUL components only consider resistance against an attacker
+with an attack potential up to Enhanced-Basic. This is due to the level of
+design information that can be provided of how the base component provides
+the services on which the dependent component relies through application of
+the ACO_DEV activities. Therefore, the confidence arising from composed
+TOE evaluations using CAPs is limited to a level similar to that obtained
+from EAL4 component TOE evaluations. Although assurance in the
+components that comprise the composed TOE may be higher than EAL4.
+
+## **B.2 Performing Security Target evaluation for a composed** **TOE**
+
+
+636 An ST will be submitted by the developer for the evaluation of the composed
+(base component + dependent component) TOE. This ST will identify the
+assurance package to be applied to the composed TOE, providing assurance
+in the composed entity by drawing upon the assurance gained in the
+component evaluations.
+
+
+637 The purpose of considering the composition of components within an ST is
+to validate the compatibility of the components from the point of view of
+both the environment and the requirements, and also to assess that the
+composed TOE ST is consistent with the component STs and the security
+policies expressed within them. This includes determining that the
+component STs and the security policies expressed within them are
+compatible.
+
+
+638 The composed TOE ST may refer out to the content of the component STs,
+or the ST author may chose to reiterate the material of the component STs
+within the composed TOE ST providing a rationale of how the component
+STs are represented in the composed TOE ST.
+
+
+639 During the conduct of the ASE_CCL evaluation activities for a composed
+TOE ST the evaluator determines that the component STs are accurately
+represented in the composed TOE ST. This is achieved through determining
+that the composed TOE ST demonstrably conforms to the component TOE
+STs. Also, the evaluator will need to determine that the dependencies of the
+dependent component on the operational environment are adequately
+fulfilled in the composed TOE.
+
+
+640 The composed TOE description will describe the composed solution. The
+logical and physical scope and boundary of the composed solution will be
+described, and the logical boundary(ies) between the components will also be
+identified. The description will identify the security functionality to be
+provided by each component.
+
+
+641 The statement of SFRs for the composed TOE will identify which
+component is to satisfy an SFR. If an SFR is met by both components, then
+
+
+Page 232 of 247 Version 3.1 April 2017
+
+
+**Composition (ACO)**
+
+
+the statement will identify which component meets the different aspects of
+the SFR. Similarly the composed TOE Summary Specification will identify
+which component provides the security functionality described.
+
+
+642 The package of ASE: Security Target evaluation requirements applied to the
+composed TOE ST should be consistent with the package of ASE: Security
+Target evaluation requirements used in the component evaluations.
+
+
+643 Reuse of evaluation results from the evaluation of component STs can be
+made in the instances that the composed TOE ST directly refers to the
+component STs. e.g. if the composed TOE ST refers to a component ST for
+part of its statement of SFRs, the evaluator can understand that the
+requirement for the completion of all assignment and selection operations (as
+stated in ASE_REQ.*.3C has been satisfied in the component evaluations.
+
+## **B.3 Interactions between composed IT entities**
+
+
+644 The TSF of the base component is often defined without knowledge of the
+dependencies of the possible applications with which it may by composed.
+The TSF of this base component is defined to include all parts of the base
+component that have to be relied upon for enforcement of the base
+component SFRs. This will include all parts of the base component required
+to implement the base component SFRs.
+
+
+645 The TSFI of this base component represents the interfaces provided by the
+TSF to the external entities defined in the statement of SFRs to invoke a
+service of the TSF. This includes interfaces to the human user and also
+interfaces to external IT entities. However, the TSFI only includes those
+interfaces to the TSF, and therefore is not necessarily an exhaustive interface
+specification of all possible interfaces available between an external entity
+and the base component. The base component may present interfaces to
+services that were not considered security-relevant, either because of the
+inherent purpose of the service (e.g., adjust type font) or because associated
+CC SFRs are not being claimed in the base component's ST (e.g. the login
+interface when no FIA: Identification and authentication SFRs are claimed).
+
+
+646 The functional interfaces provided by the base component are in addition to
+the security interfaces (TSFIs), and are not required to be considered during
+the base component evaluation. These often include interfaces that are used
+by a dependent component to invoke a service provided by the base
+component.
+
+
+647 The base component may include some indirect interfaces through which
+TSFIs may be called, e.g. APIs that can be used to invoke a service of the
+TSF, which were not considered during the evaluation of the base component.
+
+
+April 2017 Version 3.1 Page 233 of 247
+
+
+**Composition (ACO)**
+
+
+**Figure 23 - Base component abstraction**
+
+
+648 The dependent component, which relies on the base component, is similarly
+defined: interfaces to external entities defined in the SFRs of the component
+ST are categorised as TSFI and are examined in ADV_FSP.
+
+
+649 Any call out from the dependent TSF to the environment in support of an
+SFR will indicate that the dependent TSF requires some service from the
+environment in order to satisfy the enforcement of the stated dependent
+component SFRs. Such a service is outside the dependent component
+boundary and the base component is unlikely to be defined in the dependent
+ST as an external entity. Hence, the calls for services made out by the
+dependent TSF to its underlying platform (the base component) will not be
+analysed as part of the Functional specification (ADV_FSP) activities. These
+dependencies on the base component are expressed in the dependent
+component ST as security objectives for the environment.
+
+
+650 This abstraction of the dependent component and the interfaces is shown in
+Figure 24 below.
+
+
+Page 234 of 247 Version 3.1 April 2017
+
+
+**Composition (ACO)**
+
+
+**Figure 24 - Dependent component abstraction**
+
+
+651 When considering the composition of the base component and the dependent
+component, if the dependent component's TSF requires services from the
+base component to support the implementation of the SFR, the interface to
+the service will need to be defined. If that service is provided by the base
+component's TSF, then that interface should be a TSFI of the base
+component and will therefore already be defined within the functional
+specification of the base component.
+
+
+652 If, however, the service called by the dependent component's TSF is not
+provided by the TSF of the base component (i.e., it is implemented in the
+non-TSF portion of the base component or possibly even in the non-TOE
+portion of the base component (not illustrated in Figure 25), there is unlikely
+to be a TSFI of the base component relating to the service, unless the service
+is mediated by the TSF of the base component. The interfaces to these
+services from the dependent component to the operational environment are
+considered in the family Reliance of dependent component (ACO_REL).
+
+
+653 The non-TSF portion of the base component is drawn into the TSF of the
+composed TOE due to the dependencies the dependent component has on the
+base component to support the SFRs of the dependent component. Therefore,
+in such cases, the TSF of the composed TOE would be larger than simply the
+sum of the components' TSFs.
+
+
+April 2017 Version 3.1 Page 235 of 247
+
+
+**Composition (ACO)**
+
+
+**Figure 25 - Composed TOE abstraction**
+
+
+654 It may be the case that the base component TSFI is being called in a manner
+that was unforeseen in the base component evaluation. Hence there would be
+a requirement for further testing of the base component TSFI.
+
+
+655 The possible interfaces are further described in the following diagram
+(Figure 26) and supporting text.
+
+
+**Figure 26 - Composed component interfaces**
+
+
+a) Arrows going _into_ 'dependent component-a' (A and B) = where the
+component expects the environment to respond to a service request
+(responding to calls out from dependent component to the
+environment);
+
+
+Page 236 of 247 Version 3.1 April 2017
+
+
+**Composition (ACO)**
+
+
+b) Arrows coming _out_ of 'base component-b' (C and D) = interfaces of
+services provided by the base component to the environment;
+
+
+c) Broken lines between components = types of communication
+between pairs of interfaces;
+
+
+d) The other (grey) arrows = interfaces that are described by the given
+criteria.
+
+
+656 The following is a simplification, but explains the considerations that need to
+be made.
+
+
+657 There are components a ('dependent component-a') and b ('base componentb'): the arrows coming _out_ of TSF-a are services provided by TSF-a and are
+therefore TSFIs(a); likewise, the arrows coming _out_ of TSF-b (โCโ) are
+TSFIs(b). These are each detailed in their respective functional specs.
+component-a is such that it requires services from its environment: those
+needed by the TSF(a) are labelled โAโ; the other (not related to TSF-a)
+services are labelled โBโ.
+
+
+658 When component-a and component-b are combined, there are four possible
+combinations of {services needed by component-a} and {services provided
+by component-b}, shown as broken lines (types of communication between
+pairs of interfaces). Any set of these might exist for a particular composition:
+
+
+a) TSF-a needs those services that are provided by TSF-b ("A" is
+connected to "C"): this is straightforward: the details about "C" are in
+the FSP for component-b. In this instance the interfaces should all be
+defined in the functional specifications for the component-b.
+
+
+b) Non-TSF-a needs those services that are provided by TSF-b (โBโ is
+connected to โCโ): this is straightforward (again, the details about
+โCโ are in the FSP for component-b), but unimportant: security-wise.
+
+
+c) Non-TSF-a needs those services that are provided by non-TSF-b (โBโ
+is connected to โDโ): we have no details about D, but there are no
+security implications about the use of these interfaces, so they do not
+need to be considered in the evaluation, although they are likely to be
+an integration issue for the developer.
+
+
+d) TSF-a needs those services that are provided by non-TSF-b (โAโ is
+connected to โDโ): this would arise when component-a and
+component-b have different senses of what a โsecurity serviceโ is.
+Perhaps component-b is making no claims about I&A (has no FIA
+SFRs in its ST), but component-a needs authentication provided by
+its environment. There are no details about the โDโ interfaces
+available (they are not TSFI (b), so they are not in component-b's
+FSP).
+
+
+April 2017 Version 3.1 Page 237 of 247
+
+
+**Composition (ACO)**
+
+
+659 Note: if the kind of interaction described in case d above exists, then the TSF
+of the composed TOE would be TSF-a + TSF-b + Non-TSF-b. Otherwise,
+the TSF of the composed TOE would be TSF-a + TSF-b.
+
+
+660 Interfaces types 2 and 4 of Figure 26 are not directly relevant to the
+evaluation of the composed TOE. Interfaces 1 and 3 will be considered
+during the application of different families:
+
+
+a) Functional specification (ADV_FSP) (for component-b) will describe
+the C interfaces.
+
+
+b) Reliance of dependent component (ACO_REL) will describe the A
+interfaces.
+
+
+c) Development evidence (ACO_DEV) will describe the C interfaces
+for connection type 1 and the D interfaces for connection type 3.
+
+
+661 A typical example where composition may be applied is a database
+management system (DBMS) that relies upon its underlying operating
+system (OS). During the evaluation of the DBMS component, there will be
+an assessment made of the security properties of that DBMS (to whatever
+degree of rigour is dictated by the assurance components used in the
+evaluation): its TSF boundary will be identified, its functional specification
+will be assessed to determine whether it describes the interfaces to the
+security services provided by the TSF, perhaps additional information about
+the TSF (its design, architecture, internal structure) will be provided, the TSF
+will be tested, aspects of its life-cycle and its guidance documentation will be
+assessed, etc.
+
+
+662 However, the DBMS evaluation will not call for any evidence concerning the
+dependency the DBMS has on the OS. The ST of the DBMS will most likely
+state assumptions about the OS in its Assumptions section and state security
+objectives for the OS in its Environment section. The DBMS ST may even
+instantiate those objectives for the environment in terms of SFRs for the OS.
+However, there will be no specification for the OS that mirrors the detail in
+the functional specification, architecture description, or other ADV evidence
+as for the DBMS. Reliance of dependent component (ACO_REL) will fulfil
+that need.
+
+
+663 Reliance of dependent component (ACO_REL) describes the interfaces of
+the dependent TOE that make the calls to the base component for the
+provision of services. These are the interfaces to which the base component
+is to respond. The interface descriptions are provided from the dependent
+component's viewpoint.
+
+
+664 Development evidence (ACO_DEV) describes the interfaces provided by the
+base component, which respond to the dependent component service requests.
+These interfaces are mapped to the relevant dependent component interfaces
+that are identified in the reliance information. (The completeness of this
+mapping, whether the base component interfaces described represent all
+dependent component interfaces, is not verified here, but in Composition
+
+
+Page 238 of 247 Version 3.1 April 2017
+
+
+**Composition (ACO)**
+
+
+rationale (ACO_COR)). At the higher levels of ACO_DEV the subsystems
+providing the interfaces are described.
+
+
+665 Any interfaces required by the dependent component that have not been
+described for the base component are reported in the rationale for
+Composition rationale (ACO_COR). The rationale also reports whether the
+interfaces of the base component on which the dependent component relies
+were considered within the base component evaluation. For any interfaces
+that were not considered in the base component evaluation, a rationale is
+provided of the impact of using the interface on the base component TSF.
+
+
+April 2017 Version 3.1 Page 239 of 247
+
+
+**Cross reference of assurance component dependencies**
+
+# **C Cross reference of assurance component** **dependencies** **(informative)**
+
+
+666 The dependencies documented in the components of Chapters 10 and 12-18
+are the direct dependencies between the assurance components.
+
+
+667 The following dependency tables for assurance components show their direct,
+indirect and optional dependencies. Each of the components that is a
+dependency of some assurance component is allocated a column. Each
+assurance component is allocated a row. The value in the table cell indicate
+whether the column label component is directly required (indicated by a
+cross โXโ) or indirectly required (indicated by a dash โ-โ), by the row label
+component. If no character is presented, the component is not dependent
+upon another component.
+
+|Col1|ACO_DEV.1|ACO_DEV.2|ACO_DEV.3|ACO_REL.1|ACO_REL.2|ALC_CMC.1|ALC_CMS.1|
+|---|---|---|---|---|---|---|---|
+|ACO_COR.1|X|||X||X|-|
+|ACO_CTT.1|X|||X||||
+|ACO_CTT.2||X||-|X|||
+|ACO_DEV.1||||X||||
+|ACO_DEV.2||||X||||
+|ACO_DEV.3|||||X|||
+|ACO_REL.1||||||||
+|ACO_REL.2||||||||
+|ACO_VUL.1|X|||-||||
+|ACO_VUL.2||X||-||||
+|ACO_VUL.3|||X||-|||
+
+
+
+**Table 15 Dependency table for Class ACO: Composition**
+
+
+Page 240 of 247 Version 3.1 April 2017
+
+
+**Cross reference of assurance component dependencies**
+
+|Col1|ADV_FSP.1|ADV_FSP.2|ADV_FSP.3|ADV_FSP.4|ADV_FSP.5|ADV_FSP.6|ADV_IMP.1|ADV_TDS.1|ADV_TDS.3|ALC_CMC.5|ALC_CMS.1|ALC_DVS.2|ALC_LCD.1|ALC_TAT.1|
+|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
+|ADV_ARC.1|X|-||||||X|||||||
+|ADV_FSP.1|||||||||||||||
+|ADV_FSP.2||-||||||X|||||||
+|ADV_FSP.3||-||||||X|||||||
+|ADV_FSP.4||-||||||X|||||||
+|ADV_FSP.5||-||-|||X|X|-|||||-|
+|ADV_FSP.6||-||-|||X|X|-|||||-|
+|ADV_IMP.1||-||-|||-|-|X|||||X|
+|ADV_IMP.2||-||-|||-|-|X|X|-|-|-|X|
+|ADV_INT.1||-||-|||X|-|X|||||X|
+|ADV_INT.2||-||-|||X|-|X|||||X|
+|ADV_INT.3||-||-|||X|-|X|||||X|
+|ADV_SPM.1||-||X||||-|||||||
+|ADV_TDS.1||X||||||-|||||||
+|ADV_TDS.2||-|X|||||-|||||||
+|ADV_TDS.3||-||X||||-|||||||
+|ADV_TDS.4||-||-|X||-|-|-|||||-|
+|ADV_TDS.5||-||-|X||-|-|-|||||-|
+|ADV_TDS.6||-||-||X|-|-|-|||||-|
+
+
+
+**Table 16 Dependency table for Class ADV: Development**
+
+|Col1|ADV_FSP.1|
+|---|---|
+|AGD_OPE.1|X|
+|AGD_PRE.1||
+
+
+
+**Table 17 Dependency table for Class AGD: Guidance documents**
+
+
+April 2017 Version 3.1 Page 241 of 247
+
+
+**Cross reference of assurance component dependencies**
+
+|Col1|ADV_FSP.2|ADV_FSP.4|ADV_IMP.1|ADV_TDS.1|ADV_TDS.3|ALC_CMS.1|ALC_DVS.1|ALC_DVS.2|ALC_LCD.1|ALC_TAT.1|
+|---|---|---|---|---|---|---|---|---|---|---|
+|ALC_CMC.1||||||X|||||
+|ALC_CMC.2||||||X|||||
+|ALC_CMC.3||||||X|X||X||
+|ALC_CMC.4||||||X|X||X||
+|ALC_CMC.5||||||X||X|X||
+|ALC_CMS.1|||||||||||
+|ALC_CMS.2|||||||||||
+|ALC_CMS.3|||||||||||
+|ALC_CMS.4|||||||||||
+|ALC_CMS.5|||||||||||
+|ALC_DEL.1|||||||||||
+|ALC_DVS.1|||||||||||
+|ALC_DVS.2|||||||||||
+|ALC_FLR.1|||||||||||
+|ALC_FLR.2|||||||||||
+|ALC_FLR.3|||||||||||
+|ALC_LCD.1|||||||||||
+|ALC_LCD.2|||||||||||
+|ALC_TAT.1|-|-|X|-|-|||||-|
+|ALC_TAT.2|-|-|X|-|-|||||-|
+|ALC_TAT.3|-|-|X|-|-|||||-|
+
+
+
+**Table 18 Dependency table for Class ALC: Life-cycle support**
+
+|Col1|APE_ECD.1|APE_INT.1|APE_OBJ.2|APE_REQ.1|APE_SPD.1|
+|---|---|---|---|---|---|
+|APE_CCL.1|X|X||X||
+|APE_ECD.1||||||
+|APE_INT.1||||||
+|APE_OBJ.1||||||
+|APE_OBJ.2|||||X|
+|APE_REQ.1|X|||||
+|APE_REQ.2|X||X||-|
+|APE_SPD.1||||||
+
+
+
+**Table 19 Dependency table for Class APE: Protection Profile evaluation**
+
+
+Page 242 of 247 Version 3.1 April 2017
+
+
+**Cross reference of assurance component dependencies**
+
+|Col1|ACE_ECD.1|ACE_INT.1|ACE_MCO.1|ACE_OBJ.1|ACE_REQ.1|ACE_SPD.1|
+|---|---|---|---|---|---|---|
+|ACE_CCL.1|X|X||-|X||
+|ACE_CCO.1|-|X|X|-|X|-|
+|ACE_ECD.1|||||||
+|ACE_INT.1|||||||
+|ACE_MCO.1|-|X||X|X|X|
+|ACE_OBJ.1|||||||
+|ACE_REQ.1|X|||X|||
+|ACE_SPD.1|||||||
+
+
+
+**Table 20 Dependency table for Class ACE: Protection Profile Configuration evaluation**
+
+|Col1|ADV_ARC.1|ADV_FSP.1|ADV_FSP.2|ADV_TDS.1|ASE_ECD.1|ASE_INT.1|ASE_OBJ.2|ASE_REQ.1|ASE_SPD.1|
+|---|---|---|---|---|---|---|---|---|---|
+|ASE_CCL.1|||||X|X||X||
+|ASE_ECD.1||||||||||
+|ASE_INT.1||||||||||
+|ASE_OBJ.1||||||||||
+|ASE_OBJ.2|||||||||X|
+|ASE_REQ.1|||||X|||||
+|ASE_REQ.2|||||X||X||-|
+|ASE_SPD.1||||||||||
+|ASE_TSS.1||X|||-|X||X||
+|ASE_TSS.2|X|-|-|-|-|X||X||
+
+
+
+**Table 21 Dependency table for Class ASE: Security Target evaluation**
+
+
+April 2017 Version 3.1 Page 243 of 247
+
+
+**Cross reference of assurance component dependencies**
+
+|Col1|ADV_ARC.1|ADV_FSP.1|ADV_FSP.2|ADV_FSP.3|ADV_FSP.4|ADV_FSP.5|ADV_IMP.1|ADV_TDS.1|ADV_TDS.2|ADV_TDS.3|ADV_TDS.4|AGD_OPE.1|AGD_PRE.1|ALC_TAT.1|ATE_COV.1|ATE_FUN.1|
+|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
+|ATE_COV.1|||X|||||-|||||||-|X|
+|ATE_COV.2|||X|||||-|||||||-|X|
+|ATE_COV.3|||X|||||-|||||||-|X|
+|ATE_DPT.1|X|-|-|-||||-|X||||||-|X|
+|ATE_DPT.2|X|-|-||-|||-||X|||||-|X|
+|ATE_DPT.3|X|-|-||-|-|-|-||-|X|||-|-|X|
+|ATE_DPT.4|X|-|-||-|-|X|-||-|X|||-|-|X|
+|ATE_FUN.1|||-|||||-|||||||X|-|
+|ATE_FUN.2|||-|||||-|||||||X|-|
+|ATE_IND.1||X||||||||||X|X||||
+|ATE_IND.2||-|X|||||-||||X|X||X|X|
+|ATE_IND.3||-|-||X|||-||||X|X||X|X|
+
+
+
+**Table 22 Dependency table for Class ATE: Tests**
+
+|Col1|ADV_ARC.1|ADV_FSP.1|ADV_FSP.2|ADV_FSP.3|ADV_FSP.4|ADV_IMP.1|ADV_TDS.1|ADV_TDS.2|ADV_TDS.3|AGD_OPE.1|AGD_PRE.1|ALC_TAT.1|ATE_COV.1|ATE_DPT.1|ATE_FUN.1|
+|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
+|AVA_VAN.1||X||||||||X|X|||||
+|AVA_VAN.2|X|-|X||||X|||X|X|||||
+|AVA_VAN.3|X|-|-|-|X|X|-|-|X|X|X|-|-|X|-|
+|AVA_VAN.4|X|-|-|-|X|X|-|-|X|X|X|-|-|X|-|
+|AVA_VAN.5|X|-|-|-|X|X|-|-|X|X|X|-|-|X|-|
+
+
+
+**Table 23 Dependency table for Class AVA: Vulnerability assessment**
+
+
+Page 244 of 247 Version 3.1 April 2017
+
+
+**Cross reference of PPs and assurance components**
+
+# **D Cross reference of PPs and assurance** **components** **(informative)**
+
+
+668 Table 24 describes the relationship between PPs and the families and
+
+
+
+
+
+
+
+
+
+
+|components of the APE class.|Col2|Col3|Col4|
+|---|---|---|---|
+|Assurance class|Assurance
family|Assurance component|Assurance component|
+|Assurance class|Assurance
family|Low Assurance
PP|PP|
+|Protection Profile
evaluation|APE_CCL|**1**|1|
+|Protection Profile
evaluation|APE_ECD|**1**|1|
+|Protection Profile
evaluation|APE_INT|**1**|1|
+|Protection Profile
evaluation|APE_OBJ|**1**|**2**|
+|Protection Profile
evaluation|APE_REQ|**1**|**2**|
+|Protection Profile
evaluation|APE_SPD||**1**|
+
+
+
+**Table 24 PP assurance level summary**
+
+
+April 2017 Version 3.1 Page 245 of 247
+
+
+**Cross reference of EALs and assurance components**
+
+# **E Cross reference of EALs and assurance** **components** **(informative)**
+
+
+669 Table 25 describes the relationship between the evaluation assurance levels
+and the assurance classes, families and components.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+|Assurance
class|Assurance
Family|Assurance Components by Evaluation
Assurance Level|Col4|Col5|Col6|Col7|Col8|Col9|
+|---|---|---|---|---|---|---|---|---|
+|Assurance
class|Assurance
Family|EAL1|EAL2|EAL3|EAL4|EAL5|EAL6|EAL7|
+|Development|ADV_ARC||**1**|1|1|1|1|1|
+|Development|ADV_FSP|**1**|**2**|**3**|**4**|**5**|5|**6**|
+|Development|ADV_IMP||||**1**|1|**2**|2|
+|Development|ADV_INT|||||**2**|**3**|3|
+|Development|ADV_SPM||||||**1**|1|
+|Development|ADV_TDS||**1**|**2**|**3**|**4**|**5**|**6**|
+|Guidance
documents|AGD_OPE|**1**|1|1|1|1|1|1|
+|Guidance
documents|AGD_PRE|**1**|1|1|1|1|1|1|
+|Life-cycle
support|ALC_CMC|**1**|**2**|**3**|**4**|4|**5**|5|
+|Life-cycle
support|ALC_CMS|**1**|**2**|**3**|**4**|**5**|5|5|
+|Life-cycle
support|ALC_DEL||**1**|1|1|1|1|1|
+|Life-cycle
support|ALC_DVS|||**1**|1|1|**2**|2|
+|Life-cycle
support|ALC_FLR||||||||
+|Life-cycle
support|ALC_LCD|||**1**|1|1|1|**2**|
+|Life-cycle
support|ALC_TAT||||**1**|**2**|**3**|3|
+|Security
Target
evaluation|ASE_CCL|**1**|1|1|1|1|1|1|
+|Security
Target
evaluation|ASE_ECD|**1**|1|1|1|1|1|1|
+|Security
Target
evaluation|ASE_INT|**1**|1|1|1|1|1|1|
+|Security
Target
evaluation|ASE_OBJ|**1**|**2**|2|2|2|2|2|
+|Security
Target
evaluation|ASE_REQ|**1**|**2**|2|2|2|2|2|
+|Security
Target
evaluation|ASE_SPD||**1**|1|1|1|1|1|
+|Security
Target
evaluation|ASE_TSS|**1**|1|1|1|1|1|1|
+|Tests|ATE_COV||**1**|**2**|2|2|**3**|3|
+|Tests|ATE_DPT|||**1**|1|**3**|3|**4**|
+|Tests|ATE_FUN||**1**|1|1|1|**2**|2|
+|Tests|ATE_IND|**1**|**2**|2|2|2|2|**3**|
+|Vulnerability
assessment|AVA_VAN|**1**|**2**|2|**3**|**4**|**5**|5|
+
+
+
+**Table 25 Evaluation assurance level summary**
+
+
+Page 246 of 247 Version 3.1 April 2017
+
+
+**Cross reference of CAPs and assurance components**
+
+# **F Cross reference of CAPs and assurance** **components** **(informative)**
+
+
+670 Table 26 describes the relationship between the composition assurance levels
+and the assurance classes, families and components.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+|Assurance class|Assurance
Family|Assurance Components by
Composition Assurance
Package|Col4|Col5|
+|---|---|---|---|---|
+|Assurance class|Assurance
Family|CAP-A|CAP-B|CAP-C|
+|Composition|ACO_COR|**1**|1|1|
+|Composition|ACO_CTT|**1**|**2**|2|
+|Composition|ACO_DEV|**1**|**2**|**3**|
+|Composition|ACO_REL|**1**|1|**2**|
+|Composition|ACO_VUL|**1**|**2**|**3**|
+|Guidance
documents|AGD_OPE|**1**|1|1|
+|Guidance
documents|AGD_PRE|**1**|1|1|
+|Life-cycle
support|ALC_CMC|**1**|1|1|
+|Life-cycle
support|ALC_CMS|**2**|2|2|
+|Life-cycle
support|ALC_DEL||||
+|Life-cycle
support|ALC_DVS||||
+|Life-cycle
support|ALC_FLR||||
+|Life-cycle
support|ALC_LCD||||
+|Life-cycle
support|ALC_TAT||||
+|Security Target
evaluation|ASE_CCL|**1**|1|1|
+|Security Target
evaluation|ASE_ECD|**1**|1|1|
+|Security Target
evaluation|ASE_INT|**1**|1|1|
+|Security Target
evaluation|ASE_OBJ|**1**|**2**|2|
+|Security Target
evaluation|ASE_REQ|**1**|**2**|2|
+|Security Target
evaluation|ASE_SPD||**1**|1|
+|Security Target
evaluation|ASE_TSS|**1**|1|1|
+
+
+
+**Table 26 Composition assurance level summary**
+
+
+April 2017 Version 3.1 Page 247 of 247
+
+
+
diff --git a/niap-cc/sdp-file-encrypt/doc/knowledge_base/CEMV3.1R5.md b/niap-cc/sdp-file-encrypt/doc/knowledge_base/CEMV3.1R5.md
new file mode 100644
index 0000000..1be3afa
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/doc/knowledge_base/CEMV3.1R5.md
@@ -0,0 +1,27406 @@
+Consider using the pymupdf_layout package for a greatly improved page layout analysis.
+# **Foreword**
+
+This version of the Common Methodology for Information Technology Security Evaluation
+(CEM v3.1) is the first major revision since being published as CEM v2.3 in 2005.
+
+CEM v3.1 aims to: eliminate redundant evaluation activities; reduce/eliminate activities that
+contribute little to the final assurance of a product; clarify CEM terminology to reduce
+misunderstanding; restructure and refocus the evaluation activities to those areas where
+security assurance is gained; and add new CEM requirements if needed.
+
+_**Trademarks:**_
+
+
+๏ญ UNIX is a registered trademark of The Open Group in the United States and other
+countries
+
+
+๏ญ Windows is a registered trademark of Microsoft Corporation in the United States
+and other countries
+
+
+Page 2 of 430 Version 3.1 April 2017
+
+
+_**Legal Notice:**_
+
+_The governmental organisations listed below contributed to the development of this version_
+_of the Common Methodology for Information Technology Security Evaluation. As the joint_
+_holders of the copyright in the Common Methodology for Information Technology Security_
+_Evaluation, version_ 3.1 _(called โCEM_ 3.1 _โ), they hereby grant non-exclusive license to_
+_ISO/IEC to use CEM_ 3.1 _in the continued development/maintenance of the ISO/IEC 18045_
+_international standard. However, these governmental organisations retain the right to use,_
+_copy, distribute, translate or modify CEM_ 3.1 _as they see fit._
+
+_Australia:_ _The Australian Signals Directorate;_
+_Canada:_ _Communications Security Establishment;_
+_France:_ _Agence Nationale de la Sรฉcuritรฉ des Systรจmes d'Information;_
+_Germany:_ _Bundesamt fรผr Sicherheit in der Informationstechnik;_
+_Japan:_ _Information Technology Promotion Agency;_
+_Netherlands:_ _Netherlands National Communications Security Agency;_
+_New Zealand:_ _Government Communications Security Bureau;_
+_Republic of Korea:_ _National Security Research Institute;_
+_Spain:_ _Ministerio de Administraciones Pรบblicas and_
+_Centro Criptolรณgico Nacional;_
+_Sweden:_ _Swedish Defence Materiel Administration;_
+_United Kingdom:_ _National Cyber Security Centre;_
+_United States:_ _The National Security Agency and the_
+_National Institute of Standards and Technology._
+
+
+April 2017 Version 3.1 Page 3 of 430
+
+
+**Table of contents**
+
+# **Table of Contents**
+
+
+**1** **INTRODUCTION ............................................................................................. 12**
+
+
+**2** **SCOPE ........................................................................................................... 13**
+
+
+**3** **NORMATIVE REFERENCES ......................................................................... 14**
+
+
+**4** **TERMS AND DEFINITIONS ........................................................................... 15**
+
+
+**5** **SYMBOLS AND ABBREVIATED TERMS ..................................................... 17**
+
+
+**6** **OVERVIEW ..................................................................................................... 18**
+
+
+**6.1** **Organisation of the CEM ...................................................................................................................... 18**
+
+
+**7** **DOCUMENT CONVENTIONS ........................................................................ 19**
+
+
+**7.1** **Terminology ............................................................................................................................................ 19**
+
+
+**7.2** **Verb usage .............................................................................................................................................. 19**
+
+
+**7.3** **General evaluation guidance ................................................................................................................. 19**
+
+
+**7.4** **Relationship between CC and CEM structures ................................................................................... 19**
+
+
+**8** **EVALUATION PROCESS AND RELATED TASKS ....................................... 21**
+
+
+**8.1** **Introduction ............................................................................................................................................ 21**
+
+
+**8.2** **Evaluation process overview ................................................................................................................. 21**
+8.2.1 Objectives ....................................................................................................................................... 21
+8.2.2 Responsibilities of the roles ............................................................................................................ 21
+8.2.3 Relationship of roles ....................................................................................................................... 22
+8.2.4 General evaluation model ............................................................................................................... 22
+8.2.5 Evaluator verdicts ........................................................................................................................... 23
+
+
+**8.3** **Evaluation input task ............................................................................................................................. 25**
+8.3.1 Objectives ....................................................................................................................................... 25
+8.3.2 Application notes ............................................................................................................................ 25
+8.3.3 Management of evaluation evidence sub-task ................................................................................ 26
+
+
+**8.4** **Evaluation sub-activities ........................................................................................................................ 27**
+
+
+**8.5** **Evaluation output task ........................................................................................................................... 27**
+8.5.1 Objectives ....................................................................................................................................... 27
+8.5.2 Management of evaluation outputs ................................................................................................. 27
+8.5.3 Application notes ............................................................................................................................ 28
+8.5.4 Write OR sub-task .......................................................................................................................... 28
+8.5.5 Write ETR sub-task ........................................................................................................................ 28
+
+
+**9** **CLASS APE: PROTECTION PROFILE EVALUATION ................................. 36**
+
+
+Page 4 of 430 Version 3.1 April 2017
+
+
+**Table of contents**
+
+
+**9.1** **Introduction ............................................................................................................................................ 36**
+
+
+**9.2** **Application notes .................................................................................................................................... 36**
+9.2.1 Re-using the evaluation results of certified PPs.............................................................................. 36
+
+
+**9.3** **PP introduction (APE_INT) .................................................................................................................. 37**
+9.3.1 Evaluation of sub-activity (APE_INT.1) ........................................................................................ 37
+
+
+**9.4** **Conformance claims (APE_CCL) ......................................................................................................... 39**
+9.4.1 Evaluation of sub-activity (APE_CCL.1) ....................................................................................... 39
+
+
+**9.5** **Security problem definition (APE_SPD) .............................................................................................. 48**
+9.5.1 Evaluation of sub-activity (APE_SPD.1) ....................................................................................... 48
+
+
+**9.6** **Security objectives (APE_OBJ) ............................................................................................................ 50**
+9.6.1 Evaluation of sub-activity (APE_OBJ.1) ........................................................................................ 50
+9.6.2 Evaluation of sub-activity (APE_OBJ.2) ........................................................................................ 50
+
+
+**9.7** **Extended components definition (APE_ECD) ..................................................................................... 54**
+9.7.1 Evaluation of sub-activity (APE_ECD.1) ....................................................................................... 54
+
+
+**9.8** **Security requirements (APE_REQ) ...................................................................................................... 59**
+9.8.1 Evaluation of sub-activity (APE_REQ.1) ....................................................................................... 59
+9.8.2 Evaluation of sub-activity (APE_REQ.2) ....................................................................................... 62
+
+
+**10** **CLASS ACE: PROTECTION PROFILE CONFIGURATION EVALUATION .. 68**
+
+
+**10.1** **Introduction ....................................................................................................................................... 68**
+
+
+**10.2** **PP-Module introduction (ACE_INT) .............................................................................................. 70**
+10.2.1 Evaluation of sub-activity (ACE_INT.1) ........................................................................................ 70
+
+
+**10.3** **PP-Module conformance claims (ACE_CCL) ................................................................................ 71**
+10.3.1 Evaluation of sub-activity (ACE_CCL.1) ....................................................................................... 71
+
+
+**10.4** **PP-Module Security problem definition (ACE_SPD) .................................................................... 73**
+10.4.1 Evaluation of sub-activity (ACE_SPD.1) ....................................................................................... 73
+
+
+**10.5** **PP-Module Security objectives (ACE_OBJ) ................................................................................... 74**
+10.5.1 Evaluation of sub-activity (ACE_OBJ.1) ....................................................................................... 74
+
+
+**10.6** **PP-Module extended components definition (ACE_ECD) ............................................................ 75**
+10.6.1 Evaluation of sub-activity (ACE_ECD.1) ...................................................................................... 75
+
+
+**10.7** **PP-Module security requirements (ACE_REQ) ............................................................................. 76**
+10.7.1 Evaluation of sub-activity (ACE_REQ.1) ...................................................................................... 76
+
+
+**10.8** **PP-Module consistency (ACE_MCO) .............................................................................................. 77**
+10.8.1 Evaluation of sub-activity (ACE_MCO.1) ..................................................................................... 77
+
+
+**10.9** **PP-Configuration consistency (ACE_CCO) .................................................................................... 79**
+10.9.1 Evaluation of sub-activity (ACE_CCO.1) ...................................................................................... 79
+
+
+**11** **CLASS ASE: SECURITY TARGET EVALUATION ....................................... 82**
+
+
+**11.1** **Introduction ....................................................................................................................................... 82**
+
+
+**11.2** **Application notes ............................................................................................................................... 82**
+
+
+April 2017 Version 3.1 Page 5 of 430
+
+
+**Table of contents**
+
+
+11.2.1 Re-using the evaluation results of certified PPs ............................................................................. 82
+
+
+**11.3** **ST introduction (ASE_INT) ............................................................................................................. 83**
+11.3.1 Evaluation of sub-activity (ASE_INT.1) ........................................................................................ 83
+
+
+**11.4** **Conformance claims (ASE_CCL) .................................................................................................... 87**
+11.4.1 Evaluation of sub-activity (ASE_CCL.1) ....................................................................................... 87
+
+
+**11.5** **Security problem definition (ASE_SPD) ......................................................................................... 98**
+11.5.1 Evaluation of sub-activity (ASE_SPD.1) ....................................................................................... 98
+
+
+**11.6** **Security objectives (ASE_OBJ) ...................................................................................................... 100**
+11.6.1 Evaluation of sub-activity (ASE_OBJ.1)...................................................................................... 100
+11.6.2 Evaluation of sub-activity (ASE_OBJ.2)...................................................................................... 100
+
+
+**11.7** **Extended components definition (ASE_ECD) .............................................................................. 104**
+11.7.1 Evaluation of sub-activity (ASE_ECD.1) ..................................................................................... 104
+
+
+**11.8** **Security requirements (ASE_REQ) ............................................................................................... 109**
+11.8.1 Evaluation of sub-activity (ASE_REQ.1) ..................................................................................... 109
+11.8.2 Evaluation of sub-activity (ASE_REQ.2) ..................................................................................... 112
+
+
+**11.9** **TOE summary specification (ASE_TSS) ....................................................................................... 118**
+11.9.1 Evaluation of sub-activity (ASE_TSS.1) ...................................................................................... 118
+11.9.2 Evaluation of sub-activity (ASE_TSS.2) ...................................................................................... 119
+
+
+**12** **CLASS ADV: DEVELOPMENT .................................................................... 121**
+
+
+**12.1** **Introduction ..................................................................................................................................... 121**
+
+
+**12.2** **Application notes ............................................................................................................................. 121**
+
+
+**12.3** **Security Architecture (ADV_ARC) ............................................................................................... 123**
+12.3.1 Evaluation of sub-activity (ADV_ARC.1) ................................................................................... 123
+
+
+**12.4** **Functional specification (ADV_FSP) ............................................................................................. 129**
+12.4.1 Evaluation of sub-activity (ADV_FSP.1) ..................................................................................... 129
+12.4.2 Evaluation of sub-activity (ADV_FSP.2) ..................................................................................... 133
+12.4.3 Evaluation of sub-activity (ADV_FSP.3) ..................................................................................... 139
+12.4.4 Evaluation of sub-activity (ADV_FSP.4) ..................................................................................... 145
+12.4.5 Evaluation of sub-activity (ADV_FSP.5) ..................................................................................... 152
+12.4.6 Evaluation of sub-activity (ADV_FSP.6) ..................................................................................... 159
+
+
+**12.5** **Implementation representation (ADV_IMP) ................................................................................ 160**
+12.5.1 Evaluation of sub-activity (ADV_IMP.1) .................................................................................... 160
+12.5.2 Evaluation of sub-activity (ADV_IMP.2) .................................................................................... 162
+
+
+**12.6** **TSF internals (ADV_INT) .............................................................................................................. 163**
+12.6.1 Evaluation of sub-activity (ADV_INT.1) ..................................................................................... 163
+12.6.2 Evaluation of sub-activity (ADV_INT.2) ..................................................................................... 166
+12.6.3 Evaluation of sub-activity (ADV_INT.3) ..................................................................................... 168
+
+
+**12.7** **Security policy modelling (ADV_SPM) ......................................................................................... 169**
+12.7.1 Evaluation of sub-activity (ADV_SPM.1) .................................................................................... 169
+
+
+**12.8** **TOE design (ADV_TDS) ................................................................................................................. 170**
+12.8.1 Evaluation of sub-activity (ADV_TDS.1) .................................................................................... 170
+12.8.2 Evaluation of sub-activity (ADV_TDS.2) .................................................................................... 174
+12.8.3 Evaluation of sub-activity (ADV_TDS.3) .................................................................................... 180
+
+
+Page 6 of 430 Version 3.1 April 2017
+
+
+**Table of contents**
+
+
+12.8.4 Evaluation of sub-activity (ADV_TDS.4) .................................................................................... 192
+12.8.5 Evaluation of sub-activity (ADV_TDS.5) .................................................................................... 204
+12.8.6 Evaluation of sub-activity (ADV_TDS.6) .................................................................................... 204
+
+
+**13** **CLASS AGD: GUIDANCE DOCUMENTS .................................................... 205**
+
+
+**13.1** **Introduction ..................................................................................................................................... 205**
+
+
+**13.2** **Application notes ............................................................................................................................. 205**
+
+
+**13.3** **Operational user guidance (AGD_OPE) ....................................................................................... 206**
+13.3.1 Evaluation of sub-activity (AGD_OPE.1) .................................................................................... 206
+
+
+**13.4** **Preparative procedures (AGD_PRE) ............................................................................................ 210**
+13.4.1 Evaluation of sub-activity (AGD_PRE.1) .................................................................................... 210
+
+
+**14** **CLASS ALC: LIFE-CYCLE SUPPORT ........................................................ 213**
+
+
+**14.1** **Introduction ..................................................................................................................................... 213**
+
+
+**14.2** **CM capabilities (ALC_CMC)......................................................................................................... 214**
+14.2.1 Evaluation of sub-activity (ALC_CMC.1) ................................................................................... 214
+14.2.2 Evaluation of sub-activity (ALC_CMC.2) ................................................................................... 215
+14.2.3 Evaluation of sub-activity (ALC_CMC.3) ................................................................................... 217
+14.2.4 Evaluation of sub-activity (ALC_CMC.4) ................................................................................... 221
+14.2.5 Evaluation of sub-activity (ALC_CMC.5) ................................................................................... 228
+
+
+**14.3** **CM scope (ALC_CMS) ................................................................................................................... 237**
+14.3.1 Evaluation of sub-activity (ALC_CMS.1) .................................................................................... 237
+14.3.2 Evaluation of sub-activity (ALC_CMS.2) .................................................................................... 237
+14.3.3 Evaluation of sub-activity (ALC_CMS.3) .................................................................................... 238
+14.3.4 Evaluation of sub-activity (ALC_CMS.4) .................................................................................... 239
+14.3.5 Evaluation of sub-activity (ALC_CMS.5) .................................................................................... 241
+
+
+**14.4** **Delivery (ALC_DEL) ...................................................................................................................... 243**
+14.4.1 Evaluation of sub-activity (ALC_DEL.1) ..................................................................................... 243
+
+
+**14.5** **Development security (ALC_DVS) ................................................................................................ 245**
+14.5.1 Evaluation of sub-activity (ALC_DVS.1) .................................................................................... 245
+14.5.2 Evaluation of sub-activity (ALC_DVS.2) .................................................................................... 248
+
+
+**14.6** **Flaw remediation (ALC_FLR) ....................................................................................................... 253**
+14.6.1 Evaluation of sub-activity (ALC_FLR.1) ..................................................................................... 253
+14.6.2 Evaluation of sub-activity (ALC_FLR.2) ..................................................................................... 255
+14.6.3 Evaluation of sub-activity (ALC_FLR.3) ..................................................................................... 259
+
+
+**14.7** **Life-cycle definition (ALC_LCD) ................................................................................................... 266**
+14.7.1 Evaluation of sub-activity (ALC_LCD.1) .................................................................................... 266
+14.7.2 Evaluation of sub-activity (ALC_LCD.2) .................................................................................... 267
+
+
+**14.8** **Tools and techniques (ALC_TAT) ................................................................................................. 270**
+14.8.1 Evaluation of sub-activity (ALC_TAT.1) ..................................................................................... 270
+14.8.2 Evaluation of sub-activity (ALC_TAT.2) ..................................................................................... 272
+14.8.3 Evaluation of sub-activity (ALC_TAT.3) ..................................................................................... 275
+
+
+**15** **CLASS ATE: TESTS .................................................................................... 279**
+
+
+April 2017 Version 3.1 Page 7 of 430
+
+
+**Table of contents**
+
+
+**15.1** **Introduction ..................................................................................................................................... 279**
+
+
+**15.2** **Application notes ............................................................................................................................. 279**
+15.2.1 Understanding the expected behaviour of the TOE ...................................................................... 280
+15.2.2 Testing vs. alternate approaches to verify the expected behaviour of functionality ..................... 280
+15.2.3 Verifying the adequacy of tests .................................................................................................... 281
+
+
+**15.3** **Coverage (ATE_COV) .................................................................................................................... 282**
+15.3.1 Evaluation of sub-activity (ATE_COV.1) .................................................................................... 282
+15.3.2 Evaluation of sub-activity (ATE_COV.2) .................................................................................... 283
+15.3.3 Evaluation of sub-activity (ATE_COV.3) .................................................................................... 284
+
+
+**15.4** **Depth (ATE_DPT) ........................................................................................................................... 285**
+15.4.1 Evaluation of sub-activity (ATE_DPT.1) ..................................................................................... 285
+15.4.2 Evaluation of sub-activity (ATE_DPT.2) ..................................................................................... 288
+15.4.3 Evaluation of sub-activity (ATE_DPT.3) ..................................................................................... 291
+15.4.4 Evaluation of sub-activity (ATE_DPT.4) ..................................................................................... 294
+
+
+**15.5** **Functional tests (ATE_FUN) .......................................................................................................... 295**
+15.5.1 Evaluation of sub-activity (ATE_FUN.1) .................................................................................... 295
+15.5.2 Evaluation of sub-activity (ATE_FUN.2) .................................................................................... 298
+
+
+**15.6** **Independent testing (ATE_IND) .................................................................................................... 299**
+15.6.1 Evaluation of sub-activity (ATE_IND.1) ..................................................................................... 299
+15.6.2 Evaluation of sub-activity (ATE_IND.2) ..................................................................................... 304
+15.6.3 Evaluation of sub-activity (ATE_IND.3) ..................................................................................... 310
+
+
+**16** **CLASS AVA: VULNERABILITY ASSESSMENT ......................................... 311**
+
+
+**16.1** **Introduction ..................................................................................................................................... 311**
+
+
+**16.2** **Vulnerability analysis (AVA_VAN) ............................................................................................... 312**
+16.2.1 Evaluation of sub-activity (AVA_VAN.1) ................................................................................... 312
+16.2.2 Evaluation of sub-activity (AVA_VAN.2) ................................................................................... 318
+16.2.3 Evaluation of sub-activity (AVA_VAN.3) ................................................................................... 326
+16.2.4 Evaluation of sub-activity (AVA_VAN.4) ................................................................................... 337
+16.2.5 Evaluation of sub-activity (AVA_VAN.5) ................................................................................... 346
+
+
+**17** **CLASS ACO: COMPOSITION ..................................................................... 347**
+
+
+**17.1** **Introduction ..................................................................................................................................... 347**
+
+
+**17.2** **Application notes ............................................................................................................................. 347**
+
+
+**17.3** **Composition rationale (ACO_COR) .............................................................................................. 349**
+17.3.1 Evaluation of sub-activity (ACO_COR.1) .................................................................................... 349
+
+
+**17.4** **Development evidence (ACO_DEV) .............................................................................................. 357**
+17.4.1 Evaluation of sub-activity (ACO_DEV.1) .................................................................................... 357
+17.4.2 Evaluation of sub-activity (ACO_DEV.2) .................................................................................... 358
+17.4.3 Evaluation of sub-activity (ACO_DEV.3) .................................................................................... 360
+
+
+**17.5** **Reliance of dependent component (ACO_REL) ........................................................................... 364**
+17.5.1 Evaluation of sub-activity (ACO_REL.1) .................................................................................... 364
+17.5.2 Evaluation of sub-activity (ACO_REL.2) .................................................................................... 366
+
+
+**17.6** **Composed TOE testing (ACO_CTT) ............................................................................................. 370**
+17.6.1 Evaluation of sub-activity (ACO_CTT.1) .................................................................................... 370
+
+
+Page 8 of 430 Version 3.1 April 2017
+
+
+**Table of contents**
+
+
+17.6.2 Evaluation of sub-activity (ACO_CTT.2) .................................................................................... 373
+
+
+**17.7** **Composition vulnerability analysis (ACO_VUL) ......................................................................... 377**
+17.7.1 Evaluation of sub-activity (ACO_VUL.1) .................................................................................... 377
+17.7.2 Evaluation of sub-activity (ACO_VUL.2) .................................................................................... 380
+17.7.3 Evaluation of sub-activity (ACO_VUL.3) .................................................................................... 385
+
+
+**A** **GENERAL EVALUATION GUIDANCE ........................................................ 390**
+
+
+**A.1** **Objectives ......................................................................................................................................... 390**
+
+
+**A.2** **Sampling ........................................................................................................................................... 390**
+
+
+**A.3** **Dependencies .................................................................................................................................... 392**
+A.3.1 Dependencies between activities .................................................................................................. 393
+A.3.2 Dependencies between sub-activities ........................................................................................... 393
+A.3.3 Dependencies between actions ..................................................................................................... 393
+
+
+**A.4** **Site Visits .......................................................................................................................................... 394**
+A.4.1 Introduction .................................................................................................................................. 394
+A.4.2 General Approach ......................................................................................................................... 394
+A.4.3 Orientation Guide for the Preparation of the Check List .............................................................. 395
+A.4.4 Example of a checklist .................................................................................................................. 397
+
+
+**A.5** **Scheme Responsibilities .................................................................................................................. 400**
+
+
+**B** **VULNERABILITY ASSESSMENT (AVA) ..................................................... 402**
+
+
+**B.1** **What is Vulnerability Analysis ....................................................................................................... 402**
+
+
+**B.2** **Evaluator construction of a Vulnerability Analysis ..................................................................... 403**
+B.2.1 Generic vulnerability guidance ..................................................................................................... 403
+B.2.2 Identification of Potential Vulnerabilities ..................................................................................... 413
+
+
+**B.3** **When attack potential is used ......................................................................................................... 417**
+B.3.1 Developer...................................................................................................................................... 417
+B.3.2 Evaluator ....................................................................................................................................... 417
+
+
+**B.4** **Calculating attack potential ............................................................................................................ 419**
+B.4.1 Application of attack potential ...................................................................................................... 419
+B.4.2 Characterising attack potential ...................................................................................................... 420
+
+
+**B.5** **Example calculation for direct attack ............................................................................................ 429**
+
+
+April 2017 Version 3.1 Page 9 of 430
+
+
+**List of figures**
+
+# **List of figures**
+
+
+Figure 1 - Mapping of the CC and CEM structures .............................................................. 20
+Figure 2 - Generic evaluation model .................................................................................... 23
+Figure 3 - Example of the verdict assignment rule ............................................................... 24
+Figure 4 - ETR information content for a PP evaluation ...................................................... 29
+Figure 5 - ETR information content for a TOE evaluation ................................................... 32
+Figure 6 - Evaluation of a PP-Configuration ........................................................................ 69
+
+
+Page 10 of 430 Version 3.1 April 2017
+
+
+**List of tables**
+
+# **List of tables**
+
+
+Table 1 Example of a checklist at EAL 4 (extract) ............................................................ 398
+Table 2 Vulnerability testing and attack potential ............................................................... 418
+Table 3 Calculation of attack potential ................................................................................ 426
+Table 4 Rating of vulnerabilities and TOE resistance ......................................................... 428
+
+
+April 2017 Version 3.1 Page 11 of 430
+
+
+**Introduction**
+
+# **1 Introduction**
+
+
+1 The target audience for the Common Methodology for Information
+Technology Security Evaluation (CEM) is primarily evaluators applying the
+CC and certifiers confirming evaluator actions; evaluation sponsors,
+developers, PP/ST authors and other parties interested in IT security may be
+a secondary audience.
+
+
+2 The CEM recognises that not all questions concerning IT security evaluation
+will be answered herein and that further interpretations will be needed.
+Individual schemes will determine how to handle such interpretations,
+although these may be subject to mutual recognition agreements. A list of
+methodology-related activities that may be handled by individual schemes
+can be found in Annex A.
+
+
+Page 12 of 430 Version 3.1 April 2017
+
+
+**Scope**
+
+# **2 Scope**
+
+
+3 The Common Methodology for Information Technology Security Evaluation
+(CEM) is a companion document to the Common Criteria for Information
+Technology Security Evaluation (CC). The CEM defines the minimum
+actions to be performed by an evaluator in order to conduct a CC evaluation,
+using the criteria and evaluation evidence defined in the CC.
+
+
+4 The CEM does not define evaluator actions for certain high assurance CC
+components, where there is as yet no generally agreed guidance.
+
+
+April 2017 Version 3.1 Page 13 of 430
+
+
+**Normative references**
+
+# **3 Normative references**
+
+
+5 The following referenced documents are indispensable for the application of
+this document. For dated references, only the edition cited applies. For
+undated references, the latest edition of the referenced document (including
+any amendments) applies.
+
+
+[CC] Common Criteria for Information Technology
+Security Evaluation, Version 3.1, revision 5, April
+2017.
+
+
+Page 14 of 430 Version 3.1 April 2017
+
+
+**Terms and definitions**
+
+# **4 Terms and definitions**
+
+
+6 For the purposes of this document, the following terms and definitions apply.
+
+
+7 Terms which are presented in bold-faced type are themselves defined in this
+Section.
+
+
+8 **action** ๏พ evaluator action element of the CC Part 3
+
+
+These actions are either explicitly stated as evaluator actions or implicitly
+derived from developer actions (implied evaluator actions) within the CC
+Part 3 assurance components.
+
+
+9 **activity** ๏พ application of an assurance class of the CC Part 3
+
+
+10 **check** ๏พ generate a **verdict** by a simple comparison
+
+
+Evaluator expertise is not required. The statement that uses this verb
+describes what is mapped.
+
+
+11 **evaluation deliverable** ๏พ any resource required from the sponsor or
+developer by the evaluator or evaluation authority to perform one or more
+evaluation or evaluation oversight activities
+
+
+12 **evaluation evidence** ๏พ tangible **evaluation deliverable**
+
+
+13 **evaluation technical report** ๏พ report that documents the **overall verdict**
+and its justification, produced by the evaluator and submitted to an
+evaluation authority
+
+
+14 **examine** ๏พ generate a **verdict** by analysis using evaluator expertise
+
+
+The statement that uses this verb identifies what is analysed and the
+properties for which it is analysed.
+
+
+15 **interpretation** ๏พ clarification or amplification of a CC, CEM or **scheme**
+requirement
+
+
+16 **methodology** ๏พ system of principles, procedures and processes applied to
+IT security evaluations
+
+
+17 **observation report** ๏พ report written by the evaluator requesting a
+clarification or identifying a problem during the evaluation
+
+
+18 **overall verdict** ๏พ _pass or fail_ statement issued by an evaluator with respect
+to the result of an evaluation
+
+
+19 **oversight verdict** ๏พ statement issued by an evaluation authority confirming
+or rejecting an _overall verdict_ based on the results of evaluation oversight
+activities
+
+
+April 2017 Version 3.1 Page 15 of 430
+
+
+**Terms and definitions**
+
+
+20 **record** ๏พ retain a written description of procedures, events, observations,
+insights and results in sufficient detail to enable the work performed during
+the evaluation to be reconstructed at a later time
+
+
+21 **report** ๏พ include evaluation results and supporting material in the
+**Evaluation Technical Report** or an **Observation Report**
+
+
+22 **scheme** ๏พ set of rules, established by an evaluation authority, defining the
+evaluation environment, including criteria and **methodology** required to
+conduct IT security evaluations
+
+
+23 **sub-activity** ๏พ application of an assurance component of the CC Part 3
+
+
+Assurance families are not explicitly addressed in the CEM because
+evaluations are conducted on a single assurance component from an
+assurance family.
+
+
+24 **tracing** ๏พ simple directional relation between two sets of entities, which
+shows which entities in the first set correspond to which entities in the
+second
+
+
+25 **verdict** ๏พ _pass, fail or inconclusive_ statement issued by an evaluator with
+respect to a CC evaluator action element, assurance component, or class
+
+
+Also see **overall verdict** .
+
+
+26 **work unit** ๏พ most granular level of evaluation work
+
+
+Each CEM action comprises one or more work units, which are grouped
+within the CEM action by CC content and presentation of evidence or
+developer action element. The work units are presented in the CEM in the
+same order as the CC elements from which they are derived. Work units are
+identified in the left margin by a symbol such as ALC_TAT.1-2. In this
+symbol, the string _ALC_TAT.1_ indicates the CC component (i.e. the CEM
+sub-activity), and the final digit ( _2_ ) indicates that this is the second work unit
+in the ALC_TAT.1 sub-activity.
+
+
+Page 16 of 430 Version 3.1 April 2017
+
+
+**Symbols and abbreviated terms**
+
+# **5 Symbols and abbreviated terms**
+
+
+**CEM** Common Methodology for Information Technology
+Security Evaluation
+
+**ETR** Evaluation Technical Report
+
+**OR** Observation Report
+
+
+April 2017 Version 3.1 Page 17 of 430
+
+
+**Overview**
+
+# **6 Overview**
+
+## **6.1 Organisation of the CEM**
+
+
+27 Chapter 7 defines the conventions used in the CEM.
+
+
+28 Chapter 8 describes general evaluation tasks with no verdicts associated with
+them as they do not map to CC evaluator action elements.
+
+
+29 Chapter 9 addresses the work necessary for reaching an evaluation result on
+a PP.
+
+
+30 Chapters 11 to 17 define the evaluation activities, organised by Assurance
+Classes.
+
+
+31 Annex A covers the basic evaluation techniques used to provide technical
+evidence of evaluation results.
+
+
+32 Annex B provides an explanation of the Vulnerability Analysis criteria and
+examples of their application.
+
+
+Page 18 of 430 Version 3.1 April 2017
+
+
+**Document Conventions**
+
+# **7 Document Conventions**
+
+## **7.1 Terminology**
+
+
+33 Unlike the CC, where each element maintains the last digit of its identifying
+symbol for all components within the family, the CEM may introduce new
+work units when a CC evaluator action element changes from sub-activity to
+sub-activity; as a result, the last digit of the work unit's identifying symbol
+may change although the work unit remains unchanged.
+
+
+34 Any methodology-specific evaluation work required that is not derived
+directly from CC requirements is termed _task_ or _sub-task_ .
+
+## **7.2 Verb usage**
+
+
+35 All work unit and sub-task verbs are preceded by the auxiliary verb _shall_ and
+by presenting both the verb and the _shall_ in _**bold italic**_ type face. The
+auxiliary verb _shall_ is used only when the provided text is mandatory and
+therefore only within the work units and sub-tasks. The work units and subtasks contain mandatory activities that the evaluator must perform in order to
+assign verdicts.
+
+
+36 Guidance text accompanying work units and sub-tasks gives further
+explanation on how to apply the CC words in an evaluation. The verb usage
+is in accordance with ISO definitions for these verbs. The auxiliary verb
+_should_ is used when the described method is strongly preferred. All other
+auxiliary verbs, including _may_, are used where the described method(s) is
+allowed but is neither recommended nor strongly preferred; it is merely
+explanation.
+
+
+37 The verbs _check_, _examine_, _report_ and _record_ are used with a precise meaning
+within this part of the CEM and the Chapter 4 should be referenced for their
+definitions.
+
+## **7.3 General evaluation guidance**
+
+
+38 Material that has applicability to more than one sub-activity is collected in
+one place. Guidance whose applicability is widespread (across activities and
+EALs) has been collected into Annex A. Guidance that pertains to multiple
+sub-activities within a single activity has been provided in the introduction to
+that activity. If guidance pertains to only a single sub-activity, it is presented
+within that sub-activity.
+
+## **7.4 Relationship between CC and CEM structures**
+
+
+39 There are direct relationships between the CC structure (i.e. class, family,
+component and element) and the structure of the CEM. Figure 1 illustrates
+the correspondence between the CC constructs of class, family and evaluator
+action elements and CEM activities, sub-activities and actions. However,
+
+
+April 2017 Version 3.1 Page 19 of 430
+
+
+**Document Conventions**
+
+
+several CEM work units may result from the requirements noted in CC
+developer action and content and presentation elements.
+
+
+**Figure 1 - Mapping of the CC and CEM structures**
+
+
+Page 20 of 430 Version 3.1 April 2017
+
+
+**Evaluation process and related tasks**
+
+# **8 Evaluation process and related tasks**
+
+## **8.1 Introduction**
+
+
+40 This chapter provides an overview of the evaluation process and defines the
+tasks an evaluator is intended to perform when conducting an evaluation.
+
+
+41 Each evaluation, whether of a PP or TOE (including ST), follows the same
+process, and has four evaluator tasks in common: the input task, the output
+task, the evaluation sub-activities, and the demonstration of the technical
+competence to the evaluation authority task.
+
+
+42 The input task and the output tasks, which are related to management of
+evaluation evidence and to report generation, are entirely described in this
+chapter. Each task has associated sub-tasks that apply to, and are normative
+for all CC evaluations (evaluation of a PP or a TOE).
+
+
+43 The evaluation sub-activities are only introduced in this chapter, and fully
+described in the following chapters.
+
+
+44 In contrast to the evaluation sub-activities, input and output tasks have no
+verdicts associated with them as they do not map to CC evaluator action
+elements; they are performed in order to ensure conformance with the
+universal principles and to comply with the CEM.
+
+
+45 The demonstration of the technical competence to the evaluation authority
+task may be fulfilled by the evaluation authority analysis of the output tasks
+results, or may include the demonstration by the evaluators of their
+understanding of the inputs for the evaluation sub-activities. This task has no
+associated evaluator verdict, but has an evaluator authority verdict. The
+detailed criteria to pass this task are left to the discretion of the evaluation
+authority, as noted in Annex A.5.
+
+## **8.2 Evaluation process overview**
+
+
+**8.2.1** **Objectives**
+
+
+46 This section presents the general model of the methodology and identifies:
+
+
+a) roles and responsibilities of the parties involved in the evaluation
+process;
+
+
+b) the general evaluation model.
+
+
+**8.2.2** **Responsibilities of the roles**
+
+
+47 The general model defines the following roles: sponsor, developer, evaluator
+and evaluation authority.
+
+
+April 2017 Version 3.1 Page 21 of 430
+
+
+**Evaluation process and related tasks**
+
+
+48 The sponsor is responsible for requesting and supporting an evaluation. This
+means that the sponsor establishes the different agreements for the evaluation
+(e.g. commissioning the evaluation). Moreover, the sponsor is responsible
+for ensuring that the evaluator is provided with the evaluation evidence.
+
+
+49 The developer produces the TOE and is responsible for providing the
+evidence required for the evaluation (e.g. training, design information), on
+behalf of the sponsor.
+
+
+50 The evaluator performs the evaluation tasks required in the context of an
+evaluation: the evaluator receives the evaluation evidence from the developer
+on behalf of the sponsor or directly from the sponsor, performs the
+evaluation sub-activities and provides the results of the evaluation
+assessment to the evaluation authority.
+
+
+51 The evaluation authority establishes and maintains the scheme, monitors the
+evaluation conducted by the evaluator, and issues certification/validation
+reports as well as certificates based on the evaluation results provided by the
+evaluator.
+
+
+**8.2.3** **Relationship of roles**
+
+
+52 To prevent undue influence from improperly affecting an evaluation, some
+separation of roles is required. This implies that the roles described above are
+fulfilled by different entities, except that the roles of developer and sponsor
+may be satisfied by a single entity.
+
+
+53 Moreover, some evaluations (e.g. EAL1 evaluation) may not require the
+developer to be involved in the project. In this case, it is the sponsor who
+provides the TOE to the evaluator and who generates the evaluation evidence.
+
+
+**8.2.4** **General evaluation model**
+
+
+54 The evaluation process consists of the evaluator performing the evaluation
+input task, the evaluation output task and the evaluation sub-activities. Figure
+2 provides an overview of the relationship between these tasks and subactivities.
+
+
+Page 22 of 430 Version 3.1 April 2017
+
+
+**Evaluation process and related tasks**
+
+
+**Figure 2 - Generic evaluation model**
+
+
+55 The evaluation process may be preceded by a preparation phase where initial
+contact is made between the sponsor and the evaluator. The work that is
+performed and the involvement of the different roles during this phase may
+vary. It is typically during this step that the evaluator performs a feasibility
+analysis to assess the likelihood of a successful evaluation.
+
+
+**8.2.5** **Evaluator verdicts**
+
+
+56 The evaluator assigns verdicts to the requirements of the CC and not to those
+of the CEM. The most granular CC structure to which a verdict is assigned is
+the evaluator action element (explicit or implied). A verdict is assigned to an
+applicable CC evaluator action element as a result of performing the
+corresponding CEM action and its constituent work units. Finally, an
+evaluation result is assigned, as described in CC Part 1, Chapter 10,
+Evaluation results.
+
+
+April 2017 Version 3.1 Page 23 of 430
+
+
+**Evaluation process and related tasks**
+
+
+**Figure 3 - Example of the verdict assignment rule**
+
+
+57 The CEM recognises three mutually exclusive verdict states:
+
+
+a) Conditions for a _pass_ verdict are defined as an evaluator completion
+of the CC evaluator action element and determination that the
+requirements for the PP, ST or TOE under evaluation are met. The
+conditions for passing the element are defined as:
+
+
+1) the constituent work units of the related CEM action, and;
+
+
+2) all evaluation evidence required for performing these work
+units is coherent, that is it can be fully and completely
+understood by the evaluator, and
+
+
+3) all evaluation evidence required for performing these work
+units does not have any obvious internal inconsistencies or
+inconsistencies with other evaluation evidence. Note that
+obvious means here that the evaluator discovers this
+inconsistency while performing the work units: the evaluator
+should not undertake a full consistency analysis across the
+entire evaluation evidence every time a work unit is
+performed.
+
+
+b) Conditions for a _fail_ verdict are defined as an evaluator completion of
+the CC evaluator action element and determination that the
+requirements for the PP, ST, or TOE under evaluation are not met, or
+
+
+Page 24 of 430 Version 3.1 April 2017
+
+
+**Evaluation process and related tasks**
+
+
+that the evidence is incoherent, or an obvious inconsistency in the
+evaluation evidence has been found;
+
+
+c) All verdicts are initially _inconclusive_ and remain so until either a _pass_
+or _fail_ verdict is assigned.
+
+
+58 The overall verdict is _pass_ if and only if all the constituent verdicts are also
+_pass_ . In the example illustrated in Figure 3, if the verdict for one evaluator
+action element is _fail_ then the verdicts for the corresponding assurance
+component, assurance class, and overall verdict are also _fail_ .
+
+## **8.3 Evaluation input task**
+
+
+**8.3.1** **Objectives**
+
+
+59 The objective of this task is to ensure that the evaluator has available the
+correct version of the evaluation evidence necessary for the evaluation and
+that it is adequately protected. Otherwise, the technical accuracy of the
+evaluation cannot be assured, nor can it be assured that the evaluation is
+being conducted in a way to provide repeatable and reproducible results.
+
+
+**8.3.2** **Application notes**
+
+
+60 The responsibility to provide all the required evaluation evidence lies with
+the sponsor. However, most of the evaluation evidence is likely to be
+produced and supplied by the developer, on behalf of the sponsor.
+
+
+61 Since the assurance requirements apply to the entire TOE, all evaluation
+evidence pertaining to all parts of the TOE is to be made available to the
+evaluator. The scope and required content of such evaluation evidence is
+independent of the level of control that the developer has over each of the
+parts of the TOE. For example, if design is required, then the TOE design
+(ADV_TDS) requirements will apply to all subsystems that are part of the
+TSF. In addition, assurance requirements that call for procedures to be in
+place (for example, CM capabilities (ALC_CMC) and Delivery
+(ALC_DEL)) will also apply to the entire TOE (including any part produced
+by another developer).
+
+
+62 It is recommended that the evaluator, in conjunction with the sponsor,
+produce an index to required evaluation evidence. This index may be a set of
+references to the documentation. This index should contain enough
+information (e.g. a brief summary of each document, or at least an explicit
+title, indication of the sections of interest) to help the evaluator to find easily
+the required evidence.
+
+
+63 It is the information contained in the evaluation evidence that is required, not
+any particular document structure. Evaluation evidence for a sub-activity
+may be provided by separate documents, or a single document may satisfy
+several of the input requirements of a sub-activity.
+
+
+April 2017 Version 3.1 Page 25 of 430
+
+
+**Evaluation process and related tasks**
+
+
+64 The evaluator requires stable and formally-issued versions of evaluation
+evidence. However, draft evaluation evidence may be provided during an
+evaluation, for example, to help an evaluator make an early, informal
+assessment, but is not used as the basis for verdicts. It may be helpful for the
+evaluator to see draft versions of particular appropriate evaluation evidence,
+such as:
+
+
+a) test documentation, to allow the evaluator to make an early
+assessment of tests and test procedures;
+
+
+b) design documents, to provide the evaluator with background for
+understanding the TOE design;
+
+
+c) source code or hardware drawings, to allow the evaluator to assess
+the application of the developer's standards.
+
+
+65 Draft evaluation evidence is more likely to be encountered where the
+evaluation of a TOE is performed concurrently with its development.
+However, it may also be encountered during the evaluation of an alreadydeveloped TOE where the developer has had to perform additional work to
+address a problem identified by the evaluator (e.g. to correct an error in
+design or implementation) or to provide evaluation evidence of security that
+is not provided in the existing documentation (e.g. in the case of a TOE not
+originally developed to meet the requirements of the CC).
+
+
+**8.3.3** **Management of evaluation evidence sub-task**
+
+
+8.3.3.1 Configuration control
+
+
+66 The evaluator _**shall perform**_ configuration control of the evaluation evidence.
+
+
+67 The CC implies that the evaluator is able to identify and locate each item of
+evaluation evidence after it has been received and is able to determine
+whether a specific version of a document is in the evaluator's possession.
+
+
+68 The evaluator _**shall protect**_ the evaluation evidence from alteration or loss
+while it is in the evaluator's possession.
+
+
+8.3.3.2 Disposal
+
+
+69 Schemes may wish to control the disposal of evaluation evidence at the
+conclusion of an evaluation. The disposal of the evaluation evidence should
+be achieved by one or more of:
+
+
+a) returning the evaluation evidence;
+
+
+b) archiving the evaluation evidence;
+
+
+c) destroying the evaluation evidence.
+
+
+Page 26 of 430 Version 3.1 April 2017
+
+
+**Evaluation process and related tasks**
+
+
+8.3.3.3 Confidentiality
+
+
+70 An evaluator may have access to sponsor and developer commerciallysensitive information (e.g. TOE design information, specialist tools), and
+may have access to nationally-sensitive information during the course of an
+evaluation. Schemes may wish to impose requirements for the evaluator to
+maintain the confidentiality of the evaluation evidence. The sponsor and
+evaluator may mutually agree to additional requirements as long as these are
+consistent with the scheme.
+
+
+71 Confidentiality requirements affect many aspects of evaluation work,
+including the receipt, handling, storage and disposal of evaluation evidence.
+
+## **8.4 Evaluation sub-activities**
+
+
+72 The evaluation sub-activities vary depending whether it is a PP or a TOE
+evaluation. Moreover, in the case of a TOE evaluation, the sub-activities
+depend upon the selected assurance requirements.
+
+## **8.5 Evaluation output task**
+
+
+**8.5.1** **Objectives**
+
+
+73 The objective of this Section is to describe the Observation Report (OR) and
+the Evaluation Technical Report (ETR). Schemes may require additional
+evaluator reports such as reports on individual units of work, or may require
+additional information to be contained in the OR and the ETR. The CEM
+does not preclude the addition of information into these reports as the CEM
+specifies only the minimum information content.
+
+
+74 Consistent reporting of evaluation results facilitates the achievement of the
+universal principle of repeatability and reproducibility of results. The
+consistency covers the type and the amount of information reported in the
+ETR and OR. ETR and OR consistency among different evaluations is the
+responsibility of the evaluation authority.
+
+
+75 The evaluator performs the two following sub-tasks in order to achieve the
+CEM requirements for the information content of reports:
+
+
+a) write OR sub-task (if needed in the context of the evaluation);
+
+
+b) write ETR sub-task.
+
+
+**8.5.2** **Management of evaluation outputs**
+
+
+76 The evaluator delivers the ETR to the evaluation authority, as well as any
+ORs as they become available. Requirements for controls on handling the
+ETR and ORs are established by the scheme which may include delivery to
+the sponsor or developer. The ETR and ORs may include sensitive or
+proprietary information and may need to be sanitised before they are given to
+the sponsor.
+
+
+April 2017 Version 3.1 Page 27 of 430
+
+
+**Evaluation process and related tasks**
+
+
+**8.5.3** **Application notes**
+
+
+77 In this version of the CEM, the requirements for the provision of evaluator
+evidence to support re-evaluation and re-use have not been explicitly stated.
+Where information for re-evaluation or re-use is required by the sponsor, the
+scheme under which the evaluation is being performed should be consulted.
+
+
+**8.5.4** **Write OR sub-task**
+
+
+78 ORs provide the evaluator with a mechanism to request a clarification (e.g.
+from the evaluation authority on the application of a requirement) or to
+identify a problem with an aspect of the evaluation.
+
+
+79 In the case of a fail verdict, the evaluator _**shall provide**_ an OR to reflect the
+evaluation result. Otherwise, the evaluator may use ORs as one way of
+expressing clarification needs.
+
+
+80 For each OR, the evaluator _**shall report**_ the following:
+
+
+a) the identifier of the PP or TOE evaluated;
+
+
+b) the evaluation task/sub-activity during which the observation was
+generated;
+
+
+c) the observation;
+
+
+d) the assessment of its severity (e.g. implies a fail verdict, holds up
+progress on the evaluation, requires a resolution prior to evaluation
+being completed);
+
+
+e) the identification of the organisation responsible for resolving the
+issue;
+
+
+f) the recommended timetable for resolution;
+
+
+g) the assessment of the impact on the evaluation of failure to resolve
+the observation.
+
+
+81 The intended audience of an OR and procedures for handling the report
+depend on the nature of the report's content and on the scheme. Schemes may
+distinguish different types of ORs or define additional types, with associated
+differences in required information and distribution (e.g. evaluation ORs to
+evaluation authorities and sponsors).
+
+
+**8.5.5** **Write ETR sub-task**
+
+
+8.5.5.1 Objectives
+
+
+82 The evaluator _**shall provide**_ an ETR to present technical justification of the
+verdicts.
+
+
+Page 28 of 430 Version 3.1 April 2017
+
+
+**Evaluation process and related tasks**
+
+
+83 The CEM defines the ETR's minimum content requirement; however,
+schemes may specify additional content and specific presentational and
+structural requirements. For instance, schemes may require that certain
+introductory material (e.g. disclaimers and copyright Chapters) be reported in
+the ETR.
+
+
+84 The reader of the ETR is assumed to be familiar with general concepts of
+information security, the CC, the CEM, evaluation approaches and IT.
+
+
+85 The ETR supports the evaluation authority to confirm that the evaluation was
+done to the required standard, but it is anticipated that the documented results
+may not provide all of the necessary information, so additional information
+specifically requested by the scheme may be necessary. This aspect is
+outside the scope of the CEM.
+
+
+8.5.5.2 ETR for a PP Evaluation
+
+
+86 This Section describes the minimum content of the ETR for a PP evaluation.
+The contents of the ETR are portrayed in Figure 4; this figure may be used as
+a guide when constructing the structural outline of the ETR document.
+
+
+**Figure 4 - ETR information content for a PP evaluation**
+
+
+8.5.5.2.1 Introduction
+
+
+April 2017 Version 3.1 Page 29 of 430
+
+
+**Evaluation process and related tasks**
+
+
+87 The evaluator _**shall report**_ evaluation scheme identifiers.
+
+
+88 Evaluation scheme identifiers (e.g. logos) are the information required to
+unambiguously identify the scheme responsible for the evaluation oversight.
+
+
+89 The evaluator _**shall report**_ ETR configuration control identifiers.
+
+
+90 The ETR configuration control identifiers contain information that identifies
+the ETR (e.g. name, date and version number).
+
+
+91 The evaluator _**shall report**_ PP configuration control identifiers.
+
+
+92 PP configuration control identifiers (e.g. name, date and version number) are
+required to identify what is being evaluated in order for the evaluation
+authority to verify that the verdicts have been assigned correctly by the
+evaluator.
+
+
+93 The evaluator _**shall report**_ the identity of the developer.
+
+
+94 The identity of the PP developer is required to identify the party responsible
+for producing the PP.
+
+
+95 The evaluator _**shall report**_ the identity of the sponsor.
+
+
+96 The identity of the sponsor is required to identify the party responsible for
+providing evaluation evidence to the evaluator.
+
+
+97 The evaluator _**shall report**_ the identity of the evaluator.
+
+
+98 The identity of the evaluator is required to identify the party performing the
+evaluation and responsible for the evaluation verdicts.
+
+
+8.5.5.2.2 Evaluation
+
+
+99 The evaluator _**shall report**_ the evaluation methods, techniques, tools and
+standards used.
+
+
+100 The evaluator references the evaluation criteria, methodology and
+interpretations used to evaluate the PP.
+
+
+101 The evaluator _**shall report**_ any constraints on the evaluation, constraints on
+the handling of evaluation results and assumptions made during the
+evaluation that have an impact on the evaluation results.
+
+
+102 The evaluator may include information in relation to legal or statutory
+aspects, organisation, confidentiality, etc.
+
+
+8.5.5.2.3 Results of the evaluation
+
+
+103 The evaluator _**shall report**_ a verdict and a supporting rationale for each
+assurance component that constitutes an APE activity, as a result of
+performing the corresponding CEM action and its constituent work units.
+
+
+Page 30 of 430 Version 3.1 April 2017
+
+
+**Evaluation process and related tasks**
+
+
+104 The rationale justifies the verdict using the CC, the CEM, any interpretations
+and the evaluation evidence examined and shows how the evaluation
+evidence does or does not meet each aspect of the criteria. It contains a
+description of the work performed, the method used, and any derivation of
+results. The rationale may provide detail to the level of a CEM work unit.
+
+
+8.5.5.2.4 Conclusions and recommendations
+
+
+105 The evaluator _**shall report**_ the conclusions of the evaluation, in particular the
+overall verdict as defined in CC Part 1 Chapter 10, Evaluation results, and
+determined by application of the verdict assignment described in 8.2.5.
+
+
+106 The evaluator provides recommendations that may be useful for the
+evaluation authority. These recommendations may include shortcomings of
+the PP discovered during the evaluation or mention of features which are
+particularly useful.
+
+
+8.5.5.2.5 List of evaluation evidence
+
+
+107 The evaluator _**shall report**_ for each item of evaluation evidence the following
+information:
+
+
+๏ญ the issuing body (e.g. the developer, the sponsor);
+
+
+๏ญ the title;
+
+
+๏ญ the unique reference (e.g. issue date and version number).
+
+
+8.5.5.2.6 List of acronyms/Glossary of terms
+
+
+108 The evaluator _**shall report**_ any acronyms or abbreviations used in the ETR.
+
+
+109 Glossary definitions already defined by the CC or CEM need not be repeated
+in the ETR.
+
+
+8.5.5.2.7 Observation reports
+
+
+110 The evaluator _**shall report**_ a complete list that uniquely identifies the ORs
+raised during the evaluation and their status.
+
+
+111 For each OR, the list should contain its identifier as well as its title or a brief
+summary of its content.
+
+
+8.5.5.3 ETR for a TOE Evaluation
+
+
+112 This Section describes the minimum content of the ETR for a TOE
+evaluation. The contents of the ETR are portrayed in Figure 5; this figure
+may be used as a guide when constructing the structural outline of the ETR
+document.
+
+
+April 2017 Version 3.1 Page 31 of 430
+
+
+**Evaluation process and related tasks**
+
+
+**Figure 5 - ETR information content for a TOE evaluation**
+
+
+8.5.5.3.1 Introduction
+
+
+113 The evaluator _**shall report**_ evaluation scheme identifiers.
+
+
+114 Evaluation scheme identifiers (e.g. logos) are the information required to
+unambiguously identify the scheme responsible for the evaluation oversight.
+
+
+115 The evaluator _**shall report**_ ETR configuration control identifiers.
+
+
+116 The ETR configuration control identifiers contain information that identifies
+the ETR (e.g. name, date and version number).
+
+
+117 The evaluator _**shall report**_ ST and TOE configuration control identifiers.
+
+
+118 ST and TOE configuration control identifiers identify what is being
+evaluated in order for the evaluation authority to verify that the verdicts have
+been assigned correctly by the evaluator.
+
+
+119 If the ST claims that the TOE conforms to the requirements of one or more
+PPs, the ETR shall report the reference of the corresponding PPs.
+
+
+Page 32 of 430 Version 3.1 April 2017
+
+
+**Evaluation process and related tasks**
+
+
+120 The PPs reference contains information that uniquely identifies the PPs (e.g.
+title, date, and version number).
+
+
+121 The evaluator _**shall report**_ the identity of the developer.
+
+
+122 The identity of the TOE developer is required to identify the party
+responsible for producing the TOE.
+
+
+123 The evaluator _**shall report**_ the identity of the sponsor.
+
+
+124 The identity of the sponsor is required to identify the party responsible for
+providing evaluation evidence to the evaluator.
+
+
+125 The evaluator _**shall report**_ the identity of the evaluator.
+
+
+126 The identity of the evaluator is required to identify the party performing the
+evaluation and responsible for the evaluation verdicts.
+
+
+8.5.5.3.2 Architectural description of the TOE
+
+
+127 The evaluator _**shall report**_ a high level description of the TOE and its major
+components based on the evaluation evidence described in the CC assurance
+family entitled TOE design (ADV_TDS), where applicable.
+
+
+128 The intent of this Section is to characterise the degree of architectural
+separation of the major components. If there is no TOE design (ADV_TDS)
+requirement in the ST, this is not applicable and is considered to be satisfied.
+
+
+8.5.5.3.3 Evaluation
+
+
+129 The evaluator _**shall report**_ the evaluation methods, techniques, tools and
+standards used.
+
+
+130 The evaluator may reference the evaluation criteria, methodology and
+interpretations used to evaluate the TOE or the devices used to perform the
+tests.
+
+
+131 The evaluator _**shall report**_ any constraints on the evaluation, constraints on
+the distribution of evaluation results and assumptions made during the
+evaluation that have an impact on the evaluation results.
+
+
+132 The evaluator may include information in relation to legal or statutory
+aspects, organisation, confidentiality, etc.
+
+
+8.5.5.3.4 Results of the evaluation
+
+
+133 For each activity on which the TOE is evaluated, the evaluator _**shall report**_ :
+
+
+๏ญ the title of the activity considered;
+
+
+April 2017 Version 3.1 Page 33 of 430
+
+
+**Evaluation process and related tasks**
+
+
+๏ญ a verdict and a supporting rationale for each assurance component
+that constitutes this activity, as a result of performing the
+corresponding CEM action and its constituent work units.
+
+
+134 The rationale justifies the verdict using the CC, the CEM, any interpretations
+and the evaluation evidence examined and shows how the evaluation
+evidence does or does not meet each aspect of the criteria. It contains a
+description of the work performed, the method used, and any derivation of
+results. The rationale may provide detail to the level of a CEM work unit.
+
+
+135 The evaluator _**shall report**_ all information specifically required by a work
+unit.
+
+
+136 For the AVA and ATE activities, work units that identify information to be
+reported in the ETR have been defined.
+
+
+8.5.5.3.5 Conclusions and recommendations
+
+
+137 The evaluator _**shall report**_ the conclusions of the evaluation, which will
+relate to whether the TOE has satisfied its associated ST, in particular the
+overall verdict as defined in CC Part 1 Chapter 10, Evaluation results, and
+determined by application of the verdict assignment described in 8.2.5.
+
+
+138 The evaluator provides recommendations that may be useful for the
+evaluation authority. These recommendations may include shortcomings of
+the IT product discovered during the evaluation or mention of features which
+are particularly useful.
+
+
+8.5.5.3.6 List of evaluation evidence
+
+
+139 The evaluator _**shall report**_ for each item of evaluation evidence the following
+information:
+
+
+๏ญ the issuing body (e.g. the developer, the sponsor);
+
+
+๏ญ the title;
+
+
+๏ญ the unique reference (e.g. issue date and version number).
+
+
+8.5.5.3.7 List of acronyms/Glossary of terms
+
+
+140 The evaluator _**shall report**_ any acronyms or abbreviations used in the ETR.
+
+
+141 Glossary definitions already defined by the CC or CEM need not be repeated
+in the ETR.
+
+
+8.5.5.3.8 Observation reports
+
+
+142 The evaluator _**shall report**_ a complete list that uniquely identifies the ORs
+raised during the evaluation and their status.
+
+
+Page 34 of 430 Version 3.1 April 2017
+
+
+**Evaluation process and related tasks**
+
+
+143 For each OR, the list should contain its identifier as well as its title or a brief
+summary of its content.
+
+
+April 2017 Version 3.1 Page 35 of 430
+
+
+**Class APE: Protection Profile evaluation**
+
+# **9 Class APE: Protection Profile evaluation**
+
+## **9.1 Introduction**
+
+
+144 This Chapter describes the evaluation of a PP. The requirements and
+methodology for PP evaluation are identical for each PP evaluation,
+regardless of the EAL (or other set of assurance requirements) that is claimed
+in the PP. The evaluation methodology in this Chapter is based on the
+requirements on the PP as specified in CC Part 3 class APE.
+
+
+145 This Chapter should be used in conjunction with Annexes A, B and C,
+Guidance for Operations in CC Part 1, as these Annexes clarify the concepts
+here and provide many examples.
+
+## **9.2 Application notes**
+
+
+**9.2.1** **Re-using the evaluation results of certified PPs**
+
+
+146 While evaluating a PP that is based on one or more certified PPs, it may be
+possible to re-use the fact that these PPs were certified. The potential for reuse of the result of a certified PP is greater if the PP under evaluation does
+not add threats, OSPs, security objectives and/or security requirements to
+those of the PP that conformance is being claimed to. If the PP under
+evaluation contains much more than the certified PP, re-use may not be
+useful at all.
+
+
+147 The evaluator is allowed to re-use the PP evaluation results by doing certain
+analyses only partially or not at all if these analyses or parts thereof were
+already done as part of the PP evaluation. While doing this, the evaluator
+should assume that the analyses in the PP were performed correctly.
+
+
+148 An example would be where the PP that conformance is being claimed to
+contains a set of security requirements, and these were determined to be
+internally consistent during its evaluation. If the PP under evaluation uses the
+exact same requirements, the consistency analysis does not have to be
+repeated during the PP evaluation. If the PP under evaluation adds one or
+more requirements, or performs operations on these requirements, the
+analysis will have to be repeated. However, it may be possible to save work
+in this consistency analysis by using the fact that the original requirements
+are internally consistent. If the original requirements are internally consistent,
+the evaluator only has to determine that:
+
+
+a) the set of all new and/or changed requirements is internally consistent,
+and
+
+
+b) the set of all new and/or changed requirements is consistent with the
+original requirements.
+
+
+149 The evaluator notes in the ETR each case where analyses are not done or
+only partially done for this reason.
+
+
+Page 36 of 430 Version 3.1 April 2017
+
+
+**Class APE: Protection Profile evaluation**
+
+## **9.3 PP introduction (APE_INT)**
+
+
+**9.3.1** **Evaluation of sub-activity (APE_INT.1)**
+
+
+9.3.1.1 Objectives
+
+
+150 The objective of this sub-activity is to determine whether the PP is correctly
+identified, and whether the PP reference and TOE overview are consistent
+with each other.
+
+
+9.3.1.2 Input
+
+
+151 The evaluation evidence for this sub-activity is:
+
+
+a) the PP.
+
+
+9.3.1.3 Action APE_INT.1.1E
+
+
+APE_INT.1.1C _**The PP introduction shall contain a PP reference and a TOE overview.**_
+
+
+APE_INT.1-1 The evaluator _**shall check**_ that the PP introduction contains a PP reference
+and a TOE overview.
+
+
+APE_INT.1.2C _**The PP reference shall uniquely identify the PP.**_
+
+
+APE_INT.1-2 The evaluator _**shall examine**_ the PP reference to determine that it uniquely
+identifies the PP.
+
+
+152 The evaluator determines that the PP reference identifies the PP itself, so that
+it may be easily distinguished from other PPs, and that it also uniquely
+identifies each version of the PP, e.g. by including a version number and/or a
+date of publication.
+
+
+153 The PP should have some referencing system that is capable of supporting
+unique references (e.g. use of numbers, letters or dates).
+
+
+APE_INT.1.3C _**The TOE overview shall summarise the usage and major security features**_
+_**of the TOE.**_
+
+
+APE_INT.1-3 The evaluator _**shall examine**_ the TOE overview to determine that it describes
+the usage and major security features of the TOE.
+
+
+154 The TOE overview should briefly (i.e. several paragraphs) describe the usage
+and major security features expected of the TOE. The TOE overview should
+enable consumers and potential TOE developers to quickly determine
+whether the PP is of interest to them.
+
+
+155 The evaluator determines that the overview is clear enough for TOE
+developers and consumers, and sufficient to give them a general
+understanding of the intended usage and major security features of the TOE.
+
+
+APE_INT.1.4C _**The TOE overview shall identify the TOE type.**_
+
+
+April 2017 Version 3.1 Page 37 of 430
+
+
+**Class APE: Protection Profile evaluation**
+
+
+APE_INT.1-4 The evaluator _**shall check**_ that the TOE overview identifies the TOE type.
+
+
+APE_INT.1.5C _**The**_ _**TOE**_ _**overview**_ _**shall**_ _**identify**_ _**any**_ _**non-TOE**_
+_**hardware/software/firmware available to the TOE.**_
+
+
+APE_INT.1-5 The evaluator _**shall examine**_ the TOE overview to determine that it identifies
+any non-TOE hardware/software/firmware available to the TOE.
+
+
+156 While some TOEs may run stand-alone, other TOEs (notably software
+TOEs) need additional hardware, software or firmware to operate. In this
+section of the PP, the PP author lists all hardware, software, and/or firmware
+that will be available for the TOE to run on.
+
+
+157 This identification should be detailed enough for potential consumers and
+TOE developers to determine whether their TOE may operate with the listed
+hardware, software and firmware.
+
+
+Page 38 of 430 Version 3.1 April 2017
+
+
+**Class APE: Protection Profile evaluation**
+
+## **9.4 Conformance claims (APE_CCL)**
+
+
+**9.4.1** **Evaluation of sub-activity (APE_CCL.1)**
+
+
+9.4.1.1 Objectives
+
+
+158 The objective of this sub-activity is to determine the validity of various
+conformance claims. These describe how the PP conforms to the CC, other
+PPs and packages.
+
+
+9.4.1.2 Input
+
+
+159 The evaluation evidence for this sub-activity is:
+
+
+a) the PP;
+
+
+b) the PP(s) that the PP claims conformance to;
+
+
+c) the package(s) that the PP claims conformance to.
+
+
+9.4.1.3 Action APE_CCL.1.1E
+
+
+APE_CCL.1.1C _**The conformance claim shall contain a CC conformance claim that**_
+_**identifies the version of the CC to which the PP claims conformance.**_
+
+
+APE_CCL.1-1 The evaluator _**shall check**_ that the conformance claim contains a CC
+conformance claim that identifies the version of the CC to which the PP
+claims conformance.
+
+
+160 The evaluator determines that the CC conformance claim identifies the
+version of the CC that was used to develop this PP. This should include the
+version number of the CC and, unless the International English version of the
+CC was used, the language of the version of the CC that was used.
+
+
+APE_CCL.1.2C _**The CC conformance claim shall describe the conformance of the PP to**_
+_**CC Part 2 as either CC Part 2 conformant or CC Part 2 extended.**_
+
+
+APE_CCL.1-2 The evaluator _**shall check**_ that the CC conformance claim states a claim of
+either CC Part 2 conformant or CC Part 2 extended for the PP.
+
+
+APE_CCL.1.3C _**The CC conformance claim shall describe the conformance of the PP to**_
+_**CC Part 3 as either CC Part 3 conformant or CC Part 3 extended.**_
+
+
+APE_CCL.1-3 The evaluator _**shall check**_ that the CC conformance claim states a claim of
+either CC Part 3 conformant or CC Part 3 extended for the PP.
+
+
+APE_CCL.1.4C _**The CC conformance claim shall be consistent with the extended**_
+_**components definition.**_
+
+
+APE_CCL.1-4 The evaluator _**shall examine**_ the CC conformance claim for CC Part 2 to
+determine that it is consistent with the extended components definition.
+
+
+April 2017 Version 3.1 Page 39 of 430
+
+
+**Class APE: Protection Profile evaluation**
+
+
+161 If the CC conformance claim contains CC Part 2 conformant, the evaluator
+determines that the extended components definition does not define
+functional components.
+
+
+162 If the CC conformance claim contains CC Part 2 extended, the evaluator
+determines that the extended components definition defines at least one
+extended functional component.
+
+
+APE_CCL.1-5 The evaluator _**shall examine**_ the CC conformance claim for CC Part 3 to
+determine that it is consistent with the extended components definition.
+
+
+163 If the CC conformance claim contains CC Part 3 conformant, the evaluator
+determines that the extended components definition does not define
+assurance components.
+
+
+164 If the CC conformance claim contains CC Part 3 extended, the evaluator
+determines that the extended components definition defines at least one
+extended assurance component.
+
+
+APE_CCL.1.5C _**The conformance claim shall identify all PPs and security requirement**_
+_**packages to which the PP claims conformance.**_
+
+
+APE_CCL.1-6 The evaluator _**shall check**_ that the conformance claim contains a PP claim
+that identifies all PPs for which the PP claims conformance.
+
+
+165 If the PP does not claim conformance to another PP, this work unit is not
+applicable and therefore considered to be satisfied.
+
+
+166 The evaluator determines that any referenced PPs are unambiguously
+identified (e.g. by title and version number, or by the identification included
+in the introduction of that PP).
+
+
+167 The evaluator is reminded that claims of partial conformance to a PP are not
+permitted.
+
+
+APE_CCL.1-7 The evaluator _**shall check**_ that the conformance claim contains a package
+claim that identifies all packages to which the PP claims conformance.
+
+
+168 If the PP does not claim conformance to a package, this work unit is not
+applicable and therefore considered to be satisfied.
+
+
+169 The evaluator determines that any referenced packages are unambiguously
+identified (e.g. by title and version number, or by the identification included
+in the introduction of that package).
+
+
+170 The evaluator is reminded that claims of partial conformance to a package
+are not permitted.
+
+
+APE_CCL.1.6C _**The conformance claim shall describe any conformance of the PP to a**_
+_**package as either package-conformant or package-augmented.**_
+
+
+Page 40 of 430 Version 3.1 April 2017
+
+
+**Class APE: Protection Profile evaluation**
+
+
+APE_CCL.1-8 The evaluator _**shall check**_ that, for each identified package, the conformance
+claim states a claim of either package-name conformant or package-name
+augmented.
+
+
+171 If the PP does not claim conformance to a package, this work unit is not
+applicable and therefore considered to be satisfied.
+
+
+172 If the package conformance claim contains package-name conformant, the
+evaluator determines that:
+
+
+a) If the package is an assurance package, then the PP contains all SARs
+included in the package, but no additional SARs.
+
+
+b) If the package is a functional package, then the PP contains all SFRs
+included in the package, but no additional SFRs.
+
+
+173 If the package conformance claim contains package-name augmented, the
+evaluator determines that:
+
+
+a) If the package is an assurance package, then the PP contains all SARs
+included in the package, and at least one additional SAR or at least
+one SAR that is hierarchical to a SAR in the package.
+
+
+b) If the package is a functional package, then the PP contains all SFRs
+included in the package, and at least one additional SFR or at least
+one SFR that is hierarchical to a SFR in the package.
+
+
+APE_CCL.1.7C _**The conformance claim rationale shall demonstrate that the TOE type is**_
+_**consistent with the TOE type in the PPs for which conformance is being**_
+_**claimed.**_
+
+
+APE_CCL.1-9 The evaluator _**shall examine**_ the conformance claim rationale to determine
+that the TOE type of the TOE is consistent with all TOE types of the PPs.
+
+
+174 If the PP does not claim conformance to another PP, this work unit is not
+applicable and therefore considered to be satisfied.
+
+
+175 The relation between the types may be simple: a firewall PP claiming
+conformance to another firewall PP, or more complex: a smart card PP
+claiming conformance to a number of other PPs at the same time: a PP for
+the integrated circuit, a PP for the smart card OS, and two PPs for two
+applications on the smart card.
+
+
+APE_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.**_
+
+
+APE_CCL.1-10 The evaluator _**shall examine**_ the conformance claim rationale to determine
+that it demonstrates that the statement of security problem definition is
+consistent, as defined by the conformance statement of the PP, with the
+
+
+April 2017 Version 3.1 Page 41 of 430
+
+
+**Class APE: Protection Profile evaluation**
+
+
+statements of security problem definition stated in the PPs to which
+conformance is being claimed.
+
+
+176 If the PP under evaluation does not claim conformance with another PP, this
+work unit is not applicable and therefore considered to be satisfied.
+
+
+177 If the PP to which conformance is being claimed does not have a statement
+of security problem definition, this work unit is not applicable and therefore
+considered to be satisfied.
+
+
+178 If strict conformance is required by the PP to which conformance is being
+claimed, no conformance claim rationale is required. Instead, the evaluator
+determines whether
+
+
+a) the threats in the PP under evaluation are a superset of or identical to
+the threats in the PP to which conformance is being claimed;
+
+
+b) the OSPs in the PP under evaluation are a superset of or identical to
+the OSPs in the PP to which conformance is being claimed;
+
+
+c) the assumptions in the PP claiming conformance are identical to the
+assumptions in the PP to which conformance is being claimed, with
+two possible exceptions described in the following two bullet points;
+
+
+๏ญ an assumption (or part of an assumption) from the PP to
+which conformance is claimed, can be omitted, if all security
+objectives for the operational environment addressing this
+assumption (or part of an assumption) are replaced by security
+objectives for the TOE;
+
+
+๏ญ an assumption can be added to the assumptions defined in the
+PP to which conformance is claimed, if a justification is given,
+why the new assumption neither mitigates a threat (or a part
+of a threat) meant to be addressed by security objectives for
+the TOE in the PP to which conformance is claimed, nor
+fulfills an OSP (or part of an OSP) meant to be addressed by
+security objectives for the TOE in the PP to which
+conformance is claimed.
+
+
+When examining a PP, which omits assumptions from another PP to which
+conformance is claimed, or adds new assumptions, the evaluator shall
+carefully determine, if the conditions given above are fulfilled. The
+following discussion gives some motivation and examples for these cases:
+
+
+๏ญ Example for omitting an assumption: A PP to which
+conformance is claimed, may contain an assumption stating
+that the operational environment prevents unauthorized
+modification or interception of data sent to an external
+interface of the TOE. This may be the case if the TOE accepts
+data in clear text and without integrity protection at this
+interface and is assumed to be located in a secure operational
+
+
+Page 42 of 430 Version 3.1 April 2017
+
+
+**Class APE: Protection Profile evaluation**
+
+
+environment, which will prevent attackers from accessing
+these data. The assumption will then be mapped in the PP, to
+which conformance is claimed, to some objective for the
+operational environment stating that the data interchanged at
+this interface are protected by adequate measures in the
+operational environment. If a PP claiming this PP, defines a
+more secure TOE, which has an additional security objective
+stating that the TOE itself protects these data, for example by
+providing a secure channel for encryption and integrity
+protection of all data transferred via this interface, the
+corresponding objective and assumption for the operational
+environment can be omitted from the PP claiming
+conformance. This is also called re-assigning of the objective,
+since the objective is re-assigned from the operational
+environment to the TOE. Note, that this TOE is still secure in
+an operational environment fulfilling the omitted assumption
+and therefore still fulfills the PP to which conformance is
+claimed.
+
+
+๏ญ Example for adding an assumption: In this example the PP to
+which conformance is claimed, is designed to specify
+requirements for a TOE of type "Firewall" and the author of
+another PP wishes to claim conformance to this PP for a TOE,
+which implements a firewall, but additionally provides the
+functionality of a virtual private network (VPN) component.
+For the VPN functionality the TOE needs cryptographic keys
+and these keys may also have to be handled securely by the
+operational environment (e. g. if symmetric keys are used to
+secure the network connection and therefore need to be
+provided in some secure way to other components in the
+network). In this case it is acceptable to add an assumption
+that the cryptographic keys used by the VPN are handled
+securely by the operational environment. This assumption
+does not address threats or OSPs of the PP to which
+conformance is claimed, and therefore fulfills the conditions
+stated above.
+
+
+๏ญ Counterexample for adding an assumption: In a variant of the
+first example a PP to which conformance is claimed, may
+already contain an objective for the TOE to provide a secure
+channel for one of its interfaces, and this objective is mapped
+to a threat of unauthorized modification or reading of the data
+on this interface. In this case it is clearly not allowed for
+another PP claiming this PP, to add an assumption for the
+operational environment, which assumes that the operational
+environment protects data on this interface against
+modification or unauthorized reading of the data. This
+assumption would reduce a threat, which is meant to be
+addressed by the TOE. Therefore a TOE fulfilling a PP with
+this added assumption would not automatically fulfill the PP
+
+
+April 2017 Version 3.1 Page 43 of 430
+
+
+**Class APE: Protection Profile evaluation**
+
+
+to which conformance is claimed, anymore and this addition
+is therefore not allowed.
+
+
+๏ญ Second counterexample for adding an assumption: In the
+example above of a TOE implementing a firewall it would not
+be admissible to add a general assumption that the TOE is
+only connected to trusted devices, because this would
+obviously remove essential threats relevant for a firewall
+(namely that there is untrusted IP traffic, which needs to be
+filtered). Therefore this addition would not be allowed.
+
+
+179 If demonstrable conformance is required by the PP to which conformance is
+being claimed, the evaluator examines the conformance claim rationale to
+determine that it demonstrates that the statement of security problem
+definition of the PP under evaluation is equivalent or more restrictive than
+the statement of security problem definition in the PP to which conformance
+is being claimed.
+
+
+180 For this, the conformance claim rationale needs to demonstrate that the
+security problem definition in the PP claiming conformance is equivalent (or
+more restrictive) than the security problem definition in the PP to which
+conformance is claimed. This means that:
+
+
+๏ญ all TOEs that would meet the security problem definition in the PP
+claiming conformance also meet the security problem definition in
+the PP to which conformance is claimed. This can also be shown
+indirectly by demonstrating that every event, which realizes a threat
+defined in the PP to which conformance is claimed, or violates an
+OSP defined in the PP to which conformance is claimed, would also
+realize a threat stated in the PP claiming conformance or violate an
+OSP defined in the PP claiming conformance. Note that fulfilling an
+OSP stated in the PP claiming conformance may avert a threat stated
+in the PP to which conformance is claimed, or that averting a threat
+stated in the PP claiming conformance may fulfill an OSP stated in
+the PP to which conformance is claimed, so threats and OSPs can
+substitute each other;
+
+
+๏ญ all operational environments that would meet the security problem
+definition in the PP to which conformance is claimed, would also
+meet the security problem definition in the PP claiming conformance
+(with one exception in the next bullet);
+
+
+๏ญ besides a set of assumptions in the PP claiming conformance needed
+to demonstrate conformance to the SPD of the PP to which
+conformance is claimed, an PP claiming conformance may specify
+further assumptions, but only if these additional assumptions are
+independent of and do not affect the security problem definition as
+defined in the PP to which conformance is claimed. More detailed,
+there are no assumptions in the PP claiming conformance that
+exclude threats to the TOE that need to be countered by the TOE
+according to the PP to which conformance is claimed. Similarly,
+
+
+Page 44 of 430 Version 3.1 April 2017
+
+
+**Class APE: Protection Profile evaluation**
+
+
+there are no assumptions in the PP claiming conformance that realize
+aspects of an OSP stated in the PP to which conformance is claimed,
+which are meant to be fulfilled by the TOE according to the PP to
+which conformance is claimed.
+
+
+APE_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.**_
+
+
+APE_CCL.1-11 The evaluator _**shall examine**_ the conformance claim rationale to determine
+that the statement of security objectives is consistent, as defined by the
+conformance statement of the PPs, with the statement of security objectives
+in the PPs.
+
+
+181 If the PP does not claim conformance to another PP, this work unit is not
+applicable and therefore considered to be satisfied.
+
+
+182 If strict conformance is required by the PP to which conformance is being
+claimed, no conformance claim rationale is required. Instead, the evaluator
+determines whether:
+
+
+๏ญ The PP under evaluation contains all security objectives for the TOE
+of the PP to which conformance is being claimed. Note that it is
+allowed for the PP under evaluation to have additional security
+objectives for the TOE;
+
+
+๏ญ The security objectives for the operational environment in the PP
+claiming conformance are identical to the security objectives for the
+operational environment in the PP to which conformance is being
+claimed, with two possible exceptions described in the following two
+bullet points;
+
+
+๏ญ a security objective for the operational environment (or part of such
+security objective) from the PP to which conformance is claimed, can
+be replaced by the same (part of the) security objective stated for the
+TOE;
+
+
+๏ญ a security objective for the operational environment can be added to
+the objectives defined in the PP to which conformance is claimed, if a
+justification is given, why the new objective neither mitigates a threat
+(or a part of a threat) meant to be addressed by security objectives for
+the TOE in the PP to which conformance is claimed, nor fulfills an
+OSP (or part of an OSP) meant to be addressed by security objectives
+for the TOE in the PP to which conformance is claimed.
+
+
+When examining a PP claiming another PP which omits security objectives
+for the operational environment from the PP to which conformance is
+claimed, or adds new security objectives for the operational environment, the
+evaluator shall carefully determine, if the conditions given above are fulfilled.
+The examples given for the case of assumptions in the preceding work unit
+are also valid here.
+
+
+April 2017 Version 3.1 Page 45 of 430
+
+
+**Class APE: Protection Profile evaluation**
+
+
+183 If demonstrable conformance is required by the PP to which conformance is
+being claimed, the evaluator examines the conformance claim rationale to
+determine that it demonstrates that the statement of security objectives of the
+PP under evaluation is equivalent or more restrictive than the statement of
+security objectives in the PP to which conformance is being claimed.
+
+
+184 For this the conformance claim rationale needs to demonstrate that the
+security objectives in the PP claiming conformance are equivalent (or more
+restrictive) than the security objectives in the PP to which conformance is
+claimed. This means that:
+
+
+๏ญ all TOEs that would meet the security objectives for the TOE in the
+PP claiming conformance also meet the security objectives for the
+TOE in the PP to which conformance is claimed;
+
+
+๏ญ all operational environments that would meet the security objectives
+for the operational environment in the PP to which conformance is
+claimed, would also meet the security objectives for the operational
+environment in the PP claiming conformance (with one exception in
+the next bullet);
+
+
+๏ญ besides a set of security objectives for the operational environment in
+the PP claiming conformance, which are used to demonstrate
+conformance to the set of security objectives defined in the PP to
+which conformance is claimed, an PP claiming conformance may
+specify further security objectives for the operational environment,
+but only if these security objectives neither affect the original set of
+security objectives for the TOE nor the security objectives for the
+operational environment as defined in the PP to which conformance
+is claimed.
+
+
+APE_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.**_
+
+
+APE_CCL.1-12 The evaluator _**shall examine**_ the PP to determine that it is consistent, as
+defined by the conformance statement of the PP, with all security
+requirements in the PPs for which conformance is being claimed.
+
+
+185 If the PP does not claim conformance to another PP, this work unit is not
+applicable and therefore considered to be satisfied.
+
+
+186 If strict conformance is required by the PP to which conformance is being
+claimed, no conformance claim rationale is required. Instead, the evaluator
+determines whether the statement of security requirements in the PP under
+evaluation is a superset of or identical to the statement of security
+requirements in the PP to which conformance is being claimed (for strict
+conformance).
+
+
+187 If demonstrable conformance is required by the PP to which conformance is
+being claimed, the evaluator examines the conformance claim rationale to
+
+
+Page 46 of 430 Version 3.1 April 2017
+
+
+**Class APE: Protection Profile evaluation**
+
+
+determine that it demonstrates that the statement of security requirements of
+the PP under evaluation is equivalent or more restrictive than the statement
+of security requirements in the PP to which conformance is being claimed.
+
+
+188 For:
+
+
+๏ญ SFRs: The conformance rationale in the PP claiming conformance
+shall demonstrate that the overall set of requirements defined by the
+SFRs in the PP claiming conformance is equivalent (or more
+restrictive) than the overall set of requirements defined by the SFRs
+in the PP to which conformance is claimed. This means that all TOEs
+that would meet the requirements defined by the set of all SFRs in the
+PP claiming conformance would also meet the requirements defined
+by the set of all SFRs in the PP to which conformance is claimed;
+
+
+๏ญ SARs: The PP claiming conformance shall contain all SARs in the
+PP to which conformance is claimed, but may claim additional SARs
+or replace SARs by hierarchically stronger SARs. The completion of
+operations in the PP claiming conformance must be consistent with
+that in the PP to which conformance is claimed; either the same
+completion will be used in the PP claiming conformance as that in the
+PP to which conformance is claimed or a completion that makes the
+SAR more restrictive (the rules of refinement apply).
+
+
+APE_CCL.1.11C _**The conformance statement shall describe the conformance required of**_
+_**any PPs/STs to the PP as strict-PP or demonstrable-PP conformance.**_
+
+
+APE_CCL.1-13 The evaluator _**shall check**_ that the PP conformance statement states a claim
+of strict-PP or demonstrable-PP conformance.
+
+
+April 2017 Version 3.1 Page 47 of 430
+
+
+**Class APE: Protection Profile evaluation**
+
+## **9.5 Security problem definition (APE_SPD)**
+
+
+**9.5.1** **Evaluation of sub-activity (APE_SPD.1)**
+
+
+9.5.1.1 Objectives
+
+
+189 The objective of this sub-activity is to determine that the security problem
+intended to be addressed by the TOE and its operational environment is
+clearly defined.
+
+
+9.5.1.2 Input
+
+
+190 The evaluation evidence for this sub-activity is:
+
+
+a) the PP.
+
+
+9.5.1.3 Action APE_SPD.1.1E
+
+
+APE_SPD.1.1C _**The security problem definition shall describe the threats.**_
+
+
+APE_SPD.1-1 The evaluator _**shall check**_ that the security problem definition describes the
+threats.
+
+
+191 If all security objectives are derived from assumptions and/or OSPs only, the
+statement of threats need not be present in the PP. In this case, this work unit
+is not applicable and therefore considered to be satisfied.
+
+
+192 The evaluator determines that the security problem definition describes the
+threats that must be countered by the TOE and/or its operational environment.
+
+
+APE_SPD.1.2C _**All threats shall be described in terms of a threat agent, an asset, and an**_
+_**adverse action.**_
+
+
+APE_SPD.1-2 The evaluator _**shall examine**_ the security problem definition to determine
+that all threats are described in terms of a threat agent, an asset, and an
+adverse action.
+
+
+193 If all security objectives are derived from assumptions and OSPs only, the
+statement of threats need not be present in the PP. In this case, this work unit
+is not applicable and therefore considered to be satisfied.
+
+
+194 Threat agents may be further described by aspects such as expertise, resource,
+opportunity, and motivation.
+
+
+APE_SPD.1.3C _**The security problem definition shall describe the OSPs.**_
+
+
+APE_SPD.1-3 The evaluator _**shall examine**_ that the security problem definition describes
+the OSPs.
+
+
+195 If all security objectives are derived from assumptions and/or threats only,
+OSPs need not be present in the PP. In this case, this work unit is not
+applicable and therefore considered to be satisfied.
+
+
+Page 48 of 430 Version 3.1 April 2017
+
+
+**Class APE: Protection Profile evaluation**
+
+
+196 The evaluator determines that OSP statements are made in terms of rules or
+guidelines that must be followed by the TOE and/or its operational
+environment.
+
+
+197 The evaluator determines that each OSP is explained and/or interpreted in
+sufficient detail to make it clearly understandable; a clear presentation of
+policy statements is necessary to permit tracing security objectives to them.
+
+
+APE_SPD.1.4C _**The security problem definition shall describe the assumptions about the**_
+_**operational environment of the TOE.**_
+
+
+APE_SPD.1-4 The evaluator _**shall examine**_ the security problem definition to determine
+that it describes the assumptions about the operational environment of the
+TOE.
+
+
+198 If there are no assumptions, this work unit is not applicable and is therefore
+considered to be satisfied.
+
+
+199 The evaluator determines that each assumption about the operational
+environment of the TOE is explained in sufficient detail to enable consumers
+to determine that their operational environment matches the assumption. If
+the assumptions are not clearly understood, the end result may be that the
+TOE is used in an operational environment in which it will not function in a
+secure manner.
+
+
+April 2017 Version 3.1 Page 49 of 430
+
+
+**Class APE: Protection Profile evaluation**
+
+## **9.6 Security objectives (APE_OBJ)**
+
+
+**9.6.1** **Evaluation of sub-activity (APE_OBJ.1)**
+
+
+9.6.1.1 Objectives
+
+
+200 The objective of this sub-activity is to determine whether the security
+objectives for the operational environment are clearly defined.
+
+
+9.6.1.2 Input
+
+
+201 The evaluation evidence for this sub-activity is:
+
+
+a) the PP.
+
+
+9.6.1.3 Action APE_OBJ.1.1E
+
+
+APE_OBJ.1.1C _**The statement of security objectives shall describe the security objectives**_
+_**for the operational environment.**_
+
+
+APE_OBJ.1-1 The evaluator _**shall check**_ that the statement of security objectives defines
+the security objectives for the operational environment.
+
+
+202 The evaluator checks that the security objectives for the operational
+environment are identified.
+
+
+**9.6.2** **Evaluation of sub-activity (APE_OBJ.2)**
+
+
+9.6.2.1 Objectives
+
+
+203 The objective of this sub-activity is to determine whether the security
+objectives adequately and completely address the security problem definition
+and that the division of this problem between the TOE and its operational
+environment is clearly defined.
+
+
+9.6.2.2 Input
+
+
+204 The evaluation evidence for this sub-activity is:
+
+
+a) the PP.
+
+
+9.6.2.3 Action APE_OBJ.2.1E
+
+
+APE_OBJ.2.1C _**The statement of security objectives shall describe the security objectives**_
+_**for the TOE and the security objectives for the operational environment.**_
+
+
+APE_OBJ.2-1 The evaluator _**shall check**_ that the statement of security objectives defines
+the security objectives for the TOE and the security objectives for the
+operational environment.
+
+
+205 The evaluator checks that both categories of security objectives are clearly
+identified and separated from the other category.
+
+
+Page 50 of 430 Version 3.1 April 2017
+
+
+**Class APE: Protection Profile evaluation**
+
+
+APE_OBJ.2.2C _**The security objectives rationale shall trace each security objective for the**_
+_**TOE back to threats countered by that security objective and OSPs**_
+_**enforced by that security objective.**_
+
+
+APE_OBJ.2-2 The evaluator _**shall check**_ that the security objectives rationale traces all
+security objectives for the TOE back to threats countered by the objectives
+and/or OSPs enforced by the objectives.
+
+
+206 Each security objective for the TOE may trace back to threats or OSPs, or a
+combination of threats and OSPs, but it must trace back to at least one threat
+or OSP.
+
+
+207 Failure to trace implies that either the security objectives rationale is
+incomplete, the security problem definition is incomplete, or the security
+objective for the TOE has no useful purpose.
+
+
+APE_OBJ.2.3C _**The security objectives rationale shall trace each security objective for the**_
+_**operational environment back to threats countered by that security**_
+_**objective, OSPs enforced by that security objective, and assumptions**_
+_**upheld by that security objective.**_
+
+
+APE_OBJ.2-3 The evaluator _**shall check**_ that the security objectives rationale traces the
+security objectives for the operational environment back to threats countered
+by that security objective, to OSPs enforced by that security objective, and to
+assumptions upheld by that security objective.
+
+
+208 Each security objective for the operational environment may trace back to
+threats, OSPs, assumptions, or a combination of threats, OSPs and/or
+assumptions, but it must trace back to at least one threat, OSP or assumption.
+
+
+209 Failure to trace implies that either the security objectives rationale is
+incomplete, the security problem definition is incomplete, or the security
+objective for the operational environment has no useful purpose.
+
+
+APE_OBJ.2.4C _**The security objectives rationale shall demonstrate that the security**_
+_**objectives counter all threats.**_
+
+
+APE_OBJ.2-4 The evaluator _**shall examine**_ the security objectives rationale to determine
+that it justifies for each threat that the security objectives are suitable to
+counter that threat.
+
+
+210 If no security objectives trace back to the threat, the evaluator action related
+to this work unit is assigned a fail verdict.
+
+
+211 The evaluator determines that the justification for a threat shows whether the
+threat is removed, diminished or mitigated.
+
+
+212 The evaluator determines that the justification for a threat demonstrates that
+the security objectives are sufficient: if all security objectives that trace back
+to the threat are achieved, the threat is removed, sufficiently diminished, or
+the effects of the threat are sufficiently mitigated.
+
+
+April 2017 Version 3.1 Page 51 of 430
+
+
+**Class APE: Protection Profile evaluation**
+
+
+213 Note that the tracings from security objectives to threats provided in the
+security objectives rationale may be part of a justification, but do not
+constitute a justification by themselves. Even in the case that a security
+objective is merely a statement reflecting the intent to prevent a particular
+threat from being realised, a justification is required, but this justification
+may be as minimal as โSecurity Objective X directly counters Threat Yโ.
+
+
+214 The evaluator also determines that each security objective that traces back to
+a threat is necessary: when the security objective is achieved it actually
+contributes to the removal, diminishing or mitigation of that threat.
+
+
+APE_OBJ.2.5C _**The security objectives rationale shall demonstrate that the security**_
+_**objectives enforce all OSPs.**_
+
+
+APE_OBJ.2-5 The evaluator _**shall examine**_ the security objectives rationale to determine
+that for each OSP it justifies that the security objectives are suitable to
+enforce that OSP.
+
+
+215 If no security objectives trace back to the OSP, the evaluator action related to
+this work unit is assigned a fail verdict.
+
+
+216 The evaluator determines that the justification for an OSP demonstrates that
+the security objectives are sufficient: if all security objectives that trace back
+to that OSP are achieved, the OSP is enforced.
+
+
+217 The evaluator also determines that each security objective that traces back to
+an OSP is necessary: when the security objective is achieved it actually
+contributes to the enforcement of the OSP.
+
+
+218 Note that the tracings from security objectives to OSPs provided in the
+security objectives rationale may be part of a justification, but do not
+constitute a justification by themselves. In the case that a security objective is
+merely a statement reflecting the intent to enforce a particular OSP, a
+justification is required, but this justification may be as minimal as โSecurity
+Objective X directly enforces OSP Yโ.
+
+
+APE_OBJ.2.6C _**The security objectives rationale shall demonstrate that the security**_
+_**objectives for the operational environment uphold all assumptions.**_
+
+
+APE_OBJ.2-6 The evaluator _**shall examine**_ the security objectives rationale to determine
+that for each assumption for the operational environment it contains an
+appropriate justification that the security objectives for the operational
+environment are suitable to uphold that assumption.
+
+
+219 If no security objectives for the operational environment trace back to the
+assumption, the evaluator action related to this work unit is assigned a fail
+verdict.
+
+
+220 The evaluator determines that the justification for an assumption about the
+operational environment of the TOE demonstrates that the security objectives
+are sufficient: if all security objectives for the operational environment that
+
+
+Page 52 of 430 Version 3.1 April 2017
+
+
+**Class APE: Protection Profile evaluation**
+
+
+trace back to that assumption are achieved, the operational environment
+upholds the assumption.
+
+
+221 The evaluator also determines that each security objective for the operational
+environment that traces back to an assumption about the operational
+environment of the TOE is necessary: when the security objective is
+achieved it actually contributes to the operational environment upholding the
+assumption.
+
+
+222 Note that the tracings from security objectives for the operational
+environment to assumptions provided in the security objectives rationale may
+be a part of a justification, but do not constitute a justification by themselves.
+Even in the case that a security objective of the operational environment is
+merely a restatement of an assumption, a justification is required, but this
+justification may be as minimal as โSecurity Objective X directly upholds
+Assumption Yโ.
+
+
+April 2017 Version 3.1 Page 53 of 430
+
+
+**Class APE: Protection Profile evaluation**
+
+## **9.7 Extended components definition (APE_ECD)**
+
+
+**9.7.1** **Evaluation of sub-activity (APE_ECD.1)**
+
+
+9.7.1.1 Objectives
+
+
+223 The objective of this sub-activity is to determine whether extended
+components have been clearly and unambiguously defined, and whether they
+are necessary, i.e. they may not be clearly expressed using existing CC Part 2
+or CC Part 3 components.
+
+
+9.7.1.2 Input
+
+
+224 The evaluation evidence for this sub-activity is:
+
+
+a) the PP.
+
+
+9.7.1.3 Action APE_ECD.1.1E
+
+
+APE_ECD.1.1C _**The statement of security requirements shall identify all extended security**_
+_**requirements.**_
+
+
+APE_ECD.1-1 The evaluator _**shall check**_ that all security requirements in the statement of
+security requirements that are not identified as extended requirements are
+present in CC Part 2 or in CC Part 3.
+
+
+APE_ECD.1.2C _**The extended components definition shall define an extended component**_
+_**for each extended security requirement.**_
+
+
+APE_ECD.1-2 The evaluator _**shall check**_ that the extended components definition defines
+an extended component for each extended security requirement.
+
+
+225 If the PP does not contain extended security requirements, this work unit is
+not applicable and therefore considered to be satisfied.
+
+
+226 A single extended component may be used to define multiple iterations of an
+extended security requirement, it is not necessary to repeat this definition for
+each iteration.
+
+
+APE_ECD.1.3C _**The extended components definition shall describe how each extended**_
+_**component is related to the existing CC components, families, and classes.**_
+
+
+APE_ECD.1-3 The evaluator _**shall examine**_ the extended components definition to
+determine that it describes how each extended component fits into the
+existing CC components, families, and classes.
+
+
+227 If the PP does not contain extended security requirements, this work unit is
+not applicable and therefore considered to be satisfied.
+
+
+228 The evaluator determines that each extended component is either:
+
+
+a) a member of an existing CC Part 2 or CC Part 3 family, or
+
+
+Page 54 of 430 Version 3.1 April 2017
+
+
+**Class APE: Protection Profile evaluation**
+
+
+b) a member of a new family defined in the PP.
+
+
+229 If the extended component is a member of an existing CC Part 2 or CC Part 3
+family, the evaluator determines that the extended components definition
+adequately describes why the extended component should be a member of
+that family and how it relates to other components of that family.
+
+
+230 If the extended component is a member of a new family defined in the PP,
+the evaluator confirms that the extended component is not appropriate for an
+existing family.
+
+
+231 If the PP defines new families, the evaluator determines that each new family
+is either:
+
+
+a) a member of an existing CC Part 2 or CC Part 3 class, or
+
+
+b) a member of a new class defined in the PP.
+
+
+232 If the family is a member of an existing CC Part 2 or CC Part 3 class, the
+evaluator determines that the extended components definition adequately
+describes why the family should be a member of that class and how it relates
+to other families in that class.
+
+
+233 If the family is a member of a new class defined in the PP, the evaluator
+confirms that the family is not appropriate for an existing class.
+
+
+APE_ECD.1-4 The evaluator _**shall examine**_ the extended components definition to
+determine that each definition of an extended component identifies all
+applicable dependencies of that component.
+
+
+234 If the PP does not contain extended security requirements, this work unit is
+not applicable and therefore considered to be satisfied.
+
+
+235 The evaluator confirms that no applicable dependencies have been
+overlooked by the PP author.
+
+
+APE_ECD.1.4C _**The extended components definition shall use the existing CC components,**_
+_**families, classes, and methodology as a model for presentation.**_
+
+
+APE_ECD.1-5 The evaluator _**shall examine**_ the extended components definition to
+determine that each extended functional component uses the existing CC Part
+2 components as a model for presentation.
+
+
+236 If the PP does not contain extended SFRs, this work unit is not applicable
+and therefore considered to be satisfied.
+
+
+237 The evaluator determines that the extended functional component is
+consistent with CC Part 2 Section 7.1.3, Component structure.
+
+
+238 If the extended functional component uses operations, the evaluator
+determines that the extended functional component is consistent with CC
+Part 1 Section 8.1, Operations.
+
+
+April 2017 Version 3.1 Page 55 of 430
+
+
+**Class APE: Protection Profile evaluation**
+
+
+239 If the extended functional component is hierarchical to an existing functional
+component, the evaluator determines that the extended functional component
+is consistent with CC Part 2 Section 7.2.1, Component changes highlighting.
+
+
+APE_ECD.1-6 The evaluator _**shall examine**_ the extended components definition to
+determine that each definition of a new functional family uses the existing
+CC functional families as a model for presentation.
+
+
+240 If the PP does not define new functional families, this work unit is not
+applicable and therefore considered to be satisfied.
+
+
+241 The evaluator determines that all new functional families are defined
+consistent with CC Part 2 Section 7.1.2, Family structure.
+
+
+APE_ECD.1-7 The evaluator _**shall examine**_ the extended components definition to
+determine that each definition of a new functional class uses the existing CC
+functional classes as a model for presentation.
+
+
+242 If the PP does not define new functional classes, this work unit is not
+applicable and therefore considered to be satisfied.
+
+
+243 The evaluator determines that all new functional classes are defined
+consistent with CC Part 2 Section 7.1.1, Class structure
+
+
+APE_ECD.1-8 The evaluator _**shall examine**_ the extended components definition to
+determine that each definition of an extended assurance component uses the
+existing CC Part 3 components as a model for presentation.
+
+
+244 If the PP does not contain extended SARs, this work unit is not applicable
+and therefore considered to be satisfied.
+
+
+245 The evaluator determines that the extended assurance component definition
+is consistent with CC Part 3 Section 7.1.3, Assurance component structure.
+
+
+246 If the extended assurance component uses operations, the evaluator
+determines that the extended assurance component is consistent with CC Part
+1 Section 8.1, Operations.
+
+
+247 If the extended assurance component is hierarchical to an existing assurance
+component, the evaluator determines that the extended assurance component
+is consistent with CC Part 3 Section 7.1.3, Assurance component structure.
+
+
+APE_ECD.1-9 The evaluator _**shall examine**_ the extended components definition to
+determine that, for each defined extended assurance component, applicable
+methodology has been provided.
+
+
+248 If the PP does not contain extended SARs, this work unit is not applicable
+and therefore considered to be satisfied.
+
+
+249 The evaluator determines that, for each evaluator action element of each
+extended SAR, one or more work units are provided and that successfully
+
+
+Page 56 of 430 Version 3.1 April 2017
+
+
+**Class APE: Protection Profile evaluation**
+
+
+performing all work units for a given evaluator action element will
+demonstrate that the element has been achieved.
+
+
+APE_ECD.1-10 The evaluator _**shall examine**_ the extended components definition to
+determine that each definition of a new assurance family uses the existing
+CC assurance families as a model for presentation.
+
+
+250 If the PP does not define new assurance families, this work unit is not
+applicable and therefore considered to be satisfied.
+
+
+251 The evaluator determines that all new assurance families are defined
+consistent with CC Part 3 Section 7.1.2, Assurance family structure.
+
+
+APE_ECD.1-11 The evaluator _**shall examine**_ the extended components definition to
+determine that each definition of a new assurance class uses the existing CC
+assurance classes as a model for presentation.
+
+
+252 If the PP does not define new assurance classes, this work unit is not
+applicable and therefore considered to be satisfied.
+
+
+253 The evaluator determines that all new assurance classes are defined
+consistent with CC Part 3 Section 7.1.1, Assurance class structure.
+
+
+APE_ECD.1.5C _**The extended components shall consist of measurable and objective**_
+_**elements such that conformance or nonconformance to these elements can**_
+_**be demonstrated.**_
+
+
+APE_ECD.1-12 The evaluator _**shall examine**_ the extended components definition to
+determine that each element in each extended component is measurable and
+states objective evaluation requirements, such that conformance or
+nonconformance can be demonstrated.
+
+
+254 If the PP does not contain extended security requirements, this work unit is
+not applicable and therefore considered to be satisfied.
+
+
+255 The evaluator determines that elements of extended functional components
+are stated in such a way that they are testable, and traceable through the
+appropriate TSF representations.
+
+
+256 The evaluator also determines that elements of extended assurance
+components avoid the need for subjective evaluator judgement.
+
+
+257 The evaluator is reminded that whilst being measurable and objective is
+appropriate for all evaluation criteria, it is acknowledged that no formal
+method exists to prove such properties. Therefore the existing CC functional
+and assurance components are to be used as a model for determining what
+constitutes conformance to this requirement.
+
+
+April 2017 Version 3.1 Page 57 of 430
+
+
+**Class APE: Protection Profile evaluation**
+
+
+9.7.1.4 Action APE_ECD.1.2E
+
+
+APE_ECD.1-13 The evaluator _**shall examine**_ the extended components definition to
+determine that each extended component may not be clearly expressed using
+existing components.
+
+
+258 If the PP does not contain extended security requirements, this work unit is
+not applicable and therefore considered to be satisfied.
+
+
+259 The evaluator should take components from CC Part 2 and CC Part 3, other
+extended components that have been defined in the PP, combinations of
+these components, and possible operations on these components into account
+when making this determination.
+
+
+260 The evaluator is reminded that the role of this work unit is to preclude
+unnecessary duplication of components, that is, components that may be
+clearly expressed by using other components. The evaluator should not
+undertake an exhaustive search of all possible combinations of components
+including operations in an attempt to find a way to express the extended
+component by using existing components.
+
+
+Page 58 of 430 Version 3.1 April 2017
+
+
+**Class APE: Protection Profile evaluation**
+
+## **9.8 Security requirements (APE_REQ)**
+
+
+**9.8.1** **Evaluation of sub-activity (APE_REQ.1)**
+
+
+9.8.1.1 Objectives
+
+
+261 The objective of this sub-activity is to determine whether the SFRs and
+SARs are clear, unambiguous and well-defined and whether they are
+internally consistent.
+
+
+9.8.1.2 Input
+
+
+262 The evaluation evidence for this sub-activity is:
+
+
+a) the PP.
+
+
+9.8.1.3 Action APE_REQ.1.1E
+
+
+APE_REQ.1.1C _**The statement of security requirements shall describe the SFRs and the**_
+_**SARs.**_
+
+
+APE_REQ.1-1 The evaluator _**shall check**_ that the statement of security requirements
+describes the SFRs.
+
+
+263 The evaluator determines that each SFR is identified by one of the following
+means:
+
+
+a) by reference to an individual component in CC Part 2;
+
+
+b) by reference to an extended component in the extended components
+definition of the PP;
+
+
+c) by reference to a PP that the PP claims to be conformant with;
+
+
+d) by reference to a security requirements package that the PP claims to
+be conformant with;
+
+
+e) by reproduction in the PP.
+
+
+264 It is not required to use the same means of identification for all SFRs.
+
+
+APE_REQ.1-2 The evaluator _**shall check**_ that the statement of security requirements
+describes the SARs.
+
+
+265 The evaluator determines that each SAR is identified by one of the following
+means:
+
+
+a) by reference to an individual component in CC Part 3;
+
+
+b) by reference to an extended component in the extended components
+definition of the PP;
+
+
+c) by reference to a PP that the PP claims to be conformant with;
+
+
+April 2017 Version 3.1 Page 59 of 430
+
+
+**Class APE: Protection Profile evaluation**
+
+
+d) by reference to a security requirements package that the PP claims to
+be conformant with;
+
+
+e) by reproduction in the PP.
+
+
+266 It is not required to use the same means of identification for all SARs.
+
+
+APE_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.**_
+
+
+APE_REQ.1-3 The evaluator _**shall examine**_ the PP to determine that all subjects, objects,
+operations, security attributes, external entities and other terms that are used
+in the SFRs and the SARs are defined.
+
+
+267 The evaluator determines that the PP defines all:
+
+
+๏ญ (types of) subjects and objects that are used in the SFRs;
+
+
+๏ญ (types of) security attributes of subjects, users, objects, information,
+sessions and/or resources, possible values that these attributes may
+take and any relations between these values (e.g. top_secret is
+โhigherโ than secret);
+
+
+๏ญ (types of) operations that are used in the SFRs, including the effects
+of these operations;
+
+
+๏ญ (types of) external entities in the SFRs;
+
+
+๏ญ other terms that are introduced in the SFRs and/or SARs by
+completing operations, if these terms are not immediately clear, or
+are used outside their dictionary definition.
+
+
+268 The goal of this work unit is to ensure that the SFRs and SARs are welldefined and that no misunderstanding may occur due to the introduction of
+vague terms. This work unit should not be taken into extremes, by forcing
+the PP writer to define every single word. The general audience of a set of
+security requirements should be assumed to have a reasonable knowledge of
+IT, security and Common Criteria.
+
+
+269 All of the above may be presented in groups, classes, roles, types or other
+groupings or characterisations that allow easy understanding.
+
+
+270 The evaluator is reminded that these lists and definitions do not have to be
+part of the statement of security requirements, but may be placed (in part or
+in whole) in different sections. This may be especially applicable if the same
+terms are used in the rest of the PP.
+
+
+APE_REQ.1.3C _**The statement of security requirements shall identify all operations on the**_
+_**security requirements.**_
+
+
+APE_REQ.1-4 The evaluator _**shall check**_ that the statement of security requirements
+identifies all operations on the security requirements.
+
+
+Page 60 of 430 Version 3.1 April 2017
+
+
+**Class APE: Protection Profile evaluation**
+
+
+271 The evaluator determines that all operations are identified in each SFR or
+SAR where such an operation is used. This includes both completed
+operations and uncompleted operations. Identification may be achieved by
+typographical distinctions, or by explicit identification in the surrounding
+text, or by any other distinctive means.
+
+
+APE_REQ.1.4C _**All operations shall be performed correctly.**_
+
+
+APE_REQ.1-5 The evaluator _**shall examine**_ the statement of security requirements to
+determine that all assignment operations are performed correctly.
+
+
+272 Guidance on the correct performance of operations may be found in CC Part
+1 Annex C, Guidance for Operations.
+
+
+APE_REQ.1-6 The evaluator _**shall examine**_ the statement of security requirements to
+determine that all iteration operations are performed correctly.
+
+
+273 Guidance on the correct performance of operations may be found in CC Part
+1 Annex C, Guidance for Operations.
+
+
+APE_REQ.1-7 The evaluator _**shall examine**_ the statement of security requirements to
+determine that all selection operations are performed correctly.
+
+
+274 Guidance on the correct performance of operations may be found in CC Part
+1 Annex C, Guidance for Operations.
+
+
+APE_REQ.1-8 The evaluator _**shall examine**_ the statement of security requirements to
+determine that all refinement operations are performed correctly.
+
+
+275 Guidance on the correct performance of operations may be found in CC Part
+1 Annex C, Guidance for Operations.
+
+
+APE_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.**_
+
+
+APE_REQ.1-9 The evaluator _**shall examine**_ the statement of security requirements to
+determine that each dependency of the security requirements is either
+satisfied, or that the security requirements rationale justifies the dependency
+not being satisfied.
+
+
+276 A dependency is satisfied by the inclusion of the relevant component (or one
+that is hierarchical to it) within the statement of security requirements. The
+component used to satisfy the dependency should, if necessary, be modified
+by operations to ensure that it actually satisfies that dependency.
+
+
+277 A justification that a dependency is not met should address either:
+
+
+a) why the dependency is not necessary or useful, in which case no
+further information is required; or
+
+
+April 2017 Version 3.1 Page 61 of 430
+
+
+**Class APE: Protection Profile evaluation**
+
+
+b) that the dependency has been addressed by the operational
+environment of the TOE, in which case the justification should
+describe how the security objectives for the operational environment
+address this dependency.
+
+
+APE_REQ.1.6C _**The statement of security requirements shall be internally consistent.**_
+
+
+APE_REQ.1-10 The evaluator _**shall examine**_ the statement of security requirements to
+determine that it is internally consistent.
+
+
+278 The evaluator determines that the combined set of all SFRs and SARs is
+internally consistent.
+
+
+279 The evaluator determines that on all occasions where different security
+requirements apply to the same types of developer evidence, events,
+operations, data, tests to be performed etc. or to โall objectsโ, โall subjectsโ
+etc., that these requirements do not conflict.
+
+
+280 Some possible conflicts are:
+
+
+a) an extended SAR specifying that the design of a certain
+cryptographic algorithm is to be kept secret, and another extended
+SAR specifying an open source review;
+
+
+b) FAU_GEN.1 Audit data generation specifying that subject identity is
+to be logged, FDP_ACC.1 Subset access control specifying who has
+access to these logs, and FPR_UNO.1 Unobservability specifying
+that some actions of subjects should be unobservable to other subjects.
+If the subject that should not be able to see an activity may access
+logs of this activity, these SFRs conflict;
+
+
+c) FDP_RIP.1 Subset residual information protection specifying
+deletion of information no longer needed, and FDP_ROL.1 Basic
+rollback specifying that a TOE may return to a previous state. If the
+information that is needed for the rollback to the previous state has
+been deleted, these requirements conflict;
+
+
+d) Multiple iterations of FDP_ACC.1 Subset access control especially
+where some iterations cover the same subjects, objects, or operations.
+If one access control SFR allows a subject to perform an operation on
+an object, while another access control SFR does not allow this, these
+requirements conflict.
+
+
+**9.8.2** **Evaluation of sub-activity (APE_REQ.2)**
+
+
+9.8.2.1 Objectives
+
+
+281 The objective of this sub-activity is to determine whether the SFRs and
+SARs are clear, unambiguous and well-defined, whether they are internally
+consistent, and whether the SFRs meet the security objectives of the TOE.
+
+
+Page 62 of 430 Version 3.1 April 2017
+
+
+**Class APE: Protection Profile evaluation**
+
+
+9.8.2.2 Input
+
+
+282 The evaluation evidence for this sub-activity is:
+
+
+a) the PP.
+
+
+9.8.2.3 Action APE_REQ.2.1E
+
+
+APE_REQ.2.1C _**The statement of security requirements shall describe the SFRs and the**_
+_**SARs.**_
+
+
+APE_REQ.2-1 The evaluator _**shall check**_ that the statement of security requirements
+describes the SFRs.
+
+
+283 The evaluator determines that each SFR is identified by one of the following
+means:
+
+
+a) by reference to an individual component in CC Part 2;
+
+
+b) by reference to an extended component in the extended components
+definition of the PP;
+
+
+c) by reference to an individual component in a PP that the PP claims to
+be conformant with;
+
+
+d) by reference to an individual component in a security requirements
+package that the PP claims to be conformant with;
+
+
+e) by reproduction in the PP.
+
+
+284 It is not required to use the same means of identification for all SFRs.
+
+
+APE_REQ.2-2 The evaluator _**shall check**_ that the statement of security requirements
+describes the SARs.
+
+
+285 The evaluator determines that each SAR is identified by one of the following
+means:
+
+
+a) by reference to an individual component in CC Part 3;
+
+
+b) by reference to an extended component in the extended components
+definition of the PP;
+
+
+c) by reference to an individual component in a PP that the PP claims to
+be conformant with;
+
+
+d) by reference to an individual component in a security requirements
+package that the PP claims to be conformant with;
+
+
+e) by reproduction in the PP.
+
+
+286 It is not required to use the same means of identification for all SARs.
+
+
+April 2017 Version 3.1 Page 63 of 430
+
+
+**Class APE: Protection Profile evaluation**
+
+
+APE_REQ.2.2C _**All subjects, objects, operations, security attributes, external entities and**_
+_**other terms that are used in the SFRs and the SARs shall be defined.**_
+
+
+APE_REQ.2-3 The evaluator _**shall examine**_ the PP to determine that all subjects, objects,
+operations, security attributes, external entities and other terms that are used
+in the SFRs and the SARs are defined.
+
+
+287 The evaluator determines that the PP defines all:
+
+
+๏ญ (types of) subjects and objects that are used in the SFRs;
+
+
+๏ญ (types of) security attributes of subjects, users, objects, information,
+sessions and/or resources, possible values that these attributes may
+take and any relations between these values (e.g. top_secret is
+โhigherโ than secret);
+
+
+๏ญ (types of) operations that are used in the SFRs, including the effects
+of these operations;
+
+
+๏ญ (types of) external entities in the SFRs;
+
+
+๏ญ other terms that are introduced in the SFRs and/or SARs by
+completing operations, if these terms are not immediately clear, or
+are used outside their dictionary definition.
+
+
+288 The goal of this work unit is to ensure that the SFRs and SARs are welldefined and that no misunderstanding may occur due to the introduction of
+vague terms. This work unit should not be taken into extremes, by forcing
+the PP writer to define every single word. The general audience of a set of
+security requirements should be assumed to have a reasonable knowledge of
+IT, security and Common Criteria.
+
+
+289 All of the above may be presented in groups, classes, roles, types or other
+groupings or characterisations that allow easy understanding.
+
+
+290 The evaluator is reminded that these lists and definitions do not have to be
+part of the statement of security requirements, but may be placed (in part or
+in whole) in different sections. This may be especially applicable if the same
+terms are used in the rest of the PP.
+
+
+APE_REQ.2.3C _**The statement of security requirements shall identify all operations on the**_
+_**security requirements.**_
+
+
+APE_REQ.2-4 The evaluator _**shall check**_ that the statement of security requirements
+identifies all operations on the security requirements.
+
+
+291 The evaluator determines that all operations are identified in each SFR or
+SAR where such an operation is used. This includes both completed
+operations and uncompleted operations. Identification may be achieved by
+typographical distinctions, or by explicit identification in the surrounding
+text, or by any other distinctive means.
+
+
+Page 64 of 430 Version 3.1 April 2017
+
+
+**Class APE: Protection Profile evaluation**
+
+
+APE_REQ.2.4C _**All operations shall be performed correctly.**_
+
+
+APE_REQ.2-5 The evaluator _**shall examine**_ the statement of security requirements to
+determine that all assignment operations are performed correctly.
+
+
+292 Guidance on the correct performance of operations may be found in CC Part
+1 Annex C, Guidance for Operations.
+
+
+APE_REQ.2-6 The evaluator _**shall examine**_ the statement of security requirements to
+determine that all iteration operations are performed correctly.
+
+
+293 Guidance on the correct performance of operations may be found in CC Part
+1 Annex C, Guidance for Operations.
+
+
+APE_REQ.2-7 The evaluator _**shall examine**_ the statement of security requirements to
+determine that all selection operations are performed correctly.
+
+
+294 Guidance on the correct performance of operations may be found in CC Part
+1 Annex C, Guidance for Operations.
+
+
+APE_REQ.2-8 The evaluator _**shall examine**_ the statement of security requirements to
+determine that all refinement operations are performed correctly.
+
+
+295 Guidance on the correct performance of operations may be found in CC Part
+1 Annex C, Guidance for Operations.
+
+
+APE_REQ.2.5C _**Each dependency of the security requirements shall either be satisfied, or**_
+_**the security requirements rationale shall justify the dependency not being**_
+_**satisfied.**_
+
+
+APE_REQ.2-9 The evaluator _**shall examine**_ the statement of security requirements to
+determine that each dependency of the security requirements is either
+satisfied, or that the security requirements rationale justifies the dependency
+not being satisfied.
+
+
+296 A dependency is satisfied by the inclusion of the relevant component (or one
+that is hierarchical to it) within the statement of security requirements. The
+component used to satisfy the dependency should, if necessary, be modified
+by operations to ensure that it actually satisfies that dependency.
+
+
+297 A justification that a dependency is not met should address either:
+
+
+a) why the dependency is not necessary or useful, in which case no
+further information is required; or
+
+
+b) that the dependency has been addressed by the operational
+environment of the TOE, in which case the justification should
+describe how the security objectives for the operational environment
+address this dependency.
+
+
+APE_REQ.2.6C _**The security requirements rationale shall trace each SFR back to the**_
+_**security objectives for the TOE.**_
+
+
+April 2017 Version 3.1 Page 65 of 430
+
+
+**Class APE: Protection Profile evaluation**
+
+
+APE_REQ.2-10 The evaluator _**shall check**_ that the security requirements rationale traces each
+SFR back to the security objectives for the TOE.
+
+
+298 The evaluator determines that each SFR is traced back to at least one security
+objective for the TOE.
+
+
+299 Failure to trace implies that either the security requirements rationale is
+incomplete, the security objectives for the TOE are incomplete, or the SFR
+has no useful purpose.
+
+
+APE_REQ.2.7C _**The security requirements rationale shall demonstrate that the SFRs meet**_
+_**all security objectives for the TOE.**_
+
+
+APE_REQ.2-11 The evaluator _**shall examine**_ the security requirements rationale to determine
+that for each security objective for the TOE it justifies that the SFRs are
+suitable to meet that security objective for the TOE.
+
+
+300 If no SFRs trace back to the security objective for the TOE, the evaluator
+action related to this work unit is assigned a fail verdict.
+
+
+301 The evaluator determines that the justification for a security objective for the
+TOE demonstrates that the SFRs are sufficient: if all SFRs that trace back to
+the objective are satisfied, the security objective for the TOE is achieved.
+
+
+302 If the SFRs that trace back to a security objective for the TOE have any
+uncompleted assignments, or uncompleted or restricted selections, the
+evaluator determines that for every conceivable completion or combination
+of completions of these operations, the security objective is still met.
+
+
+303 The evaluator also determines that each SFR that traces back to a security
+objective for the TOE is necessary: when the SFR is satisfied, it actually
+contributes to achieving the security objective.
+
+
+304 Note that the tracings from SFRs to security objectives for the TOE provided
+in the security requirements rationale may be a part of the justification, but
+do not constitute a justification by themselves.
+
+
+APE_REQ.2.8C _**The security requirements rationale shall explain why the SARs were**_
+_**chosen.**_
+
+
+APE_REQ.2-12 The evaluator _**shall check**_ that the security requirements rationale explains
+why the SARs were chosen.
+
+
+305 The evaluator is reminded that any explanation is correct, as long as it is
+coherent and neither the SARs nor the explanation have obvious
+inconsistencies with the remainder of the PP.
+
+
+306 An example of an obvious inconsistency between the SARs and the
+remainder of the PP would be to have threat agents that are very capable, but
+an AVA_VAN SAR that does not protect against these threat agents.
+
+
+APE_REQ.2.9C _**The statement of security requirements shall be internally consistent.**_
+
+
+Page 66 of 430 Version 3.1 April 2017
+
+
+**Class APE: Protection Profile evaluation**
+
+
+APE_REQ.2-13 The evaluator _**shall examine**_ the statement of security requirements to
+determine that it is internally consistent.
+
+
+307 The evaluator determines that the combined set of all SFRs and SARs is
+internally consistent.
+
+
+308 The evaluator determines that on all occasions where different security
+requirements apply to the same types of developer evidence, events,
+operations, data, tests to be performed etc. or to โall objectsโ, โall subjectsโ
+etc., that these requirements do not conflict.
+
+
+309 Some possible conflicts are:
+
+
+a) an extended SAR specifying that the design of a certain
+cryptographic algorithm is to be kept secret, and another extended
+SAR specifying an open source review;
+
+
+b) FAU_GEN.1 Audit data generation specifying that subject identity is
+to be logged, FDP_ACC.1 Subset access control specifying who has
+access to these logs, and FPR_UNO.1 Unobservability specifying
+that some actions of subjects should be unobservable to other subjects.
+If the subject that should not be able to see an activity may access
+logs of this activity, these SFRs conflict;
+
+
+c) FDP_RIP.1 Subset residual information protection specifying
+deletion of information no longer needed, and FDP_ROL.1 Basic
+rollback specifying that a TOE may return to a previous state. If the
+information that is needed for the rollback to the previous state has
+been deleted, these requirements conflict;
+
+
+d) Multiple iterations of FDP_ACC.1 Subset access control especially
+where some iterations cover the same subjects, objects, or operations.
+If one access control SFR allows a subject to perform an operation on
+an object, while another access control SFR does not allow this, these
+requirements conflict.
+
+
+April 2017 Version 3.1 Page 67 of 430
+
+
+**Class ACE: Protection Profile Configuration evaluation**
+
+# **10 Class ACE: Protection Profile** **Configuration evaluation**
+
+## **10.1 Introduction**
+
+
+310 All Base-PP(s) referenced in the PP-Module must be evaluated before the
+evaluation of a PP-Configuration.
+
+
+311 One possibility for evaluating a PP-Configuration is to flatten all the
+components of the PP(s) and PP-Modules composing the PP-Configuration
+and evaluating the resulting PP as a standard PP.
+
+
+312 Another possibility for evaluation of a PP-Configuration composed of
+several PP-Modules proceeds PP-Module by PP-Module. Considering a PPConfiguration composed of the Protection Profiles Pi and the PP-Modules Mj,
+evaluation of the PP-Configuration proceeds with the following steps,
+illustrated in Figure 6:
+
+
+a) first evaluating independently all Protection Profiles Pi;
+
+
+b) evaluating the PP-Configuration C1 composed of the PP-Module M1
+with the Protection Profiles Pi;
+
+
+c) evaluating the PP-Configuration Ci+1 composed of the PP-Module
+Mi+1 with the PP-Configuration Ci considered as a standard PP (cf.
+Section B.13 in CC Part 1);
+
+
+d) iterating the step 3 for all the PP-Modules.
+
+
+313 Steps 2 and 3 are themselves performed in two steps:
+
+
+a) Evaluation of the PP-Module with its Base-PP(s) (Evaluation of subactivity (ACE_MCO.1))
+
+
+b) Extension of the evaluation (consistency assessment) to the other
+elements of the PP-Configuration (Evaluation of sub-activity
+(ACE_CCO.1))
+
+
+Page 68 of 430 Version 3.1 April 2017
+
+
+**Class ACE: Protection Profile Configuration evaluation**
+
+
+**Figure 6 - Evaluation of a PP-Configuration**
+
+
+314 The ACE evaluation methodology is based on APE's. The common parts are
+not duplicated in this document but referred to.
+
+
+April 2017 Version 3.1 Page 69 of 430
+
+
+**Class ACE: Protection Profile Configuration evaluation**
+
+## **10.2 PP-Module introduction (ACE_INT)**
+
+
+**10.2.1** **Evaluation of sub-activity (ACE_INT.1)**
+
+
+10.2.1.1 Objectives
+
+
+315 The objective of this sub-activity is to determine whether the PP-Module is
+correctly identified, and whether the Base-PP(s) and TOE overview are
+consistent with each other.
+
+
+10.2.1.2 Input
+
+
+316 The evaluation evidence for this sub-activity is:
+
+
+a) the PP-Module;
+
+
+b) its Base-PP(s)
+
+
+10.2.1.3 Application notes
+
+
+317 _All actions of APE_INT.1.1E hold._
+
+
+10.2.1.4 Action ACE_INT.1.1E
+
+
+ACE_INT.1.1C _**The PP-Module introduction shall uniquely identify all the Base-PPs on**_
+_**which the PP-Module relies, including their logical structuring and**_
+_**relationship to the PP-Module according to CC Part 1, section B.14.3.2.**_
+
+
+ACE_INT.1-1 The evaluator _**shall check**_ that the PP-Module introduction identifies the
+Base-PP(s) on which the PP-Module relies.
+
+
+ACE_INT.1.2C _**The TOE overview shall identify the differences introduced by the PP-**_
+_**Module with respect to the TOE overview of its Base-PP(s).**_
+
+
+ACE_INT.1-2 The evaluator _**shall check**_ that the TOE overview identifies the differences
+introduced by the PP-Module with respect to the TOE overview of its BasePP(s).
+
+
+Page 70 of 430 Version 3.1 April 2017
+
+
+**Class ACE: Protection Profile Configuration evaluation**
+
+## **10.3 PP-Module conformance claims (ACE_CCL)**
+
+
+**10.3.1** **Evaluation of sub-activity (ACE_CCL.1)**
+
+
+10.3.1.1 Objectives
+
+
+318 The objective of this sub-activity is to determine the validity of various
+conformance claims. These describe how the PP-Module conforms to the CC
+Part 2 and SFR packages.
+
+
+10.3.1.2 Input
+
+
+319 The evaluation evidence for this sub-activity is:
+
+
+a) the PP-Module;
+
+
+b) the SFR package(s) that the PP claims conformance to.
+
+
+10.3.1.3 Action ACE_CCL.1.1E
+
+
+ACE_CCL.1.1C _**The conformance claim shall contain a CC conformance claim that**_
+_**identifies the version of the CC to which the PP-Module claims**_
+_**conformance.**_
+
+
+ACE_CCL.1-1 The evaluator _**shall check**_ that the conformance claim contains a CC
+conformance claim that identifies the version of the CC to which the PPModule claims conformance.
+
+
+320 The evaluator determines that the CC conformance claim identifies the
+version of the CC that was used to develop this PP-Module. This should
+include the version number of the CC and, unless the International English
+version of the CC was used, the language of the version of the CC that was
+used.
+
+
+ACE_CCL.1.2C _**The CC conformance claim shall describe the conformance of the PP-**_
+_**Module to CC Part 2 as either CC Part 2 conformant or CC Part 2**_
+_**extended.**_
+
+
+ACE_CCL.1-2 The evaluator _**shall check**_ that the CC conformance claim states a claim of
+either CC Part 2 conformant or CC Part 2 extended for the PP-Module.
+
+
+ACE_CCL.1.3C _**The conformance claim shall identify all security functional requirement**_
+_**packages to which the PP-Module claims conformance**_
+
+
+ACE_CCL.1-3 The evaluator _**shall check**_ that the conformance claim contains a package
+claim that identifies all security functional requirement packages to which
+the PP-Module claims conformance.
+
+
+321 If the PP-Module does not claim conformance to a security functional
+requirement package, this work unit is not applicable and therefore
+considered to be satisfied.
+
+
+April 2017 Version 3.1 Page 71 of 430
+
+
+**Class ACE: Protection Profile Configuration evaluation**
+
+
+322 The evaluator determines that any referenced security functional requirement
+packages are unambiguously identified (e.g. by title and version number, or
+by the identification included in the introduction of that security functional
+requirement package).
+
+
+323 The evaluator is reminded that claims of partial conformance to a security
+functional requirement package are not permitted.
+
+
+ACE_CCL.1.4C _**The CC conformance claim shall be consistent with the extended**_
+_**components definition.**_
+
+
+ACE_CCL.1-4 The evaluator _**shall examine**_ the CC conformance claim for CC Part 2 to
+determine that it is consistent with the extended components definition.
+
+
+324 If the CC conformance claim contains CC Part 2 conformant, the evaluator
+determines that the extended components definition does not define
+functional components.
+
+
+325 If the CC conformance claim contains CC Part 2 extended, the evaluator
+determines that the extended components definition defines at least one
+extended functional component.
+
+
+Page 72 of 430 Version 3.1 April 2017
+
+
+**Class ACE: Protection Profile Configuration evaluation**
+
+## **10.4 PP-Module Security problem definition (ACE_SPD)**
+
+
+**10.4.1** **Evaluation of sub-activity (ACE_SPD.1)**
+
+
+10.4.1.1 Application notes
+
+
+326 _All actions of APE_SPD.1.1E hold._
+
+
+April 2017 Version 3.1 Page 73 of 430
+
+
+**Class ACE: Protection Profile Configuration evaluation**
+
+## **10.5 PP-Module Security objectives (ACE_OBJ)**
+
+
+**10.5.1** **Evaluation of sub-activity (ACE_OBJ.1)**
+
+
+10.5.1.1 Application notes
+
+
+327 _All actions of APE_OBJ.2.1E hold._
+
+
+Page 74 of 430 Version 3.1 April 2017
+
+
+**Class ACE: Protection Profile Configuration evaluation**
+
+## **10.6 PP-Module extended components definition (ACE_ECD)**
+
+
+**10.6.1** **Evaluation of sub-activity (ACE_ECD.1)**
+
+
+10.6.1.1 Application notes
+
+
+328 _All actions of APE_ECD.1.1E hold._
+
+
+April 2017 Version 3.1 Page 75 of 430
+
+
+**Class ACE: Protection Profile Configuration evaluation**
+
+## **10.7 PP-Module security requirements (ACE_REQ)**
+
+
+**10.7.1** **Evaluation of sub-activity (ACE_REQ.1)**
+
+
+10.7.1.1 Application notes
+
+
+329 _All actions of APE_REQ.2.1E hold without considering the SAR part which_
+_is empty in PP-Modules._
+
+
+Page 76 of 430 Version 3.1 April 2017
+
+
+**Class ACE: Protection Profile Configuration evaluation**
+
+## **10.8 PP-Module consistency (ACE_MCO)**
+
+
+**10.8.1** **Evaluation of sub-activity (ACE_MCO.1)**
+
+
+10.8.1.1 Objectives
+
+
+330 The objective of this sub-activity is to determine the consistency of the PPModule regarding its Base-PP(s).
+
+
+10.8.1.2 Input
+
+
+331 The evaluation evidence for this sub-activity is:
+
+
+a) the PP-Module;
+
+
+b) its Base-PP(s).
+
+
+10.8.1.3 Action ACE_MCO.1.1E
+
+
+ACE_MCO.1.1C _**The consistency rationale shall demonstrate that the TOE type of the PP-**_
+_**Module is consistent with the TOE type(s) in the Base-PPs identified in the**_
+_**PP-Module introduction.**_
+
+
+ACE_MCO.1-1 The evaluator _**shall examine**_ the consistency rationale to determine that the
+TOE type of the PP-Module is consistent with all the TOE types of the BasePP(s).
+
+
+332 The relation between the types may be simple: a PP-Module may consider a
+TOE that provides additional security functionality regarding, or more
+complex: a TOE that provides a given security functionality in a specific way.
+
+
+ACE_MCO.1.2C _**The consistency rationale shall demonstrate that the statement of the**_
+_**security problem definition is consistent with the statement of the security**_
+_**problem definition in the Base-PPs identified in the PP-Module**_
+_**introduction.**_
+
+
+ACE_MCO.1-2 The evaluator _**shall examine**_ the PP-Module consistency rationale to
+determine that it demonstrates that the statement of security problem
+definition of the PP-Module is consistent with the statements of security
+problem definition stated in its Base-PPs.
+
+
+333 In particular, the evaluator examines the consistency rationale to determine
+that:
+
+
+a) the statements of threats, assumptions and OSPs in the PP-Module do
+not contradict those from the Base-PP(s).
+
+
+b) the statement of assumptions in the PP-Module addresses aspects out
+of scope of the Base-PP, in which case, the addition of elements is
+allowed.
+
+
+April 2017 Version 3.1 Page 77 of 430
+
+
+**Class ACE: Protection Profile Configuration evaluation**
+
+
+ACE_MCO.1.3C _**The consistency rationale shall demonstrate that the statement of security**_
+_**objectives is consistent with the statement of security objectives in the**_
+_**Base-PPs identified in the PP-Module introduction.**_
+
+
+ACE_MCO.1-3 The evaluator _**shall examine**_ the consistency rationale to determine that the
+statement of security objectives of the PP-Module is consistent with the
+statement of security objectives of its Base-PP(s).
+
+
+334 In particular, the evaluator examines the consistency rationale to determine
+that:
+
+
+a) the statements of the security objectives for the TOE and the security
+objectives for the operational environment in the PP-Module do not
+contradict those from the Base-PPs.
+
+
+b) the statement of the security objectives for the operational
+environment in the PP-Module addresses aspects out of scope of the
+Base-PP, in which case, the addition of elements is allowed.
+
+
+ACE_MCO.1.4C _**The consistency rationale shall demonstrate that the statement of security**_
+_**requirements is consistent with the statement of security requirements in**_
+_**the Base-PPs identified in the PP-Module introduction.**_
+
+
+ACE_MCO.1-4 The evaluator _**shall examine**_ the consistency rationale to determine that the
+statement of security requirements of the PP-Module is consistent with the
+statement of security requirements of its Base-PPs, that is, the SFRs of the
+PP-Module either complete or refine the SFRs of the Base-PP(s) and that no
+contradiction arises from the whole set of SFRs of the PP-Module and the
+Base-PP(s).
+
+
+Page 78 of 430 Version 3.1 April 2017
+
+
+**Class ACE: Protection Profile Configuration evaluation**
+
+## **10.9 PP-Configuration consistency (ACE_CCO)**
+
+
+**10.9.1** **Evaluation of sub-activity (ACE_CCO.1)**
+
+
+10.9.1.1 Objectives
+
+
+335 The objective of this sub-activity is to determine whether the PPConfiguration and its components are correctly identified.
+
+
+336 The objective of this sub-activity is also to determine the consistency of the
+PP-Configuration regarding the whole set of Protection Profiles and PPModules.
+
+
+337 For the consistency analysis required by this activity, the application notes of
+the CEM, Section 9.2.1 (9.2.1, Re-using the evaluation results of certified
+PPs), is applicable to determine which parts of the Base-PPs are to be reevaluated during the evaluation of PP-Configuration
+
+
+10.9.1.2 Input
+
+
+338 The evaluation evidence for this sub-activity is:
+
+
+a) the PP-Configuration reference;
+
+
+b) the PP-Configuration components statement;
+
+
+c) the PP(s) and PP-Modules identified in the components statement.
+
+
+10.9.1.3 Action ACE_CCO.1.1E
+
+
+ACE_CCO.1.1C _**The PP-Configuration reference shall uniquely identify the PP-**_
+_**Configuration.**_
+
+
+ACE_CCO.1-1 The evaluator _**shall examine**_ the PP-Configuration reference to determine
+that it uniquely identifies the PP-Configuration.
+
+
+339 The evaluator determines that the PP-Configuration reference identifies the
+PP-Configuration itself, so that it may be easily distinguished from other PPs,
+PP-Configurations and PP-Modules, and that it also uniquely identifies each
+version of the PP-Configuration, e.g. by including a version number and/or a
+date of publication.
+
+
+340 The PP-Configuration should have some referencing system that is capable
+of supporting unique references (e.g. use of numbers, letters or dates).
+
+
+ACE_CCO.1.2C _**The components statements shall uniquely identify the Protection Profiles**_
+_**and the PP-Modules that compose the PP-Configuration.**_
+
+
+ACE_CCO.1-2 The evaluator _**shall examine**_ the PP-Configuration components statement to
+determine that it uniquely identifies the Protection Profiles and PP-Modules
+contained in the PP-Configuration.
+
+
+April 2017 Version 3.1 Page 79 of 430
+
+
+**Class ACE: Protection Profile Configuration evaluation**
+
+
+341 The Protection Profiles should have been certified and available for use in
+security targets.
+
+
+ACE_CCO.1.3C _**The conformance statement shall specify the kind of conformity of the PP-**_
+_**Configuration, either strict or demonstrable. The conformance claim shall**_
+_**contain a CC conformance claim that identifies the version of the CC to**_
+_**which the PP-Configuration and its underlying Base-PP(s) and PP-**_
+_**Module claim conformance.**_
+
+
+ACE_CCO.1-3 The evaluator _**shall examine**_ the PP-Configuration conformance statement to
+determine that it specifies the kind of conformity required: strict or
+demonstrable.
+
+
+342 The evaluator _**shall check**_ that the conformance claim contains a CC
+conformance claim that identifies the version of the CC to which the PPConfiguration and its underlying Base-PP(s) and PP-Module claim
+conformance.
+
+
+343 The evaluator _**shall examine**_ the PP-Configuration conformance claim to
+determine the compatibility between all CC versions that are related to the
+PP-Configuration and its underlying Base-PP(s) and PP-Module.
+
+
+344 If at least one of the Protection Profiles identified in the PP-Configuration
+components statement claims strict conformance, then the PP-Configuration
+conformance claim has to state strict conformance also. CC versions used in
+a PP-Configuration and its underlying Base-PP(s) and PP-Module have to be
+compatible. If compatibility is not obvious, guidance from the certification
+scheme should be asked.
+
+
+ACE_CCO.1.4C _**The SAR statement shall specify the set of SAR or predefined EAL that**_
+_**applies to this PP-Configuration.**_
+
+
+ACE_CCO.1-4 The evaluator _**shall examine**_ the PP-Configuration SAR statement to
+determine that it specifies a well-formed package of SAR. The SAR package
+can be build in with components from CC Part 3 or can refer to a specific
+SAR package stated in one of the Protection Profiles composing the PPConfiguration.
+
+
+345 If the set of SAR comes from CC Part 3 then the evaluator _**shall check**_ that it
+is well-formed: it is closed by dependencies or the SAR statements provide a
+sound discarding rationale.
+
+
+346 The evaluator _**shall check**_ that the set of SAR of the PP-Configuration is
+consistent with respect to the SARs of each of the Protection Profiles
+contained in the PP-Configuration: for any SAR component in each of the
+Protection Profile, the PP-Configuration provides either the same component
+or a higher component in the family hierarchy. If the SAR component in the
+Protection Profile is a refinement of a standard component, then the
+correspondent SAR component in the PP-Configuration has to include these
+refinements. If two Protection Profiles refine the same SAR component, the
+
+
+Page 80 of 430 Version 3.1 April 2017
+
+
+**Class ACE: Protection Profile Configuration evaluation**
+
+
+evaluator _**shall check**_ that the refinements are not contradictory and that the
+corresponding SAR component in the PP-Configuration meets both.
+
+
+ACE_CCO.1.5C _**The Base-PP(s) on which the PP-Modules relies shall belong the**_
+_**Protection Profiles identified in the components statement of the PP-**_
+_**Configuration.**_
+
+
+ACE_CCO.1-5 The evaluator _**shall check**_ that the Base-PP(s) of the PP-Module are included
+in the set of PP(s) selected for the PP-Configuration.
+
+
+10.9.1.4 Action ACE_CCO.1.2E
+
+
+ACE_CCO.1-6 The evaluator _**shall check**_ that the PP-Configuration made up of all the
+Protection Profiles and PP-Modules identified in the components statement
+of the PP-Configuration is consistent. That is, the evaluator _**shall check**_ that
+no contradiction arises from the whole set of Protection Profiles and PPModules included in the PP-Configuration.
+
+
+347 The evaluator can organise this work in many ways; the actual organisation
+may depend on the will to derive evaluation results for more than one PPConfiguration at a time.
+
+
+348 For instance, the evaluator can process in two steps as follows:
+
+
+a) Assess the consistency of the set of Protection Profiles composing the
+PP-Configuration,
+
+
+b) Then proceed with the assessment of the PP-Configuration
+consistency incrementally, by adding one PP-Module at a time.
+
+
+349 An alternative is to proceed incrementally but mixing PPs and PP-Modules
+or to flatten the definition of the PP-Configuration (cf. Annex B in CC Part
+1) and to assess the consistency of the whole set of elements.
+
+
+350 Any incremental consistency analysis step where C is a subset of the PPConfiguration and X is a PP or a PP-Module that has to be added to C
+consists in:
+
+
+๏ญ assessing that the SPD, the objectives and the SFRs of X do not
+contradict the statements in C;
+
+
+๏ญ the assumptions and objectives for the environment in X either are
+the same as in C or address security aspects that are out of the scope
+of C.
+
+
+351 Note that if X is a PP-Module, C contains all its Base-PP(s) and Evaluation
+of sub-activity (ACE_MCO.1) has succeed for X, then the consistency
+analysis step has to be performed with respect to the components of C
+different from these Base-PP(s) only.
+
+
+April 2017 Version 3.1 Page 81 of 430
+
+
+**Class ASE: Security Target evaluation**
+
+# **11 Class ASE: Security Target evaluation**
+
+## **11.1 Introduction**
+
+
+352 This Chapter describes the evaluation of an ST. The ST evaluation should be
+started prior to any TOE evaluation sub-activities since the ST provides the
+basis and context to perform these sub-activities. The evaluation
+methodology in this section is based on the requirements on the ST as
+specified in CC Part 3 class ASE.
+
+
+353 This Chapter should be used in conjunction with Annexes A, B and C,
+Guidance for Operations in CC Part 1, as these Annexes clarify the concepts
+here and provide many examples.
+
+## **11.2 Application notes**
+
+
+**11.2.1** **Re-using the evaluation results of certified PPs**
+
+
+354 While evaluating an ST that is based on one or more certified PPs, it may be
+possible to re-use the fact that these PPs were certified. The potential for reuse of the result of a certified PP is greater if the ST does not add threats,
+OSPs, assumptions, security objectives and/or security requirements to those
+of the PP. If the ST contains much more than the certified PP, re-use may not
+be useful at all.
+
+
+355 The evaluator is allowed to re-use the PP evaluation results by doing certain
+analyses only partially or not at all if these analyses or parts thereof were
+already done as part of the PP evaluation. While doing this, the evaluator
+should assume that the analyses in the PP were performed correctly.
+
+
+356 An example would be where the PP contains a set of security requirements,
+and these were determined to be internally consistent during the PP
+evaluation. If the ST uses the exact same requirements, the consistency
+analysis does not have to be repeated during the ST evaluation. If the ST
+adds one or more requirements, or performs operations on these requirements,
+the analysis will have to be repeated. However, it may be possible to save
+work in this consistency analysis by using the fact that the original
+requirements are internally consistent. If the original requirements are
+internally consistent, the evaluator only has to determine that:
+
+
+a) the set of all new and/or changed requirements is internally consistent,
+and
+
+
+b) the set of all new and/or changed requirements is consistent with the
+original requirements.
+
+
+357 The evaluator notes in the ETR each case where analyses are not done or
+only partially done for this reason.
+
+
+Page 82 of 430 Version 3.1 April 2017
+
+
+**Class ASE: Security Target evaluation**
+
+## **11.3 ST introduction (ASE_INT)**
+
+
+**11.3.1** **Evaluation of sub-activity (ASE_INT.1)**
+
+
+11.3.1.1 Objectives
+
+
+358 The objective of this sub-activity is to determine whether the ST and the
+TOE are correctly identified, whether the TOE is correctly described in a
+narrative way at three levels of abstraction (TOE reference, TOE overview
+and TOE description), and whether these three descriptions are consistent
+with each other.
+
+
+11.3.1.2 Input
+
+
+359 The evaluation evidence for this sub-activity is:
+
+
+a) the ST.
+
+
+11.3.1.3 Action ASE_INT.1.1E
+
+
+ASE_INT.1.1C _**The ST introduction shall contain an ST reference, a TOE reference, a**_
+_**TOE overview and a TOE description.**_
+
+
+ASE_INT.1-1 The evaluator _**shall check**_ that the ST introduction contains an 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-2 The evaluator _**shall examine**_ the ST reference to determine that it uniquely
+identifies the ST.
+
+
+360 The evaluator determines that the ST reference identifies the ST itself, so that
+it may be easily distinguished from other STs, and that it also uniquely
+identifies each version of the ST, e.g. by including a version number and/or a
+date of publication.
+
+
+361 In evaluations where a CM system is provided, the evaluator may validate
+the uniqueness of the reference by checking the configuration list. In the
+other cases, the ST should have some referencing system that is capable of
+supporting unique references (e.g. use of numbers, letters or dates).
+
+
+ASE_INT.1.3C _**The TOE reference shall uniquely identify the TOE.**_
+
+
+ASE_INT.1-3 The evaluator _**shall examine**_ the TOE reference to determine that it uniquely
+identifies the TOE.
+
+
+362 The evaluator determines that the TOE reference uniquely identifies the TOE,
+so that it is clear to which TOE the ST refers, and that it also identifies the
+version of the TOE, e.g. by including a version/release/build number, or a
+date of release.
+
+
+April 2017 Version 3.1 Page 83 of 430
+
+
+**Class ASE: Security Target evaluation**
+
+
+363 In the end of the evaluation, the evaluator _**shall check**_ the TOE reference,
+and any unique identifiers associated with the TOE physical components are
+consistent with the identifier(s) assigned to the TOE evaluated in work units
+related to ALC_CMC.x.1C and the configuration list evaluated in work units
+related to ALC_CMS.x.2C.
+
+
+ASE_INT.1-4 The evaluator _**shall examine**_ the TOE reference to determine that it is not
+misleading.
+
+
+364 If the TOE is related to one or more well-known products, it is allowed to
+reflect this in the TOE reference. However, this should not be used to
+mislead consumers and it must be made clear which part of the product has
+been evaluated.
+
+
+365 When a TOE needs some required non-TOE hardware/software/firmware to
+run properly, the TOE reference may include the name of the non-TOE
+hardware/software/firmware used by the TOE, however it must be made
+clear that the non-TOE hardware/software/firmware has not been evaluated.
+
+
+ASE_INT.1.4C _**The TOE overview shall summarise the usage and major security features**_
+_**of the TOE.**_
+
+
+ASE_INT.1-5 The evaluator _**shall examine**_ the TOE overview to determine that it describes
+the usage and major security features of the TOE.
+
+
+366 The TOE overview should briefly (i.e. several paragraphs) describe the usage
+and major security features of the TOE. The TOE overview should enable
+potential consumers to quickly determine whether the TOE may be suitable
+for their security needs.
+
+
+367 The TOE overview may describe security features that provided by the
+product, and users may expect in that product type, but it must be clear those
+features that are evaluated and those are not evaluated.
+
+
+368 The TOE overview shall be consistent with information provided in other
+sections of the Security Target such as the TOE description, the security
+objectives, the security functional requirements, and the TOE summary
+specification. In addition to ensuring the evaluated security features are
+consistently described throughout the ST, this means that any security feature
+that is not evaluated is only discussed within the ST introduction.
+
+
+369 The TOE overview in an ST for a composed TOE should describe the usage
+and major security feature of the composed TOE, rather than those of the
+individual component TOEs.
+
+
+370 The evaluator determines that the overview is clear enough for consumers,
+and sufficient to give them a general understanding of the intended usage and
+major security features of the TOE.
+
+
+ASE_INT.1.5C _**The TOE overview shall identify the TOE type.**_
+
+
+ASE_INT.1-6 The evaluator _**shall check**_ that the TOE overview identifies the TOE type.
+
+
+Page 84 of 430 Version 3.1 April 2017
+
+
+**Class ASE: Security Target evaluation**
+
+
+ASE_INT.1-7 The evaluator _**shall examine**_ the TOE overview to determine that the TOE
+type is not misleading.
+
+
+371 There are situations where the general consumer would expect certain
+functionality of the TOE because of its TOE type. If this functionality is
+absent in the TOE, the evaluator determines that the TOE overview
+adequately discusses this absence.
+
+
+372 There are also TOEs where the general consumer would expect that the TOE
+should be able to operate in a certain operational environment because of its
+TOE type. If the TOE is unable to operate in such an operational
+environment, the evaluator determines that the TOE overview adequately
+discusses this.
+
+
+ASE_INT.1.6C _**The**_ _**TOE**_ _**overview**_ _**shall**_ _**identify**_ _**any**_ _**non-TOE**_
+_**hardware/software/firmware required by the TOE.**_
+
+
+ASE_INT.1-8 The evaluator _**shall examine**_ the TOE overview to determine that it identifies
+any non-TOE hardware/software/firmware required by the TOE.
+
+
+373 While some TOEs are able to run stand-alone, other TOEs (notably software
+TOEs) need additional hardware, software or firmware to operate. If the TOE
+does not require any hardware, software or firmware, this work unit is not
+applicable and therefore considered to be satisfied.
+
+
+374 The evaluator determines that the TOE overview identifies any additional
+hardware, software and firmware needed by the TOE to operate. This
+identification does not have to be exhaustive, but detailed enough for
+potential consumers of the TOE to determine whether their current hardware,
+software and firmware support use of the TOE, and, if this is not the case,
+which additional hardware, software and/or firmware is needed.
+
+
+ASE_INT.1.7C _**The TOE description shall describe the physical scope of the TOE.**_
+
+
+ASE_INT.1-9 The evaluator _**shall examine**_ the TOE description to determine that it
+describes the physical scope of the TOE.
+
+
+375 The evaluator determines that the TOE description lists the hardware,
+firmware, software and guidance parts that constitute the TOE and describes
+them at a level of detail that is sufficient to give the reader a general
+understanding of those parts.
+
+
+376 As a minimum the TOE description will cover the following elements:
+
+
+a) Each separately delivered part of the TOE, which will be identified
+by its unique identifier and the current format (binary, wafer, inlay,
+*.pdf, *.doc, *.chm etc.).
+
+
+b) The delivery method used by the developer to make available each
+part to the TOE consumer (Web site download, courier delivery, etc.)
+
+
+April 2017 Version 3.1 Page 85 of 430
+
+
+**Class ASE: Security Target evaluation**
+
+
+377 The physical description will also include some clear statements about the
+evaluated TOE configuration. In the case where a product could have
+multiple physical components, and therefore multiple configurations, the
+evaluated configurations must be briefly described and identified.
+
+
+378 The evaluator also determines that there is no possible misunderstanding as
+to whether any hardware, firmware, software or guidance part is part of the
+TOE or not.
+
+
+ASE_INT.1.8C _**The TOE description shall describe the logical scope of the TOE.**_
+
+
+ASE_INT.1-10 The evaluator _**shall examine**_ the TOE description to determine that it
+describes the logical scope of the TOE.
+
+
+379 The evaluator determines that the TOE description discusses the logical
+security features offered by the TOE at a level of detail that is sufficient to
+give the reader a general understanding of those features.
+
+
+380 The evaluator also determines that there is no possible misunderstanding as
+to whether any logical security feature is offered by the TOE or not.
+
+
+381 An ST for a composed TOE may refer out to the description of the logical
+scope of the component TOEs, provided in the component TOE STs to
+provide the majority of this description for the composed TOE. However, the
+evaluator determines that the composed TOE ST clearly discusses which
+features of the individual components are not within the composed TOE, and
+therefore not a feature of the composed TOE.
+
+
+11.3.1.4 Action ASE_INT.1.2E
+
+
+ASE_INT.1-11 The evaluator _**shall examine**_ the TOE reference, TOE overview and TOE
+description to determine that they are consistent with each other.
+
+
+Page 86 of 430 Version 3.1 April 2017
+
+
+**Class ASE: Security Target evaluation**
+
+## **11.4 Conformance claims (ASE_CCL)**
+
+
+**11.4.1** **Evaluation of sub-activity (ASE_CCL.1)**
+
+
+11.4.1.1 Objectives
+
+
+382 The objective of this sub-activity is to determine the validity of various
+conformance claims. These describe how the ST and the TOE conform to the
+CC and how the ST conforms to PPs and packages.
+
+
+11.4.1.2 Input
+
+
+383 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the PP(s) that the ST claims conformance to;
+
+
+c) the package(s) that the ST claims conformance to.
+
+
+11.4.1.3 Action ASE_CCL.1.1E
+
+
+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-1 The evaluator _**shall check**_ that the conformance claim contains a CC
+conformance claim that identifies the version of the CC to which the ST and
+the TOE claim conformance.
+
+
+384 The evaluator determines that the CC conformance claim identifies the
+version of the CC that was used to develop this ST. This should include the
+version number of the CC and, unless the International English version of the
+CC was used, the language of the version of the CC that was used.
+
+
+385 For a composed TOE, the evaluator will consider any differences between
+the version of the CC claimed for a component and the version of the CC
+claimed for the composed TOE. If the versions differ the evaluator will
+assess whether the differences between the versions will lead to conflicting
+claims.
+
+
+386 For instances where the CC conformance claims for the base TOE and
+dependent TOE are for different major releases of the CC (e.g. one
+component TOE conformance claim is CC v2.x and the other component
+TOE conformance claim is CC v3.x), the conformance claim for the
+composed TOE will be the earlier release of the CC, as the CC is developed
+with an aim to provide backwards compatibility (although this may not be
+achieved in the strictest sense, it is understood to be achieved in principle).
+
+
+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.**_
+
+
+April 2017 Version 3.1 Page 87 of 430
+
+
+**Class ASE: Security Target evaluation**
+
+
+ASE_CCL.1-2 The evaluator _**shall check**_ that the CC conformance claim states a claim of
+either CC Part 2 conformant or CC Part 2 extended for the ST.
+
+
+387 For a composed TOE, the evaluator will consider whether this claim is
+consistent not only with the CC Part 2, but also with the claims of
+conformance to CC Part 2 by each of the component TOEs. I.e. if one or
+more component TOEs claims to be CC Part 2 extended, then the composed
+TOE should also claim to be CC Part 2 extended.
+
+
+388 The CC conformance claim for the composed TOE may be CC Part 2
+extended, even though the component TOEs are Part 2 conformant, in the
+event that additional SFRs are claimed for the base TOE (see composed TOE
+guidance for _**ASE_CCL.1.6C**_ )
+
+
+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-3 The evaluator _**shall check**_ that the CC conformance claim states a claim of
+either CC Part 3 conformant or CC Part 3 extended for the ST.
+
+
+ASE_CCL.1.4C _**The CC conformance claim shall be consistent with the extended**_
+_**components definition.**_
+
+
+ASE_CCL.1-4 The evaluator _**shall examine**_ the CC conformance claim for CC Part 2 to
+determine that it is consistent with the extended components definition.
+
+
+389 If the CC conformance claim contains CC Part 2 conformant, the evaluator
+determines that the extended components definition does not define
+functional components.
+
+
+390 If the CC conformance claim contains CC Part 2 extended, the evaluator
+determines that the extended components definition defines at least one
+extended functional component.
+
+
+ASE_CCL.1-5 The evaluator _**shall examine**_ the CC conformance claim for CC Part 3 to
+determine that it is consistent with the extended components definition.
+
+
+391 If the CC conformance claim contains CC Part 3 conformant, the evaluator
+determines that the extended components definition does not define
+assurance components.
+
+
+392 If the CC conformance claim contains CC Part 3 extended, the evaluator
+determines that the extended components definition defines at least one
+extended assurance component.
+
+
+ASE_CCL.1.5C _**The conformance claim shall identify all PPs and security requirement**_
+_**packages to which the ST claims conformance.**_
+
+
+ASE_CCL.1-6 The evaluator _**shall check**_ that the conformance claim contains a PP claim
+that identifies all PPs for which the ST claims conformance.
+
+
+Page 88 of 430 Version 3.1 April 2017
+
+
+**Class ASE: Security Target evaluation**
+
+
+393 If the ST does not claim conformance to a PP, this work unit is not
+applicable and therefore considered to be satisfied.
+
+
+394 The evaluator determines that any referenced PPs are unambiguously
+identified (e.g. by title and version number, or by the identification included
+in the introduction of that PP). Only those PPs to which the ST claims strict
+or demonstrable conformance are allowed to be identified in the
+conformance claim section that means claiming partial conformance to a PP
+or PP-configuration is not permitted.
+
+
+395 Therefore, conformance to a PP requiring a composite solution may be
+claimed in an ST for a composed TOE. Conformance to such a PP would not
+have been possible during the evaluation of the component TOEs, as these
+components would not have satisfied the composed solution. This is only
+possible in the instances where the 'composite' PP permits use of the
+composition evaluation approach (use of ACO components).
+
+
+396 The ST for a composed TOE will identify the STs of the component TOEs
+from which the composed ST is comprised. The composed TOE is
+essentially claiming conformance to the STs of the component TOEs.
+
+
+ASE_CCL.1-7 The evaluator _**shall check**_ that the conformance claim contains a package
+claim that identifies all packages to which the ST claims conformance.
+
+
+397 If the ST does not claim conformance to a package, this work unit is not
+applicable and therefore considered to be satisfied.
+
+
+398 The evaluator determines that any referenced packages are unambiguously
+identified (e.g. by title and version number, or by the identification included
+in the introduction of that package).
+
+
+399 The evaluator determines that the component TOE STs from which the
+composed TOE is derived are also unambiguously identified.
+
+
+400 The evaluator is reminded that claims of partial conformance to a package
+are not permitted.
+
+
+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-8 The evaluator _**shall check**_ that, for each identified package, the conformance
+claim states a claim of either package-name conformant or package-name
+augmented.
+
+
+401 If the ST does not claim conformance to a package, this work unit is not
+applicable and therefore considered to be satisfied.
+
+
+402 If the package conformance claim contains package-name conformant, the
+evaluator determines that:
+
+
+a) If the package is an assurance package, then the ST contains all SARs
+included in the package, but no additional SARs.
+
+
+April 2017 Version 3.1 Page 89 of 430
+
+
+**Class ASE: Security Target evaluation**
+
+
+b) If the package is a functional package, then the ST contains all SFRs
+included in the package, but no additional SFRs.
+
+
+403 If the package conformance claim contains package-name augmented, the
+evaluator determines that:
+
+
+a) If the package is an assurance package then the ST contains all SARs
+included in the package, and at least one additional SAR or at least
+one SAR that is hierarchical to a SAR in the package.
+
+
+b) If the package is a functional package, then the ST contains all SFRs
+included in the package, and at least one additional SFR or at least
+one SFR that is hierarchical to a SFR in the package.
+
+
+ASE_CCL.1.7C _**The conformance claim rationale shall demonstrate that the TOE type is**_
+_**consistent with the TOE type in the PPs for which conformance is being**_
+_**claimed.**_
+
+
+ASE_CCL.1-9 The evaluator _**shall examine**_ the conformance claim rationale to determine
+that the TOE type of the TOE is consistent with all TOE types of the PPs.
+
+
+404 If the ST does not claim conformance to a PP, this work unit is not
+applicable and therefore considered to be satisfied.
+
+
+405 The relation between the types may be simple: a firewall ST claiming
+conformance to a firewall PP, or more complex: a smart card ST claiming
+conformance to a number of PPs at the same time (a PP for the integrated
+circuit, a PP for the smart card OS, and two PPs for two applications on the
+smart card).
+
+
+406 For a composed TOE, the evaluator will determine whether the conformance
+claim rationale demonstrates that the TOE types of the component TOEs are
+consistent with the composed TOE type. This does not mean that both the
+component and the composed TOE types have to be the same, but rather that
+the component TOEs are suitable for integration to provide the composed
+TOE. It should be made clear in the composed TOE ST which SFRs are only
+included as a result of composition, and were not examined as SFRs in the
+base and dependent TOE (e.g. EALx) evaluation.
+
+
+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-10 The evaluator _**shall examine**_ the conformance claim rationale to determine
+that it demonstrates that the statement of security problem definition is
+consistent, as defined by the conformance statement of the PP, with the
+statements of security problem definition stated in the PPs to which
+conformance is being claimed.
+
+
+Page 90 of 430 Version 3.1 April 2017
+
+
+**Class ASE: Security Target evaluation**
+
+
+407 If the ST does not claim conformance with a PP, this work unit is not
+applicable and therefore considered to be satisfied.
+
+
+408 If the PP does not have a statement of security problem definition, this work
+unit is not applicable and therefore considered to be satisfied.
+
+
+409 If strict conformance is required by the PP to which conformance is being
+claimed no conformance claim rationale is required. Instead, the evaluator
+determines whether:
+
+
+a) the threats in the ST are a superset of or identical to the threats in the
+PP to which conformance is being claimed;
+
+
+b) the OSPs in the ST are a superset of or identical to the OSPs in the PP
+to which conformance is being claimed;
+
+
+c) the assumptions in the ST are identical to the assumptions in the PP
+to which conformance is being claimed, with two possible exceptions
+described in the following two bullet points;
+
+
+๏ญ an assumption (or part of an assumption) from the PP can be
+omitted, if all security objectives for the operational
+environment addressing this assumption (or part of an
+assumption) are replaced by security objectives for the TOE;
+
+
+๏ญ an assumption can be added to the assumptions defined in the
+PP, if a rationale is given, why the new assumption neither
+mitigates a threat (or a part of a threat) meant to be addressed
+by security objectives for the TOE in the PP, nor fulfils an
+OSP (or part of an OSP) meant to be addressed by security
+objectives for the TOE in the PP.
+
+
+When examining an ST claiming a PP, which omits assumptions from the PP
+or adds new assumptions, the evaluator shall carefully determine, if the
+conditions given above are fulfilled. The following discussion gives some
+motivation and examples for these cases:
+
+
+๏ญ Example for omitting an assumption: A PP may contain an
+assumption stating that the operational environment prevents
+unauthorised modification or interception of data sent to an
+external interface of the TOE. This may be the case if the
+TOE accepts data in clear text and without integrity protection
+at this interface and is assumed to be located in a secure
+operational environment, which will prevent attackers from
+accessing these data. The assumption will then be mapped in
+the PP to some objective for the operational environment
+stating that the data interchanged at this interface are
+protected by adequate measures in the operational
+environment. If an ST claiming this PP defines a more secure
+TOE, which has an additional security objective stating that
+the TOE itself protects these data, for example by providing a
+
+
+April 2017 Version 3.1 Page 91 of 430
+
+
+**Class ASE: Security Target evaluation**
+
+
+secure channel for encryption and integrity protection of all
+data transferred via this interface, the corresponding objective
+and assumption for the operational environment can be
+omitted from the ST. This is also called re-assigning of the
+objective, since the objective is re-assigned from the
+operational environment to the TOE. Note, that this TOE is
+still secure in an operational environment fulfilling the
+omitted assumption and therefore still fulfils the PP.
+
+
+๏ญ Example for adding an assumption: In this example the PP is
+designed to specify requirements for a TOE of type "Firewall"
+and an ST author wishes to claim this PP for a TOE, which
+implements a firewall, but additionally provides the
+functionality of a virtual private network (VPN) component.
+For the VPN functionality the TOE needs cryptographic keys
+and these keys may also have to be handled securely by the
+operational environment (e. g. if symmetric keys are used to
+secure the network connection and therefore need to be
+provided in some secure way to other components in the
+network). In this case it is acceptable to add an assumption
+that the cryptographic keys used by the VPN are handled
+securely by the operational environment. This assumption
+does not address threats or OSPs of the PP and therefore
+fulfils the conditions stated above.
+
+
+๏ญ Counterexample for adding an assumption: In a variant of the
+first example a PP may already contain an objective for the
+TOE to provide a secure channel for one of its interfaces, and
+this objective is mapped to a threat of unauthorised
+modification or reading of the data on this interface. In this
+case it is clearly not allowed for an ST claiming this PP to add
+an assumption for the operational environment, which
+assumes that the operational environment protects data on this
+interface against modification or unauthorised reading of the
+data. This assumption would reduce a threat, which is meant
+to be addressed by the TOE. Therefore a TOE fulfilling an ST
+with this added assumption would not automatically fulfil the
+PP any more and this addition is therefore not allowed.
+
+
+๏ญ Second counterexample for adding an assumption: In the
+example above of a TOE implementing a firewall it would not
+be admissible to add a general assumption that the TOE is
+only connected to trusted devices, because this would
+obviously remove essential threats relevant for a firewall
+(namely that there is untrusted IP traffic, which needs to be
+filtered). Therefore this addition would not be allowed.
+
+
+410 If demonstrable conformance is required by the PP, the evaluator examines
+the conformance claim rationale to determine that it demonstrates that the
+statement of security problem definition of the ST is equivalent or more
+
+
+Page 92 of 430 Version 3.1 April 2017
+
+
+**Class ASE: Security Target evaluation**
+
+
+restrictive than the statement of security problem definition in the PP to
+which conformance is being claimed.
+
+
+411 For this, the conformance claim rationale needs to demonstrate that the
+security problem definition in the ST is equivalent (or more restrictive) than
+the security problem definition in the PP. This means that:
+
+
+๏ญ all TOEs that would meet the security problem definition in the ST
+also meet the security problem definition in the PP. This can also be
+shown indirectly by demonstrating that every event, which realises a
+threat defined in the PP or violates an OSP defined in the PP, would
+also realise a threat stated in the ST or violate an OSP defined in the
+ST. Note that fulfilling an OSP stated in the ST may avert a threat
+stated in the PP or that averting a threat stated in the ST may fulfil an
+OSP stated in the PP, so threats and OSPs can substitute each other;
+
+
+๏ญ all operational environments that would meet the security problem
+definition in the PP would also meet the security problem definition
+in the ST (with one exception in the next bullet);
+
+
+๏ญ besides a set of assumptions in the ST needed to demonstrate
+conformance to the SPD of the PP, an ST may specify further
+assumptions, but only if these additional assumptions are independent
+of and do not affect the security problem definition as defined in the
+PP. More detailed, there are no assumptions in the ST that exclude
+threats to the TOE that need to be countered by the TOE according to
+the PP. Similarly, there are no assumptions in the ST that realise
+aspects of an OSP stated in the PP, which are meant to be fulfilled by
+the TOE according to the PP."
+
+
+412 For a composed TOE, the evaluator will consider whether the security
+problem definition of the composed TOE is consistent with that specified in
+the STs for the component TOEs. This is determined in terms of
+demonstrable conformance. In particular, the evaluator examines the
+conformance claim rationale to determine that:
+
+
+a) Threat statements and OSPs in the composed TOE ST do not
+contradict those from the component STs.
+
+
+b) Any assumptions made in the component STs are upheld in the
+composed TOE ST. That is, either the assumption should also be
+present in the composed ST, or the assumption should be positively
+addressed in the composed ST. The assumption may be positively
+addressed through specification of requirements in the composed
+TOE to provide functionality fulfilling the concern captured in the
+assumption.
+
+
+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.**_
+
+
+April 2017 Version 3.1 Page 93 of 430
+
+
+**Class ASE: Security Target evaluation**
+
+
+ASE_CCL.1-11 The evaluator _**shall examine**_ the conformance claim rationale to determine
+that the statement of security objectives is consistent, as defined by the
+conformance statement of the PP, with the statement of security objectives in
+the PPs to which conformance is being claimed.
+
+
+413 If the ST does not claim conformance to a PP, this work unit is not
+applicable and therefore considered to be satisfied.
+
+
+414 If strict conformance is required by the PP to which conformance is being
+claimed, no conformance claim rationale is required. Instead, the evaluator
+determines whether:
+
+
+๏ญ The ST contains all security objectives for the TOE of the PP to
+which conformance is being claimed. Note that it is allowed for the
+ST under evaluation to have additional security objectives for the
+TOE;
+
+
+๏ญ The security objectives for the operational environment in the ST are
+identical to the security objectives for the operational environment in
+the PP to which conformance is being claimed, with two possible
+exceptions described in the following two bullet points;
+
+
+๏ญ a security objective for the operational environment (or part of such
+security objective) from the PP can be replaced by the same (part of
+the) security objective stated for the TOE;
+
+
+๏ญ a security objective for the operational environment can be added to
+the objectives defined in the PP, if a justification is given, why the
+new objective neither mitigates a threat (or a part of a threat) meant to
+be addressed by security objectives for the TOE in the PP, nor fulfils
+an OSP (or part of an OSP) meant to be addressed by security
+objectives for the TOE in the PP.
+
+
+When examining an ST claiming a PP, which omits security objectives for
+the operational environment from the PP or adds new security objectives for
+the operational environment, the evaluator shall carefully determine, if the
+conditions given above are fulfilled. The examples given for the case of
+assumptions in the preceding work unit are also valid here.
+
+
+415 If demonstrable conformance is required by the PP to which conformance is
+being claimed, the evaluator examines the conformance claim rationale to
+determine that it demonstrates that the statement of security objectives of the
+ST is equivalent or more restrictive than the statement of security objectives
+in the PP to which conformance is being claimed.
+
+
+416 For this the conformance claim rationale needs to demonstrate that the
+security objectives in the ST are equivalent (or more restrictive) than the
+security objectives in the PP. This means that:
+
+
+๏ญ all TOEs that would meet the security objectives for the TOE in the
+ST also meet the security objectives for the TOE in the PP;
+
+
+Page 94 of 430 Version 3.1 April 2017
+
+
+**Class ASE: Security Target evaluation**
+
+
+๏ญ all operational environments that would meet the security objectives
+for the operational environment in the PP would also meet the
+security objectives for the operational environment in the ST (with
+one exception in the next bullet);
+
+
+๏ญ besides a set of security objectives for the operational environment in
+the ST, which are used to demonstrate conformance to the set of
+security objectives defined in the PP, an ST may specify further
+security objectives for the operational environment, but only if these
+security objectives neither affect the original set of security objectives
+for the TOE nor the security objectives for the operational
+environment as defined in the PP to which conformance is claimed."
+
+
+417 For a composed TOE, the evaluator will consider whether the security
+objectives of the composed TOE are consistent with that specified in the STs
+for the component TOEs. This is determined in terms of demonstrable
+conformance. In particular, the evaluator examines the conformance claim
+rationale to determine that:
+
+
+a) The statement of security objectives in the dependent TOE ST
+relevant to any IT in the operational environment are consistent with
+the statement of security objectives for the TOE in the base TOE ST.
+It is not expected that the statement of security objectives for the
+environment within in the dependent TOE ST will cover all aspects
+of the statement of security objectives for the TOE in the base TOE
+ST.
+
+
+b) The statement of security objectives in the composed ST is consistent
+with the statements of security objectives in the STs for the
+component TOEs.
+
+
+418 If demonstrable conformance is required by the PP, the evaluator examines
+the conformance claim rationale to determine that it demonstrates that the
+statement of security objectives of the ST is at least equivalent to the
+statement of security objectives in the PP, or component TOE ST in the case
+of a composed TOE ST.
+
+
+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.**_
+
+
+ASE_CCL.1-12 The evaluator _**shall examine**_ the ST to determine that it is consistent, as
+defined by the conformance statement of the PP, with all security
+requirements in the PPs for which conformance is being claimed.
+
+
+419 If the ST does not claim conformance to a PP, this work unit is not
+applicable and therefore considered to be satisfied.
+
+
+420 If strict conformance is required by the PP to which conformance is being
+claimed, no conformance claim rationale is required. Instead, the evaluator
+determines whether the statement of security requirements in the ST is a
+
+
+April 2017 Version 3.1 Page 95 of 430
+
+
+**Class ASE: Security Target evaluation**
+
+
+superset of or identical to the statement of security requirements in the PP to
+which conformance is being claimed (for strict conformance).
+
+
+421 If demonstrable conformance is required by the PP to which conformance is
+being claimed, the evaluator examines the conformance claim rationale to
+determine that it demonstrates that the statement of security requirements of
+the ST is equivalent or more restrictive than the statement of security
+requirements in the PP to which conformance is being claimed.
+
+
+422 For:
+
+
+๏ญ SFRs: The conformance rationale in the ST shall demonstrate that the
+overall set of requirements defined by the SFRs in the ST is
+equivalent (or more restrictive) than the overall set of requirements
+defined by the SFRs in the PP. This means that all TOEs that would
+meet the requirements defined by the set of all SFRs in the ST would
+also meet the requirements defined by the set of all SFRs in the PP;
+
+
+๏ญ SARs: The ST shall contain all SARs in the PP, but may claim
+additional SARs or replace SARs by hierarchically stronger SARs.
+The completion of operations in the ST must be consistent with that
+in the PP; either the same completion will be used in the ST as that in
+the PP or a completion that makes the SAR more restrictive (the rules
+of refinement apply).
+
+
+423 For a composed TOE, the evaluator will consider whether the security
+requirements of the composed TOE are consistent with that specified in the
+STs for the component TOEs. This is determined in terms of demonstrable
+conformance. In particular, the evaluator examines the conformance
+rationale to determine that:
+
+
+a) The statement of security requirements in the dependent TOE ST
+relevant to any IT in the operational environment is consistent with
+the statement of security requirements for the TOE in the base TOE
+ST. It is not expected that the statement of security requirements for
+the environment within in the dependent TOE ST will cover all
+aspects of the statement of security requirements for the TOE in the
+base TOE ST, as some SFRs may need to be added to the statement
+of security requirements in the composed TOE ST. However, the
+statement of security requirements in the base should support the
+operation of the dependent component.
+
+
+b) The statement of security objectives in the dependent TOE ST
+relevant to any IT in the operational environment is consistent with
+the statement of security requirements for the TOE in the base TOE
+ST. It is not expected that the statement of security objectives for the
+environment within in the dependent TOE ST will cover all aspects
+of the statement of security requirements for the TOE in the base
+TOE ST.
+
+
+Page 96 of 430 Version 3.1 April 2017
+
+
+**Class ASE: Security Target evaluation**
+
+
+c) The statement of security requirements in the composed is consistent
+with the statements of security requirements in the STs for the
+component TOEs.
+
+
+424 If demonstrable conformance is required by the PP to which conformance is
+being claimed, the evaluator examines the conformance claim rationale to
+determine that it demonstrates that the statement of security requirements of
+the ST is at least equivalent to the statement of security requirements in the
+PP, or component TOE ST in the case of a composed TOE ST.
+
+
+April 2017 Version 3.1 Page 97 of 430
+
+
+**Class ASE: Security Target evaluation**
+
+## **11.5 Security problem definition (ASE_SPD)**
+
+
+**11.5.1** **Evaluation of sub-activity (ASE_SPD.1)**
+
+
+11.5.1.1 Objectives
+
+
+425 The objective of this sub-activity is to determine that the security problem
+intended to be addressed by the TOE and its operational environment is
+clearly defined.
+
+
+11.5.1.2 Input
+
+
+426 The evaluation evidence for this sub-activity is:
+
+
+a) the ST.
+
+
+11.5.1.3 Action ASE_SPD.1.1E
+
+
+ASE_SPD.1.1C _**The security problem definition shall describe the threats.**_
+
+
+ASE_SPD.1-1 The evaluator _**shall check**_ that the security problem definition describes the
+threats.
+
+
+427 If all security objectives are derived from assumptions and/or OSPs only, the
+statement of threats need not be present in the ST. In this case, this work unit
+is not applicable and therefore considered to be satisfied.
+
+
+428 The evaluator determines that the security problem definition describes the
+threats that must be countered by the TOE and/or operational environment.
+
+
+ASE_SPD.1.2C _**All threats shall be described in terms of a threat agent, an asset, and an**_
+_**adverse action.**_
+
+
+ASE_SPD.1-2 The evaluator _**shall examine**_ the security problem definition to determine
+that all threats are described in terms of a threat agent, an asset, and an
+adverse action.
+
+
+429 If all security objectives are derived from assumptions and/or OSPs only, the
+statement of threats need not be present in the ST. In this case, this work unit
+is not applicable and therefore considered to be satisfied.
+
+
+430 Threat agents may be further described by aspects such as expertise, resource,
+opportunity, and motivation.
+
+
+ASE_SPD.1.3C _**The security problem definition shall describe the OSPs.**_
+
+
+ASE_SPD.1-3 The evaluator _**shall examine**_ that the security problem definition describes
+the OSPs.
+
+
+431 If all security objectives are derived from assumptions and threats only,
+OSPs need not be present in the ST. In this case, this work unit is not
+applicable and therefore considered to be satisfied.
+
+
+Page 98 of 430 Version 3.1 April 2017
+
+
+**Class ASE: Security Target evaluation**
+
+
+432 The evaluator determines that OSP statements are made in terms of rules or
+guidelines that must be followed by the TOE and/or its operational
+environment.
+
+
+433 The evaluator determines that each OSP is explained and/or interpreted in
+sufficient detail to make it clearly understandable; a clear presentation of
+policy statements is necessary to permit tracing security objectives to them.
+
+
+ASE_SPD.1.4C _**The security problem definition shall describe the assumptions about the**_
+_**operational environment of the TOE.**_
+
+
+ASE_SPD.1-4 The evaluator _**shall examine**_ the security problem definition to determine
+that it describes the assumptions about the operational environment of the
+TOE.
+
+
+434 If there are no assumptions, this work unit is not applicable and is therefore
+considered to be satisfied.
+
+
+435 The evaluator determines that each assumption about the operational
+environment of the TOE is explained in sufficient detail to enable consumers
+to determine that their operational environment matches the assumption. If
+the assumptions are not clearly understood, the end result may be that the
+TOE is used in an operational environment in which it will not function in a
+secure manner.
+
+
+April 2017 Version 3.1 Page 99 of 430
+
+
+**Class ASE: Security Target evaluation**
+
+## **11.6 Security objectives (ASE_OBJ)**
+
+
+**11.6.1** **Evaluation of sub-activity (ASE_OBJ.1)**
+
+
+11.6.1.1 Objectives
+
+
+436 The objective of this sub-activity is to determine whether the security
+objectives for the operational environment are clearly defined.
+
+
+11.6.1.2 Input
+
+
+437 The evaluation evidence for this sub-activity is:
+
+
+a) the ST.
+
+
+11.6.1.3 Action ASE_OBJ.1.1E
+
+
+ASE_OBJ.1.1C _**The statement of security objectives shall describe the security objectives**_
+_**for the operational environment.**_
+
+
+ASE_OBJ.1-1 The evaluator _**shall check**_ that the statement of security objectives defines
+the security objectives for the operational environment.
+
+
+438 The evaluator checks that the security objectives for the operational
+environment are identified.
+
+
+**11.6.2** **Evaluation of sub-activity (ASE_OBJ.2)**
+
+
+11.6.2.1 Objectives
+
+
+439 The objective of this sub-activity is to determine whether the security
+objectives adequately and completely address the security problem definition
+and that the division of this problem between the TOE and its operational
+environment is clearly defined.
+
+
+11.6.2.2 Input
+
+
+440 The evaluation evidence for this sub-activity is:
+
+
+a) the ST.
+
+
+11.6.2.3 Action ASE_OBJ.2.1E
+
+
+ASE_OBJ.2.1C _**The statement of security objectives shall describe the security objectives**_
+_**for the TOE and the security objectives for the operational environment.**_
+
+
+ASE_OBJ.2-1 The evaluator _**shall check**_ that the statement of security objectives defines
+the security objectives for the TOE and the security objectives for the
+operational environment.
+
+
+441 The evaluator checks that both categories of security objectives are clearly
+identified and separated from the other category.
+
+
+Page 100 of 430 Version 3.1 April 2017
+
+
+**Class ASE: Security Target evaluation**
+
+
+ASE_OBJ.2.2C _**The security objectives rationale shall trace each security objective for the**_
+_**TOE back to threats countered by that security objective and OSPs**_
+_**enforced by that security objective.**_
+
+
+ASE_OBJ.2-2 The evaluator _**shall check**_ that the security objectives rationale traces all
+security objectives for the TOE back to threats countered by the objectives
+and/or OSPs enforced by the objectives.
+
+
+442 Each security objective for the TOE may trace back to threats or OSPs, or a
+combination of threats and OSPs, but it must trace back to at least one threat
+or OSP.
+
+
+443 Failure to trace implies that either the security objectives rationale is
+incomplete, the security problem definition is incomplete, or the security
+objective for the TOE has no useful purpose.
+
+
+ASE_OBJ.2.3C _**The security objectives rationale shall trace each security objective for the**_
+_**operational environment back to threats countered by that security**_
+_**objective, OSPs enforced by that security objective, and assumptions**_
+_**upheld by that security objective.**_
+
+
+ASE_OBJ.2-3 The evaluator _**shall check**_ that the security objectives rationale traces the
+security objectives for the operational environment back to threats countered
+by that security objective, to OSPs enforced by that security objective, and to
+assumptions upheld by that security objective.
+
+
+444 Each security objective for the operational environment may trace back to
+threats, OSPs, assumptions, or a combination of threats, OSPs and/or
+assumptions, but it must trace back to at least one threat, OSP or assumption.
+
+
+445 Failure to trace implies that either the security objectives rationale is
+incomplete, the security problem definition is incomplete, or the security
+objective for the operational environment has no useful purpose.
+
+
+ASE_OBJ.2.4C _**The security objectives rationale shall demonstrate that the security**_
+_**objectives counter all threats.**_
+
+
+ASE_OBJ.2-4 The evaluator _**shall examine**_ the security objectives rationale to determine
+that it justifies for each threat that the security objectives are suitable to
+counter that threat.
+
+
+446 If no security objectives trace back to the threat, the evaluator action related
+to this work unit is assigned a fail verdict.
+
+
+447 The evaluator determines that the justification for a threat shows whether the
+threat is removed, diminished or mitigated.
+
+
+448 The evaluator determines that the justification for a threat demonstrates that
+the security objectives are sufficient: if all security objectives that trace back
+to the threat are achieved, the threat is removed, sufficiently diminished, or
+the effects of the threat are sufficiently mitigated.
+
+
+April 2017 Version 3.1 Page 101 of 430
+
+
+**Class ASE: Security Target evaluation**
+
+
+449 Note that the tracings from security objectives to threats provided in the
+security objectives rationale may be part of a justification, but do not
+constitute a justification by themselves. Even in the case that a security
+objective is merely a statement reflecting the intent to prevent a particular
+threat from being realised, a justification is required, but this justification
+may be as minimal as โSecurity Objective X directly counters Threat Yโ.
+
+
+450 The evaluator also determines that each security objective that traces back to
+a threat is necessary: when the security objective is achieved it actually
+contributes to the removal, diminishing or mitigation of that threat.
+
+
+ASE_OBJ.2.5C _**The security objectives rationale shall demonstrate that the security**_
+_**objectives enforce all OSPs.**_
+
+
+ASE_OBJ.2-5 The evaluator _**shall examine**_ the security objectives rationale to determine
+that for each OSP it justifies that the security objectives are suitable to
+enforce that OSP.
+
+
+451 If no security objectives trace back to the OSP, the evaluator action related to
+this work unit is assigned a fail verdict.
+
+
+452 The evaluator determines that the justification for an OSP demonstrates that
+the security objectives are sufficient: if all security objectives that trace back
+to that OSP are achieved, the OSP is enforced.
+
+
+453 The evaluator also determines that each security objective that traces back to
+an OSP is necessary: when the security objective is achieved it actually
+contributes to the enforcement of the OSP.
+
+
+454 Note that the tracings from security objectives to OSPs provided in the
+security objectives rationale may be part of a justification, but do not
+constitute a justification by themselves. In the case that a security objective is
+merely a statement reflecting the intent to enforce a particular OSP, a
+justification is required, but this justification may be as minimal as โSecurity
+Objective X directly enforces OSP Yโ.
+
+
+ASE_OBJ.2.6C _**The security objectives rationale shall demonstrate that the security**_
+_**objectives for the operational environment uphold all assumptions.**_
+
+
+ASE_OBJ.2-6 The evaluator _**shall examine**_ the security objectives rationale to determine
+that for each assumption for the operational environment it contains an
+appropriate justification that the security objectives for the operational
+environment are suitable to uphold that assumption.
+
+
+455 If no security objectives for the operational environment trace back to the
+assumption, the evaluator action related to this work unit is assigned a fail
+verdict.
+
+
+456 The evaluator determines that the justification for an assumption about the
+operational environment of the TOE demonstrates that the security objectives
+are sufficient: if all security objectives for the operational environment that
+
+
+Page 102 of 430 Version 3.1 April 2017
+
+
+**Class ASE: Security Target evaluation**
+
+
+trace back to that assumption are achieved, the operational environment
+upholds the assumption.
+
+
+457 The evaluator also determines that each security objective for the operational
+environment that traces back to an assumption about the operational
+environment of the TOE is necessary: when the security objective is
+achieved it actually contributes to the operational environment upholding the
+assumption.
+
+
+458 Note that the tracings from security objectives for the operational
+environment to assumptions provided in the security objectives rationale may
+be a part of a justification, but do not constitute a justification by themselves.
+Even in the case that a security objective of the operational environment is
+merely a restatement of an assumption, a justification is required, but this
+justification may be as minimal as โSecurity Objective X directly upholds
+Assumption Yโ.
+
+
+April 2017 Version 3.1 Page 103 of 430
+
+
+**Class ASE: Security Target evaluation**
+
+## **11.7 Extended components definition (ASE_ECD)**
+
+
+**11.7.1** **Evaluation of sub-activity (ASE_ECD.1)**
+
+
+11.7.1.1 Objectives
+
+
+459 The objective of this sub-activity is to determine whether extended
+components have been clearly and unambiguously defined, and whether they
+are necessary, i.e. they may not be clearly expressed using existing CC Part 2
+or CC Part 3 components.
+
+
+11.7.1.2 Input
+
+
+460 The evaluation evidence for this sub-activity is:
+
+
+a) the ST.
+
+
+11.7.1.3 Action ASE_ECD.1.1E
+
+
+ASE_ECD.1.1C _**The statement of security requirements shall identify all extended security**_
+_**requirements.**_
+
+
+ASE_ECD.1-1 The evaluator _**shall check**_ that all security requirements in the statement of
+security requirements that are not identified as extended requirements are
+present in CC Part 2 or in CC Part 3.
+
+
+ASE_ECD.1.2C _**The extended components definition shall define an extended component**_
+_**for each extended security requirement.**_
+
+
+ASE_ECD.1-2 The evaluator _**shall check**_ that the extended components definition defines
+an extended component for each extended security requirement.
+
+
+461 If the ST does not contain extended security requirements, this work unit is
+not applicable and therefore considered to be satisfied.
+
+
+462 A single extended component may be used to define multiple iterations of an
+extended security requirement, it is not necessary to repeat this definition for
+each iteration.
+
+
+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-3 The evaluator _**shall examine**_ the extended components definition to
+determine that it describes how each extended component fits into the
+existing CC components, families, and classes.
+
+
+463 If the ST does not contain extended security requirements, this work unit is
+not applicable and therefore considered to be satisfied.
+
+
+464 The evaluator determines that each extended component is either:
+
+
+a) a member of an existing CC Part 2 or CC Part 3 family, or
+
+
+Page 104 of 430 Version 3.1 April 2017
+
+
+**Class ASE: Security Target evaluation**
+
+
+b) a member of a new family defined in the ST.
+
+
+465 If the extended component is a member of an existing CC Part 2 or CC Part 3
+family, the evaluator determines that the extended components definition
+adequately describes why the extended component should be a member of
+that family and how it relates to other components of that family.
+
+
+466 If the extended component is a member of a new family defined in the ST,
+the evaluator confirms that the extended component is not appropriate for an
+existing family.
+
+
+467 If the ST defines new families, the evaluator determines that each new family
+is either:
+
+
+a) a member of an existing CC Part 2 or CC Part 3 class, or
+
+
+b) a member of a new class defined in the ST.
+
+
+468 If the family is a member of an existing CC Part 2 or CC Part 3 class, the
+evaluator determines that the extended components definition adequately
+describes why the family should be a member of that class and how it relates
+to other families in that class.
+
+
+469 If the family is a member of a new class defined in the ST, the evaluator
+confirms that the family is not appropriate for an existing class.
+
+
+ASE_ECD.1-4 The evaluator _**shall examine**_ the extended components definition to
+determine that each definition of an extended component identifies all
+applicable dependencies of that component.
+
+
+470 If the ST does not contain extended security requirements, this work unit is
+not applicable and therefore considered to be satisfied.
+
+
+471 The evaluator confirms that no applicable dependencies have been
+overlooked by the ST author.
+
+
+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-5 The evaluator _**shall examine**_ the extended components definition to
+determine that each extended functional component uses the existing CC Part
+2 components as a model for presentation.
+
+
+472 If the ST does not contain extended SFRs, this work unit is not applicable
+and therefore considered to be satisfied.
+
+
+473 The evaluator determines that the extended functional component is
+consistent with CC Part 2 Section 7.1.3, Component structure.
+
+
+474 If the extended functional component uses operations, the evaluator
+determines that the extended functional component is consistent with CC
+Part 1 Section 8.1, Operations.
+
+
+April 2017 Version 3.1 Page 105 of 430
+
+
+**Class ASE: Security Target evaluation**
+
+
+475 If the extended functional component is hierarchical to an existing functional
+component, the evaluator determines that the extended functional component
+is consistent with CC Part 2 Section 7.2.1, Component changes highlighting.
+
+
+ASE_ECD.1-6 The evaluator _**shall examine**_ the extended components definition to
+determine that each definition of a new functional family uses the existing
+CC functional families as a model for presentation.
+
+
+476 If the ST does not define new functional families, this work unit is not
+applicable and therefore considered to be satisfied.
+
+
+477 The evaluator determines that all new functional families are defined
+consistent with CC Part 2 Section 7.1.2, Family structure.
+
+
+ASE_ECD.1-7 The evaluator _**shall examine**_ the extended components definition to
+determine that each definition of a new functional class uses the existing CC
+functional classes as a model for presentation.
+
+
+478 If the ST does not define new functional classes, this work unit is not
+applicable and therefore considered to be satisfied.
+
+
+479 The evaluator determines that all new functional classes are defined
+consistent with CC Part 2 Section 7.1.1, Class structure.
+
+
+ASE_ECD.1-8 The evaluator _**shall examine**_ the extended components definition to
+determine that each definition of an extended assurance component uses the
+existing CC Part 3 components as a model for presentation.
+
+
+480 If the ST does not contain extended SARs, this work unit is not applicable
+and therefore considered to be satisfied.
+
+
+481 The evaluator determines that the extended assurance component definition
+is consistent with CC Part 3 Section 7.1.3, Assurance component structure.
+
+
+482 If the extended assurance component uses operations, the evaluator
+determines that the extended assurance component is consistent with CC Part
+1 Section 8.1, Operations.
+
+
+483 If the extended assurance component is hierarchical to an existing assurance
+component, the evaluator determines that the extended assurance component
+is consistent with CC Part 3 Section 7.1.3, Assurance component structure.
+
+
+ASE_ECD.1-9 The evaluator _**shall examine**_ the extended components definition to
+determine that, for each defined extended assurance component, applicable
+methodology has been provided.
+
+
+484 If the ST does not contain extended SARs, this work unit is not applicable
+and therefore considered to be satisfied.
+
+
+485 The evaluator determines that, for each evaluator action element of each
+extended SAR, one or more work units are provided and that successfully
+
+
+Page 106 of 430 Version 3.1 April 2017
+
+
+**Class ASE: Security Target evaluation**
+
+
+performing all work units for a given evaluator action element will
+demonstrate that the element has been achieved.
+
+
+ASE_ECD.1-10 The evaluator _**shall examine**_ the extended components definition to
+determine that each definition of a new assurance family uses the existing
+CC assurance families as a model for presentation.
+
+
+486 If the ST does not define new assurance families, this work unit is not
+applicable and therefore considered to be satisfied.
+
+
+487 The evaluator determines that all new assurance families are defined
+consistent with CC Part 3 Section 7.1.2, Assurance family structure.
+
+
+ASE_ECD.1-11 The evaluator _**shall examine**_ the extended components definition to
+determine that each definition of a new assurance class uses the existing CC
+assurance classes as a model for presentation.
+
+
+488 If the ST does not define new assurance classes, this work unit is not
+applicable and therefore considered to be satisfied.
+
+
+489 The evaluator determines that all new assurance classes are defined
+consistent with CC Part 3 Section 7.1.1, Assurance class structure.
+
+
+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.**_
+
+
+ASE_ECD.1-12 The evaluator _**shall examine**_ the extended components definition to
+determine that each element in each extended component is measurable and
+states objective evaluation requirements, such that conformance or
+nonconformance can be demonstrated.
+
+
+490 If the ST does not contain extended security requirements, this work unit is
+not applicable and therefore considered to be satisfied.
+
+
+491 The evaluator determines that elements of extended functional components
+are stated in such a way that they are testable, and traceable through the
+appropriate TSF representations.
+
+
+492 The evaluator also determines that elements of extended assurance
+components avoid the need for subjective evaluator judgement.
+
+
+493 The evaluator is reminded that whilst being measurable and objective is
+appropriate for all evaluation criteria, it is acknowledged that no formal
+method exists to prove such properties. Therefore the existing CC functional
+and assurance components are to be used as a model for determining what
+constitutes conformance with this requirement.
+
+
+April 2017 Version 3.1 Page 107 of 430
+
+
+**Class ASE: Security Target evaluation**
+
+
+11.7.1.4 Action ASE_ECD.1.2E
+
+
+ASE_ECD.1-13 The evaluator _**shall examine**_ the extended components definition to
+determine that each extended component can not be clearly expressed using
+existing components.
+
+
+494 If the ST does not contain extended security requirements, this work unit is
+not applicable and therefore considered to be satisfied.
+
+
+495 The evaluator should take components from CC Part 2 and CC Part 3, other
+extended components that have been defined in the ST, combinations of
+these components, and possible operations on these components into account
+when making this determination.
+
+
+496 The evaluator is reminded that the role of this work unit is to preclude
+unnecessary duplication of components, that is, components that may be
+clearly expressed by using other components. The evaluator should not
+undertake an exhaustive search of all possible combinations of components
+including operations in an attempt to find a way to express the extended
+component by using existing components.
+
+
+Page 108 of 430 Version 3.1 April 2017
+
+
+**Class ASE: Security Target evaluation**
+
+## **11.8 Security requirements (ASE_REQ)**
+
+
+**11.8.1** **Evaluation of sub-activity (ASE_REQ.1)**
+
+
+11.8.1.1 Objectives
+
+
+497 The objective of this sub-activity is to determine whether the SFRs and
+SARs are clear, unambiguous and well-defined and whether they are
+internally consistent.
+
+
+11.8.1.2 Input
+
+
+498 The evaluation evidence for this sub-activity is:
+
+
+a) the ST.
+
+
+11.8.1.3 Action ASE_REQ.1.1E
+
+
+ASE_REQ.1.1C _**The statement of security requirements shall describe the SFRs and the**_
+_**SARs.**_
+
+
+ASE_REQ.1-1 The evaluator _**shall check**_ that the statement of security requirements
+describes the SFRs.
+
+
+499 The evaluator determines that each SFR is identified by one of the following
+means:
+
+
+a) by reference to an individual component in CC Part 2;
+
+
+b) by reference to an extended component in the extended components
+definition of the ST;
+
+
+c) by reference to a PP that the ST claims to be conformant with;
+
+
+d) by reference to a security requirements package that the ST claims to
+be conformant with;
+
+
+e) by reproduction in the ST.
+
+
+500 It is not required to use the same means of identification for all SFRs.
+
+
+ASE_REQ.1-2 The evaluator _**shall check**_ that the statement of security requirements
+describes the SARs.
+
+
+501 The evaluator determines that each SAR is identified by one of the following
+means:
+
+
+a) by reference to an individual component in CC Part 3;
+
+
+b) by reference to an extended component in the extended components
+definition of the ST;
+
+
+c) by reference to a PP that the ST claims to be conformant with;
+
+
+April 2017 Version 3.1 Page 109 of 430
+
+
+**Class ASE: Security Target evaluation**
+
+
+d) by reference to a security requirements package that the ST claims to
+be conformant with;
+
+
+e) by reproduction in the ST.
+
+
+502 It is not required to use the same means of identification for all 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-3 The evaluator _**shall examine**_ the ST to determine that all subjects, objects,
+operations, security attributes, external entities and other terms that are used
+in the SFRs and the SARs are defined.
+
+
+503 The evaluator determines that the ST defines all:
+
+
+๏ญ (types of) subjects and objects that are used in the SFRs;
+
+
+๏ญ (types of) security attributes of subjects, users, objects, information,
+sessions and/or resources, possible values that these attributes may
+take and any relations between these values (e.g. top_secret is
+โhigherโ than secret);
+
+
+๏ญ (types of) operations that are used in the SFRs, including the effects
+of these operations;
+
+
+๏ญ (types of) external entities in the SFRs;
+
+
+๏ญ other terms that are introduced in the SFRs and/or SARs by
+completing operations, if these terms are not immediately clear, or
+are used outside their dictionary definition.
+
+
+504 The goal of this work unit is to ensure that the SFRs and SARs are welldefined and that no misunderstanding may occur due to the introduction of
+vague terms. This work unit should not be taken into extremes, by forcing
+the ST writer to define every single word. The general audience of a set of
+security requirements should be assumed to have a reasonable knowledge of
+IT, security and Common Criteria.
+
+
+505 All of the above may be presented in groups, classes, roles, types or other
+groupings or characterisations that allow easy understanding.
+
+
+506 The evaluator is reminded that these lists and definitions do not have to be
+part of the statement of security requirements, but may be placed (in part or
+in whole) in different sections. This may be especially applicable if the same
+terms are used in the rest of the ST.
+
+
+ASE_REQ.1.3C _**The statement of security requirements shall identify all operations on the**_
+_**security requirements.**_
+
+
+ASE_REQ.1-4 The evaluator _**shall check**_ that the statement of security requirements
+identifies all operations on the security requirements.
+
+
+Page 110 of 430 Version 3.1 April 2017
+
+
+**Class ASE: Security Target evaluation**
+
+
+507 The evaluator determines that all operations are identified in each SFR or
+SAR where such an operation is used. Identification may be achieved by
+typographical distinctions, or by explicit identification in the surrounding
+text, or by any other distinctive means.
+
+
+ASE_REQ.1.4C _**All operations shall be performed correctly.**_
+
+
+ASE_REQ.1-5 The evaluator _**shall examine**_ the statement of security requirements to
+determine that all assignment operations are performed correctly.
+
+
+508 Guidance on the correct performance of operations may be found in CC Part
+1 Annex C, Guidance for Operations.
+
+
+ASE_REQ.1-6 The evaluator _**shall examine**_ the statement of security requirements to
+determine that all iteration operations are performed correctly.
+
+
+509 Guidance on the correct performance of operations may be found in CC Part
+1 Annex C, Guidance for Operations.
+
+
+ASE_REQ.1-7 The evaluator _**shall examine**_ the statement of security requirements to
+determine that all selection operations are performed correctly.
+
+
+510 Guidance on the correct performance of operations may be found in CC Part
+1 Annex C, Guidance for Operations.
+
+
+ASE_REQ.1-8 The evaluator _**shall examine**_ the statement of security requirements to
+determine that all refinement operations are performed correctly.
+
+
+511 Guidance on the correct performance of operations may be found in CC Part
+1 Annex C, Guidance for Operations.
+
+
+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.**_
+
+
+ASE_REQ.1-9 The evaluator _**shall examine**_ the statement of security requirements to
+determine that each dependency of the security requirements is either
+satisfied, or that a security requirements rationale is provided which justifies
+the dependency not being satisfied.
+
+
+512 A dependency is satisfied by the inclusion of the relevant component (or one
+that is hierarchical to it) within the statement of security requirements. The
+component used to satisfy the dependency should, if necessary, be modified
+by operations to ensure that it actually satisfies that dependency.
+
+
+513 A justification that a dependency is not met should address either:
+
+
+a) why the dependency is not necessary or useful, in which case no
+further information is required; or
+
+
+b) that the dependency has been addressed by the operational
+environment of the TOE, in which case the justification should
+
+
+April 2017 Version 3.1 Page 111 of 430
+
+
+**Class ASE: Security Target evaluation**
+
+
+describe how the security objectives for the operational environment
+address this dependency.
+
+
+ASE_REQ.1.6C _**The statement of security requirements shall be internally consistent.**_
+
+
+ASE_REQ.1-10 The evaluator _**shall examine**_ the statement of security requirements to
+determine that it is internally consistent.
+
+
+514 The evaluator determines that the combined set of all SFRs and SARs is
+internally consistent.
+
+
+515 The evaluator determines that on all occasions where different security
+requirements apply to the same types of developer evidence, events,
+operations, data, tests to be performed etc. or to โall objectsโ, โall subjectsโ
+etc., that these requirements do not conflict.
+
+
+516 Some possible conflicts are:
+
+
+a) an extended SAR specifying that the design of a certain
+cryptographic algorithm is to be kept secret, and another extended
+SAR specifying an open source review;
+
+
+b) FAU_GEN.1 Audit data generation specifying that subject identity is
+to be logged, FDP_ACC.1 Subset access control specifying who has
+access to these logs, and FPR_UNO.1 Unobservability specifying
+that some actions of subjects should be unobservable to other subjects.
+If the subject that should not be able to see an activity may access
+logs of this activity, these SFRs conflict;
+
+
+c) FDP_RIP.1 Subset residual information protection specifying
+deletion of information no longer needed, and FDP_ROL.1 Basic
+rollback specifying that a TOE may return to a previous state. If the
+information that is needed for the rollback to the previous state has
+been deleted, these requirements conflict;
+
+
+d) Multiple iterations of FDP_ACC.1 Subset access control especially
+where some iterations cover the same subjects, objects, or operations.
+If one access control SFR allows a subject to perform an operation on
+an object, while another access control SFR does not allow this, these
+requirements conflict.
+
+
+**11.8.2** **Evaluation of sub-activity (ASE_REQ.2)**
+
+
+11.8.2.1 Objectives
+
+
+517 The objective of this sub-activity is to determine whether the SFRs and
+SARs are clear, unambiguous and well-defined, whether they are internally
+consistent, and whether the SFRs meet the security objectives of the TOE.
+
+
+11.8.2.2 Input
+
+
+518 The evaluation evidence for this sub-activity is:
+
+
+Page 112 of 430 Version 3.1 April 2017
+
+
+**Class ASE: Security Target evaluation**
+
+
+a) the ST.
+
+
+11.8.2.3 Action ASE_REQ.2.1E
+
+
+ASE_REQ.2.1C _**The statement of security requirements shall describe the SFRs and the**_
+_**SARs.**_
+
+
+ASE_REQ.2-1 The evaluator _**shall check**_ that the statement of security requirements
+describes the SFRs.
+
+
+519 The evaluator determines that each SFRs is identified by one of the
+following means:
+
+
+a) by reference to an individual component in CC Part 2;
+
+
+b) by reference to an extended component in the extended components
+definition of the ST;
+
+
+c) by reference to an individual component in a PP that the ST claims to
+be conformant with;
+
+
+d) by reference to an individual component in a security requirements
+package that the ST claims to be conformant with;
+
+
+e) by reproduction in the ST.
+
+
+520 It is not required to use the same means of identification for all SFRs.
+
+
+ASE_REQ.2-2 The evaluator _**shall check**_ that the statement of security requirements
+describes the SARs.
+
+
+521 The evaluator determines that all SARs are identified by one of the following
+means:
+
+
+a) by reference to an individual component in CC Part 3;
+
+
+b) by reference to an extended component in the extended components
+definition of the ST;
+
+
+c) by reference to an individual component in a PP that the ST claims to
+be conformant with;
+
+
+d) by reference to an individual component in a security requirements
+package that the ST claims to be conformant with;
+
+
+e) by reproduction in the ST.
+
+
+522 It is not required to use the same means of identification for all SARs.
+
+
+ASE_REQ.2.2C _**All subjects, objects, operations, security attributes, external entities and**_
+_**other terms that are used in the SFRs and the SARs shall be defined.**_
+
+
+April 2017 Version 3.1 Page 113 of 430
+
+
+**Class ASE: Security Target evaluation**
+
+
+ASE_REQ.2-3 The evaluator _**shall examine**_ the ST to determine that all subjects, objects,
+operations, security attributes, external entities and other terms that are used
+in the SFRs and the SARs are defined.
+
+
+523 The evaluator determines that the ST defines all:
+
+
+๏ญ (types of) subjects and objects that are used in the SFRs;
+
+
+๏ญ (types of) security attributes of subjects, users, objects, information,
+sessions and/or resources, possible values that these attributes may
+take and any relations between these values (e.g. top_secret is
+โhigherโ than secret);
+
+
+๏ญ (types of) operations that are used in the SFRs, including the effects
+of these operations;
+
+
+๏ญ (types of) external entities in the SFRs;
+
+
+๏ญ other terms that are introduced in the SFRs and/or SARs by
+completing operations, if these terms are not immediately clear, or
+are used outside their dictionary definition.
+
+
+524 The goal of this work unit is to ensure that the SFRs and SARs are welldefined and that no misunderstanding may occur due to the introduction of
+vague terms. This work unit should not be taken into extremes, by forcing
+the ST writer to define every single word. The general audience of a set of
+security requirements should be assumed to have a reasonable knowledge of
+IT, security and Common Criteria.
+
+
+525 All of the above may be presented in groups, classes, roles, types or other
+groupings or characterisations that allow easy understanding.
+
+
+526 The evaluator is reminded that these lists and definitions do not have to be
+part of the statement of security requirements, but may be placed (in part or
+in whole) in different sections. This may be especially applicable if the same
+terms are used in the rest of the ST.
+
+
+ASE_REQ.2.3C _**The statement of security requirements shall identify all operations on the**_
+_**security requirements.**_
+
+
+ASE_REQ.2-4 The evaluator _**shall check**_ that the statement of security requirements
+identifies all operations on the security requirements.
+
+
+527 The evaluator determines that all operations are identified in each SFR or
+SAR where such an operation is used. Identification may be achieved by
+typographical distinctions, or by explicit identification in the surrounding
+text, or by any other distinctive means.
+
+
+ASE_REQ.2.4C _**All operations shall be performed correctly.**_
+
+
+ASE_REQ.2-5 The evaluator _**shall examine**_ the statement of security requirements to
+determine that all assignment operations are performed correctly.
+
+
+Page 114 of 430 Version 3.1 April 2017
+
+
+**Class ASE: Security Target evaluation**
+
+
+528 Guidance on the correct performance of operations may be found in CC Part
+1 Annex C, Guidance for Operations.
+
+
+ASE_REQ.2-6 The evaluator _**shall examine**_ the statement of security requirements to
+determine that all iteration operations are performed correctly.
+
+
+529 Guidance on the correct performance of operations may be found in CC Part
+1 Annex C, Guidance for Operations.
+
+
+ASE_REQ.2-7 The evaluator _**shall examine**_ the statement of security requirements to
+determine that all selection operations are performed correctly.
+
+
+530 Guidance on the correct performance of operations may be found in CC Part
+1 Annex C, Guidance for Operations.
+
+
+ASE_REQ.2-8 The evaluator _**shall examine**_ the statement of security requirements to
+determine that all refinement operations are performed correctly.
+
+
+531 Guidance on the correct performance of operations may be found in CC Part
+1 Annex C, Guidance for Operations.
+
+
+ASE_REQ.2.5C _**Each dependency of the security requirements shall either be satisfied, or**_
+_**the security requirements rationale shall justify the dependency not being**_
+_**satisfied.**_
+
+
+ASE_REQ.2-9 The evaluator _**shall examine**_ the statement of security requirements to
+determine that each dependency of the security requirements is either
+satisfied, or that the security requirements rationale justifies the dependency
+not being satisfied.
+
+
+532 A dependency is satisfied by the inclusion of the relevant component (or one
+that is hierarchical to it) within the statement of security requirements. The
+component used to satisfy the dependency should, if necessary, be modified
+by operations to ensure that it actually satisfies that dependency.
+
+
+533 A justification that a dependency is not met should address either:
+
+
+a) why the dependency is not necessary or useful, in which case no
+further information is required; or
+
+
+b) that the dependency has been addressed by the operational
+environment of the TOE, in which case the justification should
+describe how the security objectives for the operational environment
+address this dependency.
+
+
+ASE_REQ.2.6C _**The security requirements rationale shall trace each SFR back to the**_
+_**security objectives for the TOE.**_
+
+
+ASE_REQ.2-10 The evaluator _**shall check**_ that the security requirements rationale traces each
+SFR back to the security objectives for the TOE.
+
+
+April 2017 Version 3.1 Page 115 of 430
+
+
+**Class ASE: Security Target evaluation**
+
+
+534 The evaluator determines that each SFR is traced back to at least one security
+objective for the TOE.
+
+
+535 Failure to trace implies that either the security requirements rationale is
+incomplete, the security objectives for the TOE are incomplete, or the SFR
+has no useful purpose.
+
+
+ASE_REQ.2.7C _**The security requirements rationale shall demonstrate that the SFRs meet**_
+_**all security objectives for the TOE.**_
+
+
+ASE_REQ.2-11 The evaluator _**shall examine**_ the security requirements rationale to determine
+that for each security objective for the TOE it demonstrates that the SFRs are
+suitable to meet that security objective for the TOE.
+
+
+536 If no SFRs trace back to the security objective for the TOE, the evaluator
+action related to this work unit is assigned a fail verdict.
+
+
+537 The evaluator determines that the justification for a security objective for the
+TOE demonstrates that the SFRs are sufficient: if all SFRs that trace back to
+the objective are satisfied, the security objective for the TOE is achieved.
+
+
+538 The evaluator also determines that each SFR that traces back to a security
+objective for the TOE is necessary: when the SFR is satisfied, it actually
+contributes to achieving the security objective.
+
+
+539 Note that the tracings from SFRs to security objectives for the TOE provided
+in the security requirements rationale may be a part of the justification, but
+do not constitute a justification by themselves.
+
+
+ASE_REQ.2.8C _**The security requirements rationale shall explain why the SARs were**_
+_**chosen.**_
+
+
+ASE_REQ.2-12 The evaluator _**shall check**_ that the security requirements rationale explains
+why the SARs were chosen.
+
+
+540 The evaluator is reminded that any explanation is correct, as long as it is
+coherent and neither the SARs nor the explanation have obvious
+inconsistencies with the remainder of the ST.
+
+
+541 An example of an obvious inconsistency between the SARs and the
+remainder of the ST would be to have threat agents that are very capable, but
+an AVA_VAN SAR that does not protect against these threat agents.
+
+
+ASE_REQ.2.9C _**The statement of security requirements shall be internally consistent.**_
+
+
+ASE_REQ.2-13 The evaluator _**shall examine**_ the statement of security requirements to
+determine that it is internally consistent.
+
+
+542 The evaluator determines that the combined set of all SFRs and SARs is
+internally consistent.
+
+
+Page 116 of 430 Version 3.1 April 2017
+
+
+**Class ASE: Security Target evaluation**
+
+
+543 The evaluator determines that on all occasions where different security
+requirements apply to the same types of developer evidence, events,
+operations, data, tests to be performed etc. or to โall objectsโ, โall subjectsโ
+etc., that these requirements do not conflict.
+
+
+544 Some possible conflicts are:
+
+
+a) an extended SAR specifying that the design of a certain
+cryptographic algorithm is to be kept secret, and another extended
+assurance requirement specifying an open source review;
+
+
+b) FAU_GEN.1 Audit data generation specifying that subject identity is
+to be logged, FDP_ACC.1 Subset access control specifying who has
+access to these logs, and FPR_UNO.1 Unobservability specifying
+that some actions of subjects should be unobservable to other subjects.
+If the subject that should not be able to see an activity may access
+logs of this activity, these SFRs conflict;
+
+
+c) FDP_RIP.1 Subset residual information protection specifying
+deletion of information no longer needed, and FDP_ROL.1 Basic
+rollback specifying that a TOE may return to a previous state. If the
+information that is needed for the rollback to the previous state has
+been deleted, these requirements conflict;
+
+
+d) Multiple iterations of FDP_ACC.1 Subset access control especially
+where some iterations cover the same subjects, objects, or operations.
+If one access control SFR allows a subject to perform an operation on
+an object, while another access control SFR does not allow this, these
+requirements conflict.
+
+
+April 2017 Version 3.1 Page 117 of 430
+
+
+**Class ASE: Security Target evaluation**
+
+## **11.9 TOE summary specification (ASE_TSS)**
+
+
+**11.9.1** **Evaluation of sub-activity (ASE_TSS.1)**
+
+
+11.9.1.1 Objectives
+
+
+545 The objective of this sub-activity is to determine whether the TOE summary
+specification addresses all SFRs, and whether the TOE summary
+specification is consistent with other narrative descriptions of the TOE.
+
+
+11.9.1.2 Input
+
+
+546 The evaluation evidence for this sub-activity is:
+
+
+a) the ST.
+
+
+11.9.1.3 Action ASE_TSS.1.1E
+
+
+ASE_TSS.1.1C _**The TOE summary specification shall describe how the TOE meets each**_
+_**SFR.**_
+
+
+ASE_TSS.1-1 The evaluator _**shall examine**_ the TOE summary specification to determine
+that it describes how the TOE meets each SFR.
+
+
+547 The evaluator determines that the TOE summary specification provides, for
+each SFR from the statement of security requirements, a description on how
+that SFR is met.
+
+
+548 The evaluator is reminded that the objective of each description is to provide
+potential consumers of the TOE with a high-level view of how the developer
+intends to satisfy each SFR and that the descriptions therefore should not be
+overly detailed. Often several SFRs will be implemented in one context; for
+instance a password authentication mechanism may implement FIA_UAU.1,
+FIA_SOS.1 and FIA_UID.1. Therefore usually the TSS will not consist of a
+long list with texts for each single SFR, but complete groups of SFRs may be
+covered by one text passage.
+
+
+549 For a composed TOE, the evaluator also determines that it is clear which
+component provides each SFR or how the components combine to meet each
+SFR.
+
+
+11.9.1.4 Action ASE_TSS.1.2E
+
+
+ASE_TSS.1-2 The evaluator _**shall examine**_ the TOE summary specification to determine
+that it is consistent with the TOE overview and the TOE description.
+
+
+550 The TOE overview, TOE description, and TOE summary specification
+describe the TOE in a narrative form at increasing levels of detail. These
+descriptions therefore need to be consistent.
+
+
+Page 118 of 430 Version 3.1 April 2017
+
+
+**Class ASE: Security Target evaluation**
+
+
+**11.9.2** **Evaluation of sub-activity (ASE_TSS.2)**
+
+
+11.9.2.1 Objectives
+
+
+551 The objective of this sub-activity is to determine whether the TOE summary
+specification addresses all SFRs, whether the TOE summary specification
+addresses interference, logical tampering and bypass, and whether the TOE
+summary specification is consistent with other narrative descriptions of the
+TOE.
+
+
+11.9.2.2 Input
+
+
+552 The evaluation evidence for this sub-activity is:
+
+
+a) the ST.
+
+
+11.9.2.3 Action ASE_TSS.2.1E
+
+
+ASE_TSS.2.1C _**The TOE summary specification shall describe how the TOE meets each**_
+_**SFR.**_
+
+
+ASE_TSS.2-1 The evaluator _**shall examine**_ the TOE summary specification to determine
+that it describes how the TOE meets each SFR.
+
+
+553 The evaluator determines that the TOE summary specification provides, for
+each SFR from the statement of security requirements, a description on how
+that SFR is met.
+
+
+554 The evaluator is reminded that the objective of each description is to provide
+potential consumers of the TOE with a high-level view of how the developer
+intends to satisfy each SFR and that the descriptions therefore should not be
+overly detailed. Often several SFRs will be implemented in one context; for
+instance a password authentication mechanism may implement FIA_UAU.1,
+FIA_SOS.1 and FIA_UID.1. Therefore usually the TSS will not consist of a
+long list with texts for each single SFR, but complete groups of SFRs may be
+covered by one text passage.
+
+
+555 For a composed TOE, the evaluator also determines that it is clear which
+component provides each SFR or how the components combine to meet each
+SFR.
+
+
+ASE_TSS.2.2C _**The TOE summary specification shall describe how the TOE protects itself**_
+_**against interference and logical tampering.**_
+
+
+ASE_TSS.2-2 The evaluator _**shall examine**_ the TOE summary specification to determine
+that it describes how the TOE protects itself against interference and logical
+tampering.
+
+
+556 The evaluator is reminded that the objective of each description is to provide
+potential consumers of the TOE with a high-level view of how the developer
+intends to provide protection against interference and logical tampering and
+that the descriptions therefore should not be overly detailed.
+
+
+April 2017 Version 3.1 Page 119 of 430
+
+
+**Class ASE: Security Target evaluation**
+
+
+557 For a composed TOE, the evaluator also determines that it is clear which
+component provides the protection or how the components combine to
+provide protection.
+
+
+ASE_TSS.2.3C _**The TOE summary specification shall describe how the TOE protects itself**_
+_**against bypass.**_
+
+
+ASE_TSS.2-3 The evaluator _**shall examine**_ the TOE summary specification to determine
+that it describes how the TOE protects itself against bypass.
+
+
+558 The evaluator is reminded that the objective of each description is to provide
+potential consumers of the TOE with a high-level view of how the developer
+intends to provide protection against bypass and that the descriptions
+therefore should not be overly detailed.
+
+
+559 For a composed TOE, the evaluator also determines that it is clear which
+component provides the protection or how the components combine to
+provide protection.
+
+
+11.9.2.4 Action ASE_TSS.2.2E
+
+
+ASE_TSS.2-4 The evaluator _**shall examine**_ the TOE summary specification to determine
+that it is consistent with the TOE overview and the TOE description.
+
+
+560 The TOE overview, TOE description, and TOE summary specification
+describe the TOE in a narrative form at increasing levels of detail. These
+descriptions therefore need to be consistent.
+
+
+Page 120 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+# **12 Class ADV: Development**
+
+## **12.1 Introduction**
+
+
+561 The purpose of the development activity is to assess the design
+documentation in terms of its adequacy to understand how the TSF meets the
+SFRs and how the implementation of these SFRs cannot be tampered with or
+bypassed. This understanding is achieved through examination of
+increasingly refined descriptions of the TSF design documentation. Design
+documentation consists of a functional specification (which describes the
+interfaces of the TSF), a TOE design description (which describes the
+architecture of the TSF in terms of how it works in order to perform the
+functions related to the SFRs being claimed), and an implementation
+description (a source code level description). In addition, there is a security
+architecture description (which describes the architectural properties of the
+TSF to explain how its security enforcement cannot be compromised or
+bypassed), an internals description (which describes how the TSF was
+constructed in a manner that encourages understandability), and a security
+policy model (which formally describes the security policies enforced by the
+TSF).
+
+## **12.2 Application notes**
+
+
+562 The CC requirements for design documentation are levelled by the amount,
+and detail of information provided, and the degree of formality of the
+presentation of the information. At lower levels, the most security-critical
+portions of the TSF are described with the most detail, while less securitycritical portions of the TSF are merely summarised; added assurance is
+gained by increasing the amount of information about the most securitycritical portions of the TSF, and increasing the details about the less securitycritical portions. The most assurance is achieved when thorough details and
+information of all portions are provided.
+
+
+563 The CC considers a document's degree of formality (that is, whether it is
+informal or semiformal) to be hierarchical. An informal document is one that
+is expressed in a natural language. The methodology does not dictate the
+specific language that must be used; that issue is left for the scheme. The
+following paragraphs differentiate the contents of the different informal
+documents.
+
+
+564 A functional specification provides a description of the purpose and methodof-use of interfaces to the TSF. For example, if an operating system presents
+the user with a means of self-identification, of creating files, of modifying or
+deleting files, of setting permissions defining what other users may access
+files, and of communicating with remote machines, its functional
+specification would contain descriptions of each of these and how they are
+realised through interactions with the externally-visible interfaces to the TSF.
+If there is also audit functionality that detects and record the occurrences of
+such events, descriptions of this audit functionality would also be expected to
+
+
+April 2017 Version 3.1 Page 121 of 430
+
+
+**Class ADV: Development**
+
+
+be part of the functional specification; while this functionality is technically
+not directly invoked by the user at the external interface, it certainly is
+affected by what occurs at the user's external interface.
+
+
+565 A design description is expressed in terms of logical divisions (subsystems
+or modules) that each provide a comprehensible service or function. For
+example, a firewall might be composed of subsystems that deal with packet
+filtering, with remote administration, with auditing, and with connectionlevel filtering. The design description of the firewall would describe the
+actions that are taken, in terms of what actions each subsystem takes when an
+incoming packet arrives at the firewall.
+
+
+Page 122 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+## **12.3 Security Architecture (ADV_ARC)**
+
+
+**12.3.1** **Evaluation of sub-activity (ADV_ARC.1)**
+
+
+12.3.1.1 Objectives
+
+
+566 The objective of this sub-activity is to determine whether the TSF is
+structured such that it cannot be tampered with or bypassed, and whether
+TSFs that provide security domains isolate those domains from each other.
+
+
+12.3.1.2 Input
+
+
+567 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the functional specification;
+
+
+c) the TOE design;
+
+
+d) the security architecture description;
+
+
+e) the implementation representation (if available);
+
+
+f) the operational user guidance;
+
+
+12.3.1.3 Application notes
+
+
+568 The notions of self-protection, domain separation, and non-bypassability are
+distinct from security functionality expressed in Part 2 SFRs because selfprotection and non-bypassability largely have no directly observable
+interface at the TSF. Rather, they are properties of the TSF that are achieved
+through the design of the TOE, and enforced by the correct implementation
+of that design. Also, the evaluation of these properties is less straight-forward
+than the evaluation of mechanisms; it is more difficult to check for the
+absence of functionality than for its presence. However, the determination
+that these properties are being satisfied is just as critical as the determination
+that the mechanisms are properly implemented.
+
+
+569 The overall approach used is that the developer provides a TSF that meets
+the above-mentioned properties, and provides evidence (in the form of
+documentation) that can be analysed to show that the properties are indeed
+met. The evaluator has the responsibility for looking at the evidence and,
+coupled with other evidence delivered for the TOE, determining that the
+properties are achieved. The work units can be characterised as those
+detailing with what information has to be provided, and those dealing with
+the actual analysis the evaluator performs.
+
+
+570 The security architecture description describes how domains are defined and
+how the TSF keeps them separate. It describes what prevents untrusted
+processes from getting to the TSF and modifying it. It describes what ensures
+that all resources under the TSF's control are adequately protected and that
+
+
+April 2017 Version 3.1 Page 123 of 430
+
+
+**Class ADV: Development**
+
+
+all actions related to the SFRs are mediated by the TSF. It explains any role
+the environment plays in any of these (e.g. presuming it gets correctly
+invoked by its underlying environment, how is its security functionality
+invoked?). In short, it explains how the TOE is considered to be providing
+any kind of _security_ service.
+
+
+571 The analyses the evaluator performs must be done in the context of all of the
+development evidence provided for the TOE, at the level of detail the
+evidence is provided. At lower assurance levels there should not be the
+expectation that, for example, TSF self-protection is completely analysed,
+because only high-level design representations will be available. The
+evaluator also needs to be sure to use information gleaned from other
+portions of their analysis (e.g., analysis of the TOE design) in making their
+assessments for the properties being examined in the following work units.
+
+
+12.3.1.4 Action ADV_ARC.1.1E
+
+
+ADV_ARC.1.1C _**The security architecture description shall be at a level of detail**_
+_**commensurate with the description of the SFR-enforcing abstractions**_
+_**described in the TOE design document.**_
+
+
+ADV_ARC.1-1 The evaluator _**shall examine**_ the security architecture description to
+determine that the information provided in the evidence is presented at a
+level of detail commensurate with the descriptions of the SFR-enforcing
+abstractions contained in the functional specification and TOE design
+document.
+
+
+572 With respect to the functional specification, the evaluator should ensure that
+the self-protection functionality described cover those effects that are evident
+at the TSFI. Such a description might include protection placed upon the
+executable images of the TSF, and protection placed on objects (e.g., files
+used by the TSF). The evaluator ensures that the functionality that might be
+invoked through the TSFI is described.
+
+
+573 If Evaluation of sub-activity (ADV_TDS.1) or Evaluation of sub-activity
+(ADV_TDS.2) is included, the evaluator ensures the security architecture
+description contains information on how any subsystems that contribute to
+TSF domain separation work.
+
+
+574 If Evaluation of sub-activity (ADV_TDS.3) or higher is available, the
+evaluator ensures that the security architecture description also contains
+implementation-dependent information. For example, such a description
+might contain information pertaining to coding conventions for parameter
+checking that would prevent TSF compromises (e.g. buffer overflows), and
+information on stack management for call and return operations. The
+evaluator checks the descriptions of the mechanisms to ensure that the level
+of detail is such that there is little ambiguity between the description in the
+security architecture description and the implementation representation.
+
+
+575 The evaluator action related to this work unit is assigned a fail verdict if the
+security architecture description mentions any module, subsystem, or
+
+
+Page 124 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+interface that is not described in the functional specification or TOE design
+document.
+
+
+ADV_ARC.1.2C _**The security architecture description shall describe the security domains**_
+_**maintained by the TSF consistently with the SFRs.**_
+
+
+ADV_ARC.1-2 The evaluator _**shall examine**_ the security architecture description to
+determine that it describes the security domains maintained by the TSF.
+
+
+576 Security domains refer to environments supplied by the TSF for use by
+potentially-harmful entities; for example, a typical secure operating system
+supplies a set of resources (address space, per-process environment
+variables) for use by processes with limited access rights and security
+properties. The evaluator determines that the developer's description of the
+security domains takes into account all of the SFRs claimed by the TOE.
+
+
+577 For some TOEs such domains do not exist because all of the interactions
+available to users are severely constrained by the TSF. A packet-filter
+firewall is an example of such a TOE. Users on the LAN or WAN do not
+interact with the TOE, so there need be no security domains; there are only
+data structures maintained by the TSF to keep the users' packets separated.
+The evaluator ensures that any claim that there are no domains is supported
+by the evidence and that no such domains are, in fact, available.
+
+
+ADV_ARC.1.3C _**The security architecture description shall describe how the TSF**_
+_**initialisation process is secure.**_
+
+
+ADV_ARC.1-3 The evaluator _**shall examine**_ the security architecture description to
+determine that the initialisation process preserves security.
+
+
+578 The information provided in the security architecture description relating to
+TSF initialisation is directed at the TOE components that are involved in
+bringing the TSF into an initial secure state (i.e. when all parts of the TSF are
+operational) when power-on or a reset is applied. This discussion in the
+security architecture description should list the system initialisation
+components and the processing that occurs in transitioning from the โdownโ
+state to the initial secure state.
+
+
+579 It is often the case that the components that perform this initialisation
+function are not accessible after the secure state is achieved; if this is the case
+then the security architecture description identifies the components and
+explains how they are not reachable by untrusted entities after the TSF has
+been established. In this respect, the property that needs to be preserved is
+that these components either 1) cannot be accessed by untrusted entities after
+the secure state is achieved, or 2) if they provide interfaces to untrusted
+entities, these TSFI cannot be used to tamper with the TSF.
+
+
+580 The TOE components related to TSF initialisation, then, are treated
+themselves as part of the TSF, and analysed from that perspective. It should
+be noted that even though these are treated as part of the TSF, it is likely that
+
+
+April 2017 Version 3.1 Page 125 of 430
+
+
+**Class ADV: Development**
+
+
+a justification (as allowed by TSF internals (ADV_INT)) can be made that
+they do not have to meet the internal structuring requirements of ADV_INT.
+
+
+ADV_ARC.1.4C _**The security architecture description shall demonstrate that the TSF**_
+_**protects itself from tampering.**_
+
+
+ADV_ARC.1-4 The evaluator _**shall examine**_ the security architecture description to
+determine that it contains information sufficient to support a determination
+that the TSF is able to protect itself from tampering by untrusted active
+entities.
+
+
+581 โSelf-protectionโ refers to the ability of the TSF to protect itself from
+manipulation from external entities that may result in changes to the TSF.
+For TOEs that have dependencies on other IT entities, it is often the case that
+the TOE uses services supplied by the other IT entities in order to perform its
+functions. In such cases, the TSF alone does not protect itself because it
+depends on the other IT entities to provide some of the protection. For the
+purposes of the security architecture description, the notion of _self-protection_
+applies only to the services provided by the TSF through its TSFI, and not to
+services provided by underlying IT entities that it uses.
+
+
+582 Self-protection is typically achieved by a variety of means, ranging from
+physical and logical restrictions on access to the TOE; to hardware-based
+means (e.g. โexecution ringsโ and memory management functionality); to
+software-based means (e.g. boundary checking of inputs on a trusted server).
+The evaluator determines that all such mechanisms are described.
+
+
+583 The evaluator determines that the design description covers how user input is
+handled by the TSF in such a way that the TSF does not subject itself to
+being corrupted by that user input. For example, the TSF might implement
+the notion of privilege and protect itself by using privileged-mode routines to
+handle user input. The TSF might make use of processor-based separation
+mechanisms such as privilege levels or rings. The TSF might implement
+software protection constructs or coding conventions that contribute to
+implementing separation of software domains, perhaps by delineating user
+address space from system address space. And the TSF might have reliance
+its environment to provide some support to the protection of the TSF.
+
+
+584 All of the mechanisms contributing to the domain separation functions are
+described. The evaluator should use knowledge gained from other evidence
+(functional specification, TOE design, TSF internals description, other parts
+of the security architecture description, or implementation representation, as
+included in the assurance package for the TOE) in determining if any
+functionality contributing to self-protection was described that is not present
+in the security architecture description.
+
+
+585 Accuracy of the description of the self-protection mechanisms is the property
+that the description faithfully describes what is implemented. The evaluator
+should use other evidence (functional specification, TOE design, TSF
+Internals documentation, other parts of the security architecture description,
+implementation representation, as included in the ST for the TOE) in
+
+
+Page 126 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+determining whether there are discrepancies in any descriptions of the selfprotection mechanisms. If Implementation representation (ADV_IMP) is
+included in the assurance package for the TOE, the evaluator will choose a
+sample of the implementation representation; the evaluator should also
+ensure that the descriptions are accurate for the sample chosen. If an
+evaluator cannot understand how a certain self-protection mechanism works
+or could work in the system architecture, it may be the case that the
+description is not accurate.
+
+
+ADV_ARC.1.5C _**The security architecture description shall demonstrate that the TSF**_
+_**prevents bypass of the SFR-enforcing functionality.**_
+
+
+ADV_ARC.1-5 The evaluator _**shall examine**_ the security architecture description to
+determine that it presents an analysis that adequately describes how the SFRenforcing mechanisms cannot be bypassed.
+
+
+586 Non-bypassability is a property that the security functionality of the TSF (as
+specified by the SFRs) is always invoked. For example, if access control to
+files is specified as a capability of the TSF via an SFR, there must be no
+interfaces through which files can be accessed without invoking the TSF's
+access control mechanism (such as an interface through which a raw disk
+access takes place).
+
+
+587 Describing how the TSF mechanisms cannot be bypassed generally requires
+a systematic argument based on the TSF and the TSFIs. The description of
+how the TSF works (contained in the design decomposition evidence, such
+as the functional specification, TOE design documentation) - along with the
+information in the TSS - provides the background necessary for the evaluator
+to understand what resources are being protected and what security functions
+are being provided. The functional specification provides descriptions of the
+TSFIs through which the resources/functions are accessed.
+
+
+588 The evaluator assesses the description provided (and other information
+provided by the developer, such as the functional specification) to ensure that
+no available interface can be used to bypass the TSF. This means that every
+available interface must be either unrelated to the SFRs that are claimed in
+the ST (and does not interact with anything that is used to satisfy SFRs) or
+else uses the security functionality that is described in other development
+evidence in the manner described. For example, a game would likely be
+unrelated to the SFRs, so there must be an explanation of how it cannot
+affect security. Access to user data, however, is likely to be related to access
+control SFRs, so the explanation would describe how the security
+functionality works when invoked through the data-access interfaces. Such a
+description is needed for every available interface.
+
+
+589 An example of a description follows. Suppose the TSF provides file
+protection. Further suppose that although the โtraditionalโ system call TSFIs
+for open, read, and write invoke the file protection mechanism described in
+the TOE design, there exists a TSFI that allows access to a batch job facility
+(creating batch jobs, deleting jobs, modifying unprocessed jobs). The
+evaluator should be able to determine from the vendor-provided description
+
+
+April 2017 Version 3.1 Page 127 of 430
+
+
+**Class ADV: Development**
+
+
+that this TSFI invokes the same protection mechanisms as do the
+โtraditionalโ interfaces. This could be done, for example, by referencing the
+appropriate sections of the TOE design that discuss _how_ the batch job facility
+TSFI achieves its security objectives.
+
+
+590 Using this same example, suppose there is a TSFI whose sole purpose is to
+display the time of day. The evaluator should determine that the description
+adequately argues that this TSFI is not capable of manipulating any protected
+resources and should not invoke any security functionality.
+
+
+591 Another example of bypass is when the TSF is supposed to maintain
+confidentiality of a cryptographic key (one is allowed to use it for
+cryptographic operations, but is not allowed to read/write it). If an attacker
+has direct physical access to the device, he might be able to examine sidechannels such as the power usage of the device, the exact timing of the
+device, or even any electromagnetic emanations of the device and, from this,
+infer the key.
+
+
+592 If such side-channels may be present, the demonstration should address the
+mechanisms that prevent these side-channels from occurring, such as random
+internal clocks, dual-line technology etc. Verification of these mechanisms
+would be verified by a combination of purely design-based arguments and
+testing.
+
+
+593 For a final example using security functionality rather than a protected
+resource, consider an ST that contains FCO_NRO.2 Enforced proof of origin,
+which requires that the TSF provides evidence of origination for information
+types specified in the ST. Suppose that the โinformation typesโ included all
+information that is sent by the TOE via e-mail. In this case the evaluator
+should examine the description to ensure that all TSFI that can be invoked to
+send e-mail perform the โevidence of origination generationโ function are
+detailed. The description might point to user guidance to show all places
+where e-mail can originate (e.g., e-mail program, notification from
+scripts/batch jobs) and then how each of these places invokes the evidence
+generation function.
+
+
+594 The evaluator should also ensure that the description is comprehensive, in
+that each interface is analysed with respect to the entire set of claimed SFRs.
+This may require the evaluator to examine supporting information
+(functional specification, TOE design, other parts of the security architecture
+description, operational user guidance, and perhaps even the implementation
+representation, as provided for the TOE) to determine that the description has
+correctly capture all aspects of an interface. The evaluator should consider
+what SFRs each TSFI might affect (from the description of the TSFI and its
+implementation in the supporting documentation), and then examine the
+description to determine whether it covers those aspects.
+
+
+Page 128 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+## **12.4 Functional specification (ADV_FSP)**
+
+
+**12.4.1** **Evaluation of sub-activity (ADV_FSP.1)**
+
+
+12.4.1.1 Objectives
+
+
+595 The objective of this sub-activity is to determine whether the developer has
+provided a high-level description of at least the SFR-enforcing and SFRsupporting TSFIs, in terms of descriptions of their parameters. There is no
+other required evidence that can be expected to be available to measure the
+accuracy of these descriptions; the evaluator merely ensures the descriptions
+seem plausible.
+
+
+12.4.1.2 Input
+
+
+596 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the functional specification;
+
+
+c) the operational user guidance;
+
+
+12.4.1.3 Action ADV_FSP.1.1E
+
+
+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-1 The evaluator _**shall examine**_ the functional specification to determine that it
+states the purpose of each SFR-supporting and SFR-enforcing TSFI.
+
+
+597 The purpose of a TSFI is a general statement summarising the functionality
+provided by the interface. It is not intended to be a complete statement of the
+actions and results related to the interface, but rather a statement to help the
+reader understand in general what the interface is intended to be used for.
+The evaluator should not only determine that the purpose exists, but also that
+it accurately reflects the TSFI by taking into account other information about
+the interface, such as the description of the parameters; this can be done in
+association with other work units for this component.
+
+
+598 If an action available through an interface plays a role in enforcing any
+security policy on the TOE (that is, if one of the actions of the interface can
+be traced to one of the SFRs levied on the TSF), then that interface is _SFR-_
+_enforcing_ . Such policies are not limited to the access control policies, but
+also refer to any functionality specified by one of the SFRs contained in the
+ST. Note that it is possible that an interface may have various actions and
+results, some of which may be SFR-enforcing and some of which may not.
+
+
+599 Interfaces to (or actions available through an interface relating to) actions
+that SFR-enforcing functionality depends on, but need only to function
+correctly in order for the security policies of the TOE to be preserved, are
+
+
+April 2017 Version 3.1 Page 129 of 430
+
+
+**Class ADV: Development**
+
+
+termed _SFR supporting_ . Interfaces to actions on which SFR-enforcing
+functionality has no dependence are termed _SFR non-interfering_ .
+
+
+600 It should be noted that in order for an interface to be SFR supporting or SFR
+non-interfering it must have _no_ SFR-enforcing actions or results. In contrast,
+an SFR-enforcing interface may have SFR-supporting actions (for example,
+the ability to set the system clock may be an SFR-enforcing action of an
+interface, but if that same interface is used to display the system date that
+action may only be SFR supporting). An example of a purely SFRsupporting interface is a system call interface that is used both by untrusted
+users and by a portion of the TSF that is running in user mode.
+
+
+601 At this level, it is unlikely that a developer will have expended effort to label
+interfaces as SFR-enforcing and SFR-supporting. In the case that this has
+been done, the evaluator should verify to the extent that supporting
+documentation (e.g., operational user guidance) allows that this identification
+is correct. Note that this identification activity is necessary for several work
+units for this component.
+
+
+602 In the more likely case that the developer has not labelled the interfaces, the
+evaluator must perform their own identification of the interfaces first, and
+then determine whether the required information (for this work unit, the
+purpose) is present. Again, because of the lack of supporting evidence this
+identification will be difficult and have low assurance that all appropriate
+interfaces have been correctly identified, but nonetheless the evaluator
+examines other evidence available for the TOE to ensure as complete
+coverage as is possible.
+
+
+ADV_FSP.1-2 The evaluator _**shall examine**_ the functional specification to determine that
+the method of use for each SFR-supporting and SFR-enforcing TSFI is given.
+
+
+603 See work unit ADV_FSP.1-1 for a discussion on the identification of SFRsupporting and SFR-enforcing TSFI.
+
+
+604 The method of use for a TSFI summarises how the interface is manipulated
+in order to invoke the actions and obtain the results associated with the TSFI.
+The evaluator should be able to determine, from reading this material in the
+functional specification, how to use each interface. This does not necessarily
+mean that there needs to be a separate method of use for each TSFI, as it may
+be possible to describe in general how kernel calls are invoked, for instance,
+and then identify each interface using that general style. Different types of
+interfaces will require different method of use specifications. APIs, network
+protocol interfaces, system configuration parameters, and hardware bus
+interfaces all have very different methods of use, and this should be taken
+into account by the developer when developing the functional specification,
+as well as by the evaluator evaluating the functional specification.
+
+
+605 For administrative interfaces whose functionality is documented as being
+inaccessible to untrusted users, the evaluator ensures that the method of
+making the functions inaccessible is described in the functional specification.
+
+
+Page 130 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+It should be noted that this inaccessibility needs to be tested by the developer
+in their test suite.
+
+
+ADV_FSP.1.2C _**The functional specification shall identify all parameters associated with**_
+_**each SFR-enforcing and SFR-supporting TSFI.**_
+
+
+ADV_FSP.1-3 The evaluator _**shall examine**_ the presentation of the TSFI to determine that it
+identifies all parameters associated with each SFR-enforcing and SFRsupporting TSFI.
+
+
+606 See work unit ADV_FSP.1-1 for a discussion on the identification of SFRsupporting and SFR-enforcing TSFI.
+
+
+607 The evaluator examines the functional specification to ensure that all of the
+parameters are described for identified TSFI. Parameters are explicit inputs
+or outputs to an interface that control the behaviour of that interface. For
+examples, parameters are the arguments supplied to an API; the various
+fields in packet for a given network protocol; the individual key values in the
+Windows Registry; the signals across a set of pins on a chip; etc.
+
+
+608 While difficult to obtain much assurance that all parameters for the
+applicable TSFI have been identified, the evaluator should also check other
+evidence provided for the evaluation (e.g., operational user guidance) to see
+if behaviour or additional parameters are described there but not in the
+functional specification.
+
+
+ADV_FSP.1.3C _**The functional specification shall provide rationale for the implicit**_
+_**categorisation of interfaces as SFR-non-interfering.**_
+
+
+ADV_FSP.1-4 The evaluator _**shall examine**_ the rationale provided by the developer for the
+implicit categorisation of interfaces as SFR-non-interfering to determine that
+it is accurate.
+
+
+609 In the case where the developer has provided adequate documentation to
+perform the analysis called for by the rest of the work units for this
+component without explicitly identifying SFR-enforcing and SFR-supporting
+interfaces, this work unit should be considered satisfied.
+
+
+610 This work unit is intended to apply to cases where the developer has not
+described a portion of the TSFI, claiming that it is SFR-non-interfering and
+therefore not subject to other requirements of this component. In such a case,
+the developer provides a rationale for this characterisation in sufficient detail
+such that the evaluator understands the rationale, the characteristics of the
+interfaces affected (e.g., their high-level function with respect to the TOE,
+such as โcolour palette manipulationโ), and that the claim that these are SFRnon-interfering is supported. Given the level of assurance the evaluator
+should not expect more detail than is provided for the SFR-enforcing or
+SFR-supporting interfaces, and in fact the detail should be much less. In
+most cases, individual interfaces should not need to be addressed in the
+developer-provided rationale section.
+
+
+April 2017 Version 3.1 Page 131 of 430
+
+
+**Class ADV: Development**
+
+
+ADV_FSP.1.4C _**The tracing shall demonstrate that the SFRs trace to TSFIs in the**_
+_**functional specification.**_
+
+
+ADV_FSP.1-5 The evaluator _**shall check**_ that the tracing links the SFRs to the
+corresponding TSFIs.
+
+
+611 The tracing is provided by the developer to serve as a guide to which SFRs
+are related to which TSFIs. This tracing can be as simple as a table; it is used
+as input to the evaluator for use in the following work units, in which the
+evaluator verifies its completeness and accuracy.
+
+
+12.4.1.4 Action ADV_FSP.1.2E
+
+
+ADV_FSP.1-6 The evaluator _**shall examine**_ the functional specification to determine that it
+is a complete instantiation of the SFRs.
+
+
+612 To ensure that all SFRs are covered by the functional specification, as well
+as the test coverage analysis, the evaluator may build upon the developer's
+tracing (see ADV_FSP.1-5 a map between the TOE security functional
+requirements and the TSFI). Note that this map may have to be at a level of
+detail below the component or even element level of the requirements,
+because of operations (assignments, refinements, selections) performed on
+the functional requirement by the ST author.
+
+
+613 For example, the FDP_ACC.1 component contains an element with
+assignments. If the ST contained, for instance, ten rules in the FDP_ACC.1
+assignment, and these ten rules were covered by three different TSFI, it
+would be inadequate for the evaluator to map FDP_ACC.1 to TSFI A, B, and
+C and claim they had completed the work unit. Instead, the evaluator would
+map FDP_ACC.1 (rule 1) to TSFI A; FDP_ACC.1 (rule 2) to TSFI B; etc. It
+might also be the case that the interface is a wrapper interface (e.g., IOCTL),
+in which case the mapping would need to be specific to certain set of
+parameters for a given interface.
+
+
+614 The evaluator must recognise that for requirements that have little or no
+manifestation at the TSF boundary (e.g., FDP_RIP) it is not expected that
+they completely map those requirements to the TSFI. The analysis for those
+requirements will be performed in the analysis for the TOE design
+(ADV_TDS) when included in the ST. It is also important to note that since
+the parameters associated with TSFIs must be fully specified, the evaluator
+should be able to determine if all aspects of an SFR appear to be
+implemented at the interface level.
+
+
+ADV_FSP.1-7 The evaluator _**shall examine**_ the functional specification to determine that it
+is an accurate instantiation of the SFRs.
+
+
+615 For each functional requirement in the ST that results in effects visible at the
+TSF boundary, the information in the associated TSFI for that requirement
+specifies the required functionality described by the requirement. For
+example, if the ST contains a requirement for access control lists, and the
+only TSFI that map to that requirement specify functionality for Unix-style
+
+
+Page 132 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+protection bits, then the functional specification is not accurate with respect
+to the requirements.
+
+
+616 The evaluator must recognise that for requirements that have little or no
+manifestation at the TSF boundary (e.g., FDP_RIP) it is not expected that the
+evaluator completely map those requirements to the TSFI. The analysis for
+those requirements will be performed in the analysis for the TOE design
+(ADV_TDS) when included in the ST.
+
+
+**12.4.2** **Evaluation of sub-activity (ADV_FSP.2)**
+
+
+12.4.2.1 Objectives
+
+
+617 The objective of this sub-activity is to determine whether the developer has
+provided a description of the TSFIs in terms of their purpose, method of use,
+and parameters. In addition, the SFR-enforcing actions, results and error
+messages of each TSFI that is SFR-enforcing are also described.
+
+
+12.4.2.2 Input
+
+
+618 The evaluation evidence for this sub-activity that is required by the workunits is:
+
+
+a) the ST;
+
+
+b) the functional specification;
+
+
+c) the TOE design.
+
+
+619 The evaluation evidence for this sub-activity that is used if included in the
+ST for the TOE is:
+
+
+a) the security architecture description;
+
+
+b) the operational user guidance;
+
+
+12.4.2.3 Action ADV_FSP.2.1E
+
+
+ADV_FSP.2.1C _**The functional specification shall completely represent the TSF.**_
+
+
+ADV_FSP.2-1 The evaluator _**shall examine**_ the functional specification to determine that
+the TSF is fully represented.
+
+
+620 The identification of the TSFI is a necessary prerequisite to all other
+activities in this sub-activity. The TSF must be identified (done as part of the
+TOE design (ADV_TDS) work units) in order to identify the TSFI. This
+activity can be done at a high level to ensure that no large groups of
+interfaces have been missed (network protocols, hardware interfaces,
+configuration files), or at a low level as the evaluation of the functional
+specification proceeds.
+
+
+April 2017 Version 3.1 Page 133 of 430
+
+
+**Class ADV: Development**
+
+
+621 In making an assessment for this work unit, the evaluator determines that all
+portions of the TSF are addressed in terms of the interfaces listed in the
+functional specification. All portions of the TSF should have a corresponding
+interface description, or if there are no corresponding interfaces for a portion
+of the TSF, the evaluator determines that that is acceptable.
+
+
+ADV_FSP.2.2C _**The functional specification shall describe the purpose and method of use**_
+_**for all TSFI.**_
+
+
+ADV_FSP.2-2 The evaluator _**shall examine**_ the functional specification to determine that it
+states the purpose of each TSFI.
+
+
+622 The purpose of a TSFI is a general statement summarising the functionality
+provided by the interface. It is not intended to be a complete statement of the
+actions and results related to the interface, but rather a statement to help the
+reader understand in general what the interface is intended to be used for.
+The evaluator should not only determine that the purpose exists, but also that
+it accurately reflects the TSFI by taking into account other information about
+the interface, such as the description of actions and error messages.
+
+
+ADV_FSP.2-3 The evaluator _**shall examine**_ the functional specification to determine that
+the method of use for each TSFI is given.
+
+
+623 The method of use for a TSFI summarises how the interface is manipulated
+in order to invoke the actions and obtain the results associated with the TSFI.
+The evaluator should be able to determine, from reading this material in the
+functional specification, how to use each interface. This does not necessarily
+mean that there needs to be a separate method of use for each TSFI, as it may
+be possible to describe in general how kernel calls are invoked, for instance,
+and then identify each interface using that general style. Different types of
+interfaces will require different method of use specifications. APIs, network
+protocol interfaces, system configuration parameters, and hardware bus
+interfaces all have very different methods of use, and this should be taken
+into account by the developer when developing the functional specification,
+as well as by the evaluator evaluating the functional specification.
+
+
+624 For administrative interfaces whose functionality is documented as being
+inaccessible to untrusted users, the evaluator ensures that the method of
+making the functions inaccessible is described in the functional specification.
+It should be noted that this inaccessibility needs to be tested by the developer
+in their test suite.
+
+
+625 The evaluator should not only determine that the set of method of use
+descriptions exist, but also that they accurately cover each TSFI.
+
+
+ADV_FSP.2.3C _**The functional specification shall identify and describe all parameters**_
+_**associated with each TSFI.**_
+
+
+ADV_FSP.2-4 The evaluator _**shall examine**_ the presentation of the TSFI to determine that it
+completely identifies all parameters associated with every TSFI.
+
+
+Page 134 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+626 The evaluator examines the functional specification to ensure that all of the
+parameters are described for each TSFI. Parameters are explicit inputs or
+outputs to an interface that control the behaviour of that interface. For
+examples, parameters are the arguments supplied to an API; the various
+fields in packet for a given network protocol; the individual key values in the
+Windows Registry; the signals across a set of pins on a chip; etc.
+
+
+627 In order to determine that all of the parameters are present in the TSFI, the
+evaluator should examine the rest of the interface description (actions, error
+messages, etc.) to determine if the effects of the parameter are accounted for
+in the description. The evaluator should also check other evidence provided
+for the evaluation (e.g., TOE design, security architecture description,
+operational user guidance, implementation representation) to see if behaviour
+or additional parameters are described there but not in the functional
+specification.
+
+
+ADV_FSP.2-5 The evaluator _**shall examine**_ the presentation of the TSFI to determine that it
+completely and accurately describes all parameters associated with every
+TSFI.
+
+
+628 Once all of the parameters have been identified, the evaluator needs to ensure
+that they are accurately described, and that the description of the parameters
+is complete. A parameter description tells what the parameter is in some
+meaningful way. For instance, the interface _foo(i)_ could be described as
+having โparameter i which is an integer"; this is not an acceptable parameter
+description. A description such as โparameter i is an integer that indicates the
+number of users currently logged in to the systemโ is much more acceptable.
+
+
+629 In order to determine that the description of the parameters is complete, the
+evaluator should examine the rest of the interface description (purpose,
+method of use, actions, error messages, etc.) to determine if the descriptions
+of the parameter(s) are accounted for in the description. The evaluator should
+also check other evidence provided (e.g., TOE design, architectural design,
+operational user guidance, implementation representation) to see if behaviour
+or additional parameters are described there but not in the functional
+specification.
+
+
+ADV_FSP.2.4C _**For each SFR-enforcing TSFI, the functional specification shall describe**_
+_**the SFR-enforcing actions associated with the TSFI.**_
+
+
+ADV_FSP.2-6 The evaluator _**shall examine**_ the presentation of the TSFI to determine that it
+completely and accurately describes the SFR-enforcing actions associated
+with the SFR-enforcing TSFIs.
+
+
+630 If an action available through an interface can be traced to one of the SFRs
+levied on the TSF, then that interface is _SFR-enforcing_ . Such policies are not
+limited to the access control policies, but also refer to any functionality
+specified by one of the SFRs contained in the ST. Note that it is possible that
+an interface may have various actions and results, some of which may be
+SFR-enforcing and some of which may not.
+
+
+April 2017 Version 3.1 Page 135 of 430
+
+
+**Class ADV: Development**
+
+
+631 The developer is not required to โlabelโ interfaces as SFR-enforcing, and
+likewise is not required to identify actions available through an interface as
+SFR-enforcing. It is the evaluator's responsibility to examine the evidence
+provided by the developer and determine that the required information is
+present. In the case where the developer has identified the SFR-enforcing
+TSFI and SFR-enforcing actions available through those TSFI, the evaluator
+must judge completeness and accuracy based on other information supplied
+for the evaluation (e.g., TOE design, security architecture description,
+operational user guidance), and on the other information presented for the
+interfaces (parameters and parameter descriptions, error messages, etc.).
+
+
+632 In this case (where the developer has provided only the SFR-enforcing
+information for SFR-enforcing TSFI) the evaluator also ensures that no
+interfaces have been mis-categorised. This is done by examining other
+information supplied for the evaluation (e.g., TOE design, security
+architecture description, operational user guidance), and the other
+information presented for the interfaces (parameters and parameter
+descriptions, for example) not labelled as SFR-enforcing.
+
+
+633 In the case where the developer has provided the same level of information
+on all interfaces, the evaluator performs the same type of analysis mentioned
+in the previous paragraphs. The evaluator should determine which interfaces
+are SFR-enforcing and which are not, and subsequently ensure that the SFRenforcing aspects of the SFR-enforcing actions are appropriately described.
+
+
+634 The SFR-enforcing actions are those that are visible at any external interface
+and that provide for the enforcement of the SFRs being claimed. For example,
+if audit requirements are included in the ST, then audit-related actions would
+be SFR-enforcing and therefore must be described, even if the result of that
+action is generally not visible through the invoked interface (as is often the
+case with audit, where a user action at one interface would produce an audit
+record visible at another interface).
+
+
+635 The level of description that is required is that sufficient for the reader to
+understand what role the TSFI actions play with respect to the SFR. The
+evaluator should keep in mind that the description should be detailed enough
+to support the generation (and assessment) of test cases against that interface.
+If the description is unclear or lacking detail such that meaningful testing
+cannot be conducted against the TSFI, it is likely that the description is
+inadequate.
+
+
+ADV_FSP.2.5C _**For each SFR-enforcing TSFI, the functional specification shall describe**_
+_**direct error messages resulting from processing associated with the SFR-**_
+_**enforcing actions.**_
+
+
+ADV_FSP.2-7 The evaluator _**shall examine**_ the presentation of the TSFI to determine that it
+completely and accurately describes error messages that may result from
+SFR-enforcing actions associated with each SFR-enforcing TSFI.
+
+
+636 This work unit should be performed in conjunction with, or after, work unit
+ADV_FSP.2-6 in order to ensure the set of SFR-enforcing TSFI and SFR
+
+Page 136 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+enforcing actions is correctly identified. The developer may provide more
+information than is required (for example, all error messages associated with
+each interface), in which the case the evaluator should restrict their
+assessment of completeness and accuracy to only those that they determine
+to be associated with SFR-enforcing actions of SFR-enforcing TSFI.
+
+
+637 Errors can take many forms, depending on the interface being described. For
+an API, the interface itself may return an error code, set a global error
+condition, or set a certain parameter with an error code. For a configuration
+file, an incorrectly configured parameter may cause an error message to be
+written to a log file. For a hardware PCI card, an error condition may raise a
+signal on the bus, or trigger an exception condition to the CPU.
+
+
+638 Errors (and the associated error messages) come about through the
+invocation of an interface. The processing that occurs in response to the
+interface invocation may encounter error conditions, which trigger (through
+an implementation-specific mechanism) an error message to be generated. In
+some instances this may be a return value from the interface itself; in other
+instances a global value may be set and checked after the invocation of an
+interface. It is likely that a TOE will have a number of low-level error
+messages that may result from fundamental resource conditions, such as
+โdisk fullโ or โresource lockedโ. While these error messages may map to a
+large number of TSFI, they could be used to detect instances where detail
+from an interface description has been omitted. For instance, a TSFI that
+produces a โdisk fullโ message, but has no obvious description of why that
+TSFI should cause an access to the disk in its description of actions, might
+cause the evaluator to examine other evidence (Security Architecture
+(ADV_ARC), TOE design (ADV_TDS)) related that TSFI to determine if
+the description is accurate.
+
+
+639 In order to determine that the description of the error messages of a TSFI is
+accurate and complete, the evaluator measures the interface description
+against the other evidence provided for the evaluation (e.g., TOE design,
+security architecture description, operational user guidance), as well as other
+evidence available for that TSFI (parameters, analysis from work unit
+ADV_FSP.2-6).
+
+
+ADV_FSP.2.6C _**The tracing shall demonstrate that the SFRs trace to TSFIs in the**_
+_**functional specification.**_
+
+
+ADV_FSP.2-8 The evaluator _**shall check**_ that the tracing links the SFRs to the
+corresponding TSFIs.
+
+
+640 The tracing is provided by the developer to serve as a guide to which SFRs
+are related to which TSFIs. This tracing can be as simple as a table; it is used
+as input to the evaluator for use in the following work units, in which the
+evaluator verifies its completeness and accuracy.
+
+
+April 2017 Version 3.1 Page 137 of 430
+
+
+**Class ADV: Development**
+
+
+12.4.2.4 Action ADV_FSP.2.2E
+
+
+ADV_FSP.2-9 The evaluator _**shall examine**_ the functional specification to determine that it
+is a complete instantiation of the SFRs.
+
+
+641 To ensure that all SFRs are covered by the functional specification, as well
+as the test coverage analysis, the evaluator may build upon the developer's
+tracing (see ADV_FSP.2-8 a map between the TOE security functional
+requirements and the TSFI. Note that this map may have to be at a level of
+detail below the component or even element level of the requirements,
+because of operations (assignments, refinements, selections) performed on
+the functional requirement by the ST author.
+
+
+642 For example, the FDP_ACC.1 component contains an element with
+assignments. If the ST contained, for instance, ten rules in the FDP_ACC.1
+assignment, and these ten rules were covered by three different TSFI, it
+would be inadequate for the evaluator to map FDP_ACC.1 to TSFI A, B, and
+C and claim they had completed the work unit. Instead, the evaluator would
+map FDP_ACC.1 (rule 1) to TSFI A; FDP_ACC.1 (rule 2) to TSFI B; etc. It
+might also be the case that the interface is a wrapper interface (e.g., IOCTL),
+in which case the mapping would need to be specific to certain set of
+parameters for a given interface.
+
+
+643 The evaluator must recognise that for requirements that have little or no
+manifestation at the TSF boundary (e.g., FDP_RIP) it is not expected that
+they completely map those requirements to the TSFI. The analysis for those
+requirements will be performed in the analysis for the TOE design
+(ADV_TDS) when included in the ST. It is also important to note that since
+the parameters, actions, and error messages associated with TSFIs must be
+fully specified, the evaluator should be able to determine if all aspects of an
+SFR appear to be implemented at the interface level.
+
+
+ADV_FSP.2-10 The evaluator _**shall examine**_ the functional specification to determine that it
+is an accurate instantiation of the SFRs.
+
+
+644 For each functional requirement in the ST that results in effects visible at the
+TSF boundary, the information in the associated TSFI for that requirement
+specifies the required functionality described by the requirement. For
+example, if the ST contains a requirement for access control lists, and the
+only TSFI that map to that requirement specify functionality for Unix-style
+protection bits, then the functional specification is not accurate with respect
+to the requirements.
+
+
+645 The evaluator must recognise that for requirements that have little or no
+manifestation at the TSF boundary (e.g., FDP_RIP) it is not expected that the
+evaluator completely map those requirements to the TSFI. The analysis for
+those requirements will be performed in the analysis for the TOE design
+(ADV_TDS) when included in the ST.
+
+
+Page 138 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+**12.4.3** **Evaluation of sub-activity (ADV_FSP.3)**
+
+
+12.4.3.1 Objectives
+
+
+646 The objective of this sub-activity is to determine whether the developer has
+provided a description of the TSFIs in terms of their purpose, method of use,
+and parameters. In addition, the actions, results and error messages of each
+TSFI are also described sufficiently that it can be determined whether they
+are SFR-enforcing, with the SFR-enforcing TSFI being described in more
+detail than other TSFIs.
+
+
+12.4.3.2 Input
+
+
+647 The evaluation evidence for this sub-activity that is required by the workunits is:
+
+
+a) the ST;
+
+
+b) the functional specification;
+
+
+c) the TOE design.
+
+
+648 The evaluation evidence for this sub-activity that is used if included in the
+ST for the TOE is:
+
+
+a) the security architecture description;
+
+
+b) the implementation representation;
+
+
+c) the TSF internals description;
+
+
+d) the operational user guidance;
+
+
+12.4.3.3 Action ADV_FSP.3.1E
+
+
+ADV_FSP.3.1C _**The functional specification shall completely represent the TSF.**_
+
+
+ADV_FSP.3-1 The evaluator _**shall examine**_ the functional specification to determine that
+the TSF is fully represented.
+
+
+649 The identification of the TSFI is a necessary prerequisite to all other
+activities in this sub-activity. The TSF must be identified (done as part of the
+TOE design (ADV_TDS) work units) in order to identify the TSFI. This
+activity can be done at a high level to ensure that no large groups of
+interfaces have been missed (network protocols, hardware interfaces,
+configuration files), or at a low level as the evaluation of the functional
+specification proceeds.
+
+
+650 In making an assessment for this work unit, the evaluator determines that all
+portions of the TSF are addressed in terms of the interfaces listed in the
+functional specification. All portions of the TSF should have a corresponding
+
+
+April 2017 Version 3.1 Page 139 of 430
+
+
+**Class ADV: Development**
+
+
+interface description, or if there are no corresponding interfaces for a portion
+of the TSF, the evaluator determines that that is acceptable.
+
+
+ADV_FSP.3.2C _**The functional specification shall describe the purpose and method of use**_
+_**for all TSFI.**_
+
+
+ADV_FSP.3-2 The evaluator _**shall examine**_ the functional specification to determine that it
+states the purpose of each TSFI.
+
+
+651 The purpose of a TSFI is a general statement summarising the functionality
+provided by the interface. It is not intended to be a complete statement of the
+actions and results related to the interface, but rather a statement to help the
+reader understand in general what the interface is intended to be used for.
+The evaluator should not only determine that the purpose exists, but also that
+it accurately reflects the TSFI by taking into account other information about
+the interface, such as the description of actions and error messages.
+
+
+ADV_FSP.3-3 The evaluator _**shall examine**_ the functional specification to determine that
+the method of use for each TSFI is given.
+
+
+652 The method of use for a TSFI summarises how the interface is manipulated
+in order to invoke the actions and obtain the results associated with the TSFI.
+The evaluator should be able to determine, from reading this material in the
+functional specification, how to use each interface. This does not necessarily
+mean that there needs to be a separate method of use for each TSFI, as it may
+be possible to describe in general how kernel calls are invoked, for instance,
+and then identify each interface using that general style. Different types of
+interfaces will require different method of use specifications. APIs, network
+protocol interfaces, system configuration parameters, and hardware bus
+interfaces all have very different methods of use, and this should be taken
+into account by the developer when developing the functional specification,
+as well as by the evaluator evaluating the functional specification.
+
+
+653 For administrative interfaces whose functionality is documented as being
+inaccessible to untrusted users, the evaluator ensures that the method of
+making the functions inaccessible is described in the functional specification.
+It should be noted that this inaccessibility needs to be tested by the developer
+in their test suite.
+
+
+654 The evaluator should not only determine that the set of method of use
+descriptions exist, but also that they accurately cover each TSFI.
+
+
+ADV_FSP.3.3C _**The functional specification shall identify and describe all parameters**_
+_**associated with each TSFI.**_
+
+
+ADV_FSP.3-4 The evaluator _**shall examine**_ the presentation of the TSFI to determine that it
+completely identifies all parameters associated with every TSFI.
+
+
+655 The evaluator examines the functional specification to ensure that all of the
+parameters are described for each TSFI. Parameters are explicit inputs or
+outputs to an interface that control the behaviour of that interface. For
+
+
+Page 140 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+examples, parameters are the arguments supplied to an API; the various
+fields in packet for a given network protocol; the individual key values in the
+Windows Registry; the signals across a set of pins on a chip; etc.
+
+
+656 In order to determine that all of the parameters are present in the TSFI, the
+evaluator should examine the rest of the interface description (actions, error
+messages, etc.) to determine if the effects of the parameter are accounted for
+in the description. The evaluator should also check other evidence provided
+for the evaluation (e.g., TOE design, security architecture description,
+operational user guidance, implementation representation) to see if behaviour
+or additional parameters are described there but not in the functional
+specification.
+
+
+ADV_FSP.3-5 The evaluator _**shall examine**_ the presentation of the TSFI to determine that it
+completely and accurately describes all parameters associated with every
+TSFI.
+
+
+657 Once all of the parameters have been identified, the evaluator needs to ensure
+that they are accurately described, and that the description of the parameters
+is complete. A parameter description tells what the parameter is in some
+meaningful way. For instance, the interface _foo(i)_ could be described as
+having โparameter i which is an integerโ; this is not an acceptable parameter
+description. A description such as โparameter i is an integer that indicates the
+number of users currently logged in to the systemโ is much more acceptable.
+
+
+658 In order to determine that the description of the parameters is complete, the
+evaluator should examine the rest of the interface description (purpose,
+method of use, actions, error messages, etc.) to determine if the descriptions
+of the parameter(s) are accounted for in the description. The evaluator should
+also check other evidence provided (e.g., TOE design, architectural design,
+operational user guidance, implementation representation) to see if behaviour
+or additional parameters are described there but not in the functional
+specification.
+
+
+ADV_FSP.3.4C _**For each SFR-enforcing TSFI, the functional specification shall describe**_
+_**the SFR-enforcing actions associated with the TSFI.**_
+
+
+ADV_FSP.3-6 The evaluator _**shall examine**_ the presentation of the TSFI to determine that it
+completely and accurately describes the SFR-enforcing actions associated
+with the SFR-enforcing TSFIs.
+
+
+659 If an action available through an interface plays a role in enforcing any
+security policy on the TOE (that is, if one of the actions of the interface can
+be traced to one of the SFRs levied on the TSF), then that interface is _SFR-_
+_enforcing_ . Such policies are not limited to the access control policies, but
+also refer to any functionality specified by one of the SFRs contained in the
+ST. Note that it is possible that an interface may have various actions and
+results, some of which may be SFR-enforcing and some of which may not.
+
+
+660 The developer is not required to โlabelโ interfaces as SFR-enforcing, and
+likewise is not required to identify actions available through an interface as
+
+
+April 2017 Version 3.1 Page 141 of 430
+
+
+**Class ADV: Development**
+
+
+SFR-enforcing. It is the evaluator's responsibility to examine the evidence
+provided by the developer and determine that the required information is
+present. In the case where the developer has identified the SFR-enforcing
+TSFI and SFR-enforcing actions available through those TSFI, the evaluator
+must judge completeness and accuracy based on other information supplied
+for the evaluation (e.g., TOE design, security architecture description,
+operational user guidance), and on the other information presented for the
+interfaces (parameters and parameter descriptions, error messages, etc.).
+
+
+661 In this case (developer has provided only the SFR-enforcing information for
+SFR-enforcing TSFI) the evaluator also ensures that no interfaces have been
+mis-categorised. This is done by examining other information supplied for
+the evaluation (e.g., TOE design, security architecture description,
+operational user guidance), and the other information presented for the
+interfaces (parameters and parameter descriptions, for example) not labelled
+as SFR-enforcing. The analysis done for work units ADV_FSP.3-7 and
+ADV_FSP.3-8 are also used in making this determination.
+
+
+662 In the case where the developer has provided the same level of information
+on all interfaces, the evaluator performs the same type of analysis mentioned
+in the previous paragraphs. The evaluator should determine which interfaces
+are SFR-enforcing and which are not, and subsequently ensure that the SFRenforcing aspects of the SFR-enforcing actions are appropriately described.
+Note that in this case, the evaluator should be able to perform the bulk of the
+work associated with work unit ADV_FSP.3-8 in the course of performing
+this SFR-enforcing analysis.
+
+
+663 The SFR-enforcing actions are those that are visible at any external interface
+and that provide for the enforcement of the SFRs being claimed. For example,
+if audit requirements are included in the ST, then audit-related actions would
+be SFR-enforcing and therefore must be described, even if the result of that
+action is generally not visible through the invoked interface (as is often the
+case with audit, where a user action at one interface would produce an audit
+record visible at another interface).
+
+
+664 The level of description that is required is that sufficient for the reader to
+understand what role the TSFI actions play with respect to the SFR. The
+evaluator should keep in mind that the description should be detailed enough
+to support the generation (and assessment) of test cases against that interface.
+If the description is unclear or lacking detail such that meaningful testing
+cannot be conducted against the TSFI, it is likely that the description is
+inadequate.
+
+
+ADV_FSP.3.5C _**For each SFR-enforcing TSFI, the functional specification shall describe**_
+_**direct error messages resulting from SFR-enforcing actions and exceptions**_
+_**associated with invocation of the TSFI.**_
+
+
+ADV_FSP.3-7 The evaluator _**shall examine**_ the presentation of the TSFI to determine that it
+completely and accurately describes error messages that may result from an
+invocation of each SFR-enforcing TSFI.
+
+
+Page 142 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+665 This work unit should be performed in conjunction with, or after, work unit
+ADV_FSP.3-6 in order to ensure the set of SFR-enforcing TSFI is correctly
+identified. The evaluator should note that the requirement and associated
+work unit is that all direct error messages associated with an SFR-enforcing
+TSFI must be described, that are associated with SFR-enforcing actions. This
+is because at this level of assurance, the โextraโ information provided by the
+error message descriptions should be used in determining whether all of the
+SFR-enforcing aspects of an interface have been appropriately described. For
+instance, if an error message associated with a TSFI (e.g., โaccess deniedโ)
+indicated that an SFR-enforcing decision or action had taken place, but in the
+description of the SFR-enforcing actions there was no mention of that
+particular SFR-enforcing mechanism, then the description may not be
+complete.
+
+
+666 Errors can take many forms, depending on the interface being described. For
+an API, the interface itself may return an error code, set a global error
+condition, or set a certain parameter with an error code. For a configuration
+file, an incorrectly configured parameter may cause an error message to be
+written to a log file. For a hardware PCI card, an error condition may raise a
+signal on the bus, or trigger an exception condition to the CPU.
+
+
+667 Errors (and the associated error messages) come about through the
+invocation of an interface. The processing that occurs in response to the
+interface invocation may encounter error conditions, which trigger (through
+an implementation-specific mechanism) an error message to be generated. In
+some instances this may be a return value from the interface itself; in other
+instances a global value may be set and checked after the invocation of an
+interface. It is likely that a TOE will have a number of low-level error
+messages that may result from fundamental resource conditions, such as
+โdisk fullโ or โresource lockedโ. While these error messages may map to a
+large number of TSFI, they could be used to detect instances where detail
+from an interface description has been omitted. For instance, a TSFI that
+produces a โdisk fullโ message, but has no obvious description of why that
+TSFI should cause an access to the disk in its description of actions, might
+cause the evaluator to examine other evidence (Security Architecture
+(ADV_ARC), TOE design (ADV_TDS)) related that TSFI to determine if
+the description is accurate.
+
+
+668 In order to determine that the description of the error messages of a TSFI is
+accurate and complete, the evaluator measures the interface description
+against the other evidence provided for the evaluation (e.g., TOE design,
+security architecture description, operational user guidance), as well as for
+other evidence supplied for that TSFI (description of SFR-enforcing actions,
+summary of SFR-supporting and SFR-non-interfering actions and results).
+
+
+ADV_FSP.3.6C _**The functional specification shall summarise the SFR-supporting and**_
+_**SFR-non-interfering actions associated with each TSFI.**_
+
+
+ADV_FSP.3-8 The evaluator _**shall examine**_ the presentation of the TSFI to determine that it
+summarises the SFR-supporting and SFR-non-interfering actions associated
+with each TSFI.
+
+
+April 2017 Version 3.1 Page 143 of 430
+
+
+**Class ADV: Development**
+
+
+669 The purpose of this work unit is to supplement the details about the SFRenforcing actions (provided in work unit ADV_FSP.3-6) with a summary of
+the remaining actions (i.e., those that are not SFR-enforcing). This covers _all_
+SFR-supporting and SFR-non-interfering actions, whether invokable through
+SFR-enforcing TSFI or through SFR-supporting or SFR-non-interfering
+TSFI. Such a summary about all SFR-supporting and SFR-non-interfering
+actions helps to provide a more complete picture of the functions provided
+by the TSF, and is to be used by the evaluator in determining whether an
+action or TSFI may have been mis-categorised.
+
+
+670 The information to be provided is more abstract than that required for SFRenforcing actions. While it should still be detailed enough so that the reader
+can understand what the action does, the description does not have to be
+detailed enough to support writing tests against it, for instance. For the
+evaluator, the key is that the information must be sufficient to make a
+positive determination that the action is SFR-supporting or SFR-noninterfering. If that level of information is missing, the summary is
+insufficient and more information must be obtained.
+
+
+ADV_FSP.3.7C _**The tracing shall demonstrate that the SFRs trace to TSFIs in the**_
+_**functional specification.**_
+
+
+ADV_FSP.3-9 The evaluator _**shall check**_ that the tracing links the SFRs to the
+corresponding TSFIs.
+
+
+671 The tracing is provided by the developer to serve as a guide to which SFRs
+are related to which TSFIs. This tracing can be as simple as a table; it is used
+as input to the evaluator for use in the following work units, in which the
+evaluator verifies its completeness and accuracy.
+
+
+12.4.3.4 Action ADV_FSP.3.2E
+
+
+ADV_FSP.3-10 The evaluator _**shall examine**_ the functional specification to determine that it
+is a complete instantiation of the SFRs.
+
+
+672 To ensure that all SFRs are covered by the functional specification, as well
+as the test coverage analysis, the evaluator may build upon the developer's
+tracing (see ADV_FSP.3-9 a map between the TOE security functional
+requirements and the TSFI. Note that this map may have to be at a level of
+detail below the component or even element level of the requirements,
+because of operations (assignments, refinements, selections) performed on
+the functional requirement by the ST author.
+
+
+673 For example, the FDP_ACC.1 component contains an element with
+assignments. If the ST contained, for instance, ten rules in the FDP_ACC.1
+assignment, and these ten rules were covered by three different TSFI, it
+would be inadequate for the evaluator to map FDP_ACC.1 to TSFI A, B, and
+C and claim they had completed the work unit. Instead, the evaluator would
+map FDP_ACC.1 (rule 1) to TSFI A; FDP_ACC.1 (rule 2) to TSFI B; etc. It
+might also be the case that the interface is a wrapper interface (e.g., IOCTL),
+
+
+Page 144 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+in which case the mapping would need to be specific to certain set of
+parameters for a given interface.
+
+
+674 The evaluator must recognise that for requirements that have little or no
+manifestation at the TSF boundary (e.g., FDP_RIP) it is not expected that
+they completely map those requirements to the TSFI. The analysis for those
+requirements will be performed in the analysis for the TOE design
+(ADV_TDS) when included in the ST. It is also important to note that since
+the parameters, actions, and error messages associated with TSFIs must be
+fully specified, the evaluator should be able to determine if all aspects of an
+SFR appear to be implemented at the interface level.
+
+
+ADV_FSP.3-11 The evaluator _**shall examine**_ the functional specification to determine that it
+is an accurate instantiation of the SFRs.
+
+
+675 For each functional requirement in the ST that results in effects visible at the
+TSF boundary, the information in the associated TSFI for that requirement
+specifies the required functionality described by the requirement. For
+example, if the ST contains a requirement for access control lists, and the
+only TSFI that map to that requirement specify functionality for Unix-style
+protection bits, then the functional specification is not accurate with respect
+to the requirements.
+
+
+676 The evaluator must recognise that for requirements that have little or no
+manifestation at the TSF boundary (e.g., FDP_RIP) it is not expected that the
+evaluator completely map those requirements to the TSFI. The analysis for
+those requirements will be performed in the analysis for the TOE design
+(ADV_TDS) when included in the ST.
+
+
+**12.4.4** **Evaluation of sub-activity (ADV_FSP.4)**
+
+
+12.4.4.1 Objectives
+
+
+677 The objective of this sub-activity is to determine whether the developer has
+completely described all of the TSFI in a manner such that the evaluator is
+able to determine whether the TSFI are completely and accurately described,
+and appears to implement the security functional requirements of the ST.
+
+
+12.4.4.2 Input
+
+
+678 The evaluation evidence for this sub-activity that is required by the workunits is:
+
+
+a) the ST;
+
+
+b) the functional specification;
+
+
+c) the TOE design.
+
+
+679 The evaluation evidence for this sub-activity that is used if included in the
+ST for the TOE is:
+
+
+April 2017 Version 3.1 Page 145 of 430
+
+
+**Class ADV: Development**
+
+
+a) the security architecture description;
+
+
+b) the implementation representation;
+
+
+c) the TSF internals description;
+
+
+d) the operational user guidance;
+
+
+12.4.4.3 Application notes
+
+
+680 The functional specification describes the interfaces to the TSF (the TSFI) in
+a structured manner. Because of the dependency on Evaluation of subactivity (ADV_TDS.1), the evaluator is expected to have identified the TSF
+prior to beginning work on this sub-activity. Without firm knowledge of
+what comprises the TSF, it is not possible to assess the completeness of the
+TSFI.
+
+
+681 In performing the various work units included in this family, the evaluator is
+asked to make assessments of accuracy and completeness of several factors
+(the TSFI itself, as well as the individual components (parameters, actions,
+error messages, etc.) of the TSFI). In doing this analysis, the evaluator is
+expected to use the documentation provided for the evaluation. This includes
+the ST, the TOE design, and may include other documentation such as the
+operational user guidance, security architecture description, and
+implementation representation. The documentation should be examined in an
+iterative fashion. The evaluator may read, for example, in the TOE design
+how a certain function is implemented, but see no way to invoke that
+function from the interface. This might cause the evaluator to question the
+completeness of a particular TSFI description, or whether an interface has
+been left out of the functional specification altogether. Describing analysis
+activities of this sort in the ETR is a key method in providing rationale that
+the work units have been performed appropriately.
+
+
+682 It should be recognised that there exist functional requirements whose
+functionality is manifested wholly or in part architecturally, rather than
+through a specific mechanism. An example of this is the implementation of
+mechanisms implementing the Residual information protection (FDP_RIP)
+requirements. Such mechanisms typically are implemented to ensure a
+behaviour isn't present, which is difficult to test and typically is verified
+through analysis. In the cases where such functional requirements are
+included in the ST, it is expected that the evaluator recognise that there may
+be SFRs of this type that have no interfaces, and that this should not be
+considered a deficiency in the functional specification.
+
+
+12.4.4.4 Action ADV_FSP.4.1E
+
+
+ADV_FSP.4.1C _**The functional specification shall completely represent the TSF.**_
+
+
+ADV_FSP.4-1 The evaluator _**shall examine**_ the functional specification to determine that
+the TSF is fully represented.
+
+
+Page 146 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+683 The identification of the TSFI is a necessary prerequisite to all other
+activities in this sub-activity. The TSF must be identified (done as part of the
+TOE design (ADV_TDS) work units) in order to identify the TSFI. This
+activity can be done at a high level to ensure that no large groups of
+interfaces have been missed (network protocols, hardware interfaces,
+configuration files), or at a low level as the evaluation of the functional
+specification proceeds.
+
+
+684 In making an assessment for this work unit, the evaluator determines that all
+portions of the TSF are addressed in terms of the interfaces listed in the
+functional specification. All portions of the TSF should have a corresponding
+interface description, or if there are no corresponding interfaces for a portion
+of the TSF, the evaluator determines that that is acceptable.
+
+
+ADV_FSP.4.2C _**The functional specification shall describe the purpose and method of use**_
+_**for all TSFI.**_
+
+
+ADV_FSP.4-2 The evaluator _**shall examine**_ the functional specification to determine that it
+states the purpose of each TSFI.
+
+
+685 The purpose of a TSFI is a general statement summarising the functionality
+provided by the interface. It is not intended to be a complete statement of the
+actions and results related to the interface, but rather a statement to help the
+reader understand in general what the interface is intended to be used for.
+The evaluator should not only determine that the purpose exists, but also that
+it accurately reflects the TSFI by taking into account other information about
+the interface, such as the description of actions and error messages.
+
+
+ADV_FSP.4-3 The evaluator _**shall examine**_ the functional specification to determine that
+the method of use for each TSFI is given.
+
+
+686 The method of use for a TSFI summarises how the interface is manipulated
+in order to invoke the actions and obtain the results associated with the TSFI.
+The evaluator should be able to determine, from reading this material in the
+functional specification, how to use each interface. This does not necessarily
+mean that there needs to be a separate method of use for each TSFI, as it may
+be possible to describe in general how kernel calls are invoked, for instance,
+and then identify each interface using that general style. Different types of
+interfaces will require different method of use specifications. APIs, network
+protocol interfaces, system configuration parameters, and hardware bus
+interfaces all have very different methods of use, and this should be taken
+into account by the developer when developing the functional specification,
+as well as by the evaluator evaluating the functional specification.
+
+
+687 For administrative interfaces whose functionality is documented as being
+inaccessible to untrusted users, the evaluator ensures that the method of
+making the functions inaccessible is described in the functional specification.
+It should be noted that this inaccessibility needs to be tested by the developer
+in their test suite.
+
+
+April 2017 Version 3.1 Page 147 of 430
+
+
+**Class ADV: Development**
+
+
+688 The evaluator should not only determine that the set of method of use
+descriptions exist, but also that they accurately cover each TSFI.
+
+
+ADV_FSP.4-4 The evaluator _**shall examine**_ the functional specification to determine the
+completeness of the TSFI
+
+
+689 The evaluator shall use the design documentation to identify the possible
+types of interfaces. The evaluator shall search the design documentation and
+the guidance documentation for potential TSFI not contained in the
+developer's documentation, thus indicating that the set of TSFI defined by
+the developer is incomplete. The evaluator _**shall examine**_ the arguments
+presented by the developer that the TSFI is complete and check down to the
+lowest level of design or with the implementation representation that no
+additional TSFI exist.
+
+
+ADV_FSP.4.3C _**The functional specification shall identify and describe all parameters**_
+_**associated with each TSFI.**_
+
+
+ADV_FSP.4-5 The evaluator _**shall examine**_ the presentation of the TSFI to determine that it
+completely identifies all parameters associated with every TSFI.
+
+
+690 The evaluator examines the functional specification to ensure that all of the
+parameters are described for each TSFI. Parameters are explicit inputs or
+outputs to an interface that control the behaviour of that interface. For
+examples, parameters are the arguments supplied to an API; the various
+fields in packet for a given network protocol; the individual key values in the
+Windows Registry; the signals across a set of pins on a chip; etc.
+
+
+691 In order to determine that all of the parameters are present in the TSFI, the
+evaluator should examine the rest of the interface description (actions, error
+messages, etc.) to determine if the effects of the parameter are accounted for
+in the description. The evaluator should also check other evidence provided
+for the evaluation (e.g., TOE design, security architecture description,
+operational user guidance, implementation representation) to see if behaviour
+or additional parameters are described there but not in the functional
+specification.
+
+
+ADV_FSP.4-6 The evaluator _**shall examine**_ the presentation of the TSFI to determine that it
+completely and accurately describes all parameters associated with every
+TSFI.
+
+
+692 Once all of the parameters have been identified, the evaluator needs to ensure
+that they are accurately described, and that the description of the parameters
+is complete. A parameter description tells what the parameter is in some
+meaningful way. For instance, the interface _foo(i)_ could be described as
+having โparameter i which is an integerโ; this is not an acceptable parameter
+description. A description such as โparameter i is an integer that indicates the
+number of users currently logged in to the systemโ is much more acceptable.
+
+
+693 In order to determine that the description of the parameters is complete, the
+evaluator should examine the rest of the interface description (purpose,
+
+
+Page 148 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+method of use, actions, error messages, etc.) to determine if the descriptions
+of the parameter(s) are accounted for in the description. The evaluator should
+also check other evidence provided (e.g., TOE design, architectural design,
+operational user guidance, implementation representation) to see if behaviour
+or additional parameters are described there but not in the functional
+specification.
+
+
+ADV_FSP.4.4C _**The functional specification shall describe all actions associated with each**_
+_**TSFI.**_
+
+
+ADV_FSP.4-7 The evaluator _**shall examine**_ the presentation of the TSFI to determine that it
+completely and accurately describes all actions associated with every TSFI.
+
+
+694 The evaluator checks to ensure that all of the actions are described. actions
+available through an interface describe what the interface does (as opposed to
+the TOE design, which describes how the actions are provided by the TSF).
+
+
+695 Actions of an interface describe functionality that can be invoked through the
+interface, and can be categorised as _regular_ actions, and _SFR-related_ actions.
+Regular actions are descriptions of what the interface does. The amount of
+information provided for this description is dependant on the complexity of
+the interface. The SFR-related actions are those that are visible at any
+external interface (for instance, audit activity caused by the invocation of an
+interface (assuming audit requirements are included in the ST) should be
+described, even though the result of that action is generally not visible
+through the invoked interface). Depending on the parameters of an interface,
+there may be many different actions able to be invoked through the interface
+(for instance, an API might have the first parameter be a โsubcommandโ, and
+the following parameters be specific to that subcommand. The IOCTL API
+in some Unix systems is an example of such an interface).
+
+
+696 In order to determine that the description of the actions of a TSFI is complete,
+the evaluator should review the rest of the interface description (parameter
+descriptions, error messages, etc.) to determine if the actions described are
+accounted for. The evaluator should also analyse other evidence provided for
+the evaluation (e.g., TOE design, security architecture description,
+operational user guidance, implementation representation) to see if there is
+evidence of actions that are described there but not in the functional
+specification.
+
+
+ADV_FSP.4.5C _**The functional specification shall describe all direct error messages that**_
+_**may result from an invocation of each TSFI.**_
+
+
+ADV_FSP.4-8 The evaluator _**shall examine**_ the presentation of the TSFI to determine that it
+completely and accurately describes all errors messages resulting from an
+invocation of each TSFI.
+
+
+697 Errors can take many forms, depending on the interface being described. For
+an API, the interface itself may return an error code; set a global error
+condition, or set a certain parameter with an error code. For a configuration
+file, an incorrectly configured parameter may cause an error message to be
+
+
+April 2017 Version 3.1 Page 149 of 430
+
+
+**Class ADV: Development**
+
+
+written to a log file. For a hardware PCI card, an error condition may raise a
+signal on the bus, or trigger an exception condition to the CPU.
+
+
+698 Errors (and the associated error messages) come about through the
+invocation of an interface. The processing that occurs in response to the
+interface invocation may encounter error conditions, which trigger (through
+an implementation-specific mechanism) an error message to be generated. In
+some instances this may be a return value from the interface itself; in other
+instances a global value may be set and checked after the invocation of an
+interface. It is likely that a TOE will have a number of low-level error
+messages that may result from fundamental resource conditions, such as
+โdisk fullโ or โresource lockedโ. While these error messages may map to a
+large number of TSFI, they could be used to detect instances where detail
+from an interface description has been omitted. For instance, a TSFI that
+produces a โdisk fullโ message, but has no obvious description of why that
+TSFI should cause an access to the disk in its description of actions, might
+cause the evaluator to examine other evidence (Security Architecture
+(ADV_ARC), TOE design (ADV_TDS)) related that TSFI to determine if
+the description is complete and accurate.
+
+
+699 The evaluator determines that, for each TSFI, the exact set of error messages
+that can be returned on invoking that interface can be determined. The
+evaluator reviews the evidence provided for the interface to determine if the
+set of errors seems complete. They cross-check this information with other
+evidence provided for the evaluation (e.g., TOE design, security architecture
+description, operational user guidance, implementation representation) to
+ensure that there are no errors steaming from processing mentioned that are
+not included in the functional specification.
+
+
+ADV_FSP.4-9 The evaluator _**shall examine**_ the presentation of the TSFI to determine that it
+completely and accurately describes the meaning of all error messages
+resulting from an invocation of each TSFI.
+
+
+700 In order to determine accuracy, the evaluator must be able to understand
+meaning of the error. For example, if an interface returns a numeric code of 0,
+1, or 2, the evaluator would not be able to understand the error if the
+functional specification only listed: โpossible errors resulting from
+invocation of the _foo()_ interface are 0, 1, or 2โ. Instead the evaluator checks
+to ensure that the errors are described such as: โpossible errors resulting from
+invocation of the _foo()_ interface are 0 (processing successful), 1 (file not
+found), or 2 (incorrect filename specification)โ.
+
+
+701 In order to determine that the description of the errors due to invoking a
+TSFI is complete, the evaluator examines the rest of the interface description
+(parameter descriptions, actions, etc.) to determine if potential error
+conditions that might be caused by using such an interface are accounted for.
+The evaluator also checks other evidence provided for the evaluation (e.g.
+TOE design, security architecture description, operational user guidance,
+implementation representation) to see if error processing related to the TSFI
+is described there but is not described in the functional specification.
+
+
+Page 150 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+ADV_FSP.4.6C _**The tracing shall demonstrate that the SFRs trace to TSFIs in the**_
+_**functional specification.**_
+
+
+ADV_FSP.4-10 The evaluator _**shall check**_ that the tracing links the SFRs to the
+corresponding TSFIs.
+
+
+702 The tracing is provided by the developer to serve as a guide to which SFRs
+are related to which TSFIs. This tracing can be as simple as a table; it is used
+as input to the evaluator for use in the following work units, in which the
+evaluator verifies its completeness and accuracy.
+
+
+12.4.4.5 Action ADV_FSP.4.2E
+
+
+ADV_FSP.4-11 The evaluator _**shall examine**_ the functional specification to determine that it
+is a complete instantiation of the SFRs.
+
+
+703 To ensure that all SFRs are covered by the functional specification, as well
+as the test coverage analysis, the evaluator may build upon the developer's
+tracing (see ADV_FSP.4-10 a map between the TOE security functional
+requirements and the TSFI. Note that this map may have to be at a level of
+detail below the component or even element level of the requirements,
+because of operations (assignments, refinements, selections) performed on
+the functional requirement by the ST author.
+
+
+704 For example, the FDP_ACC.1 component contains an element with
+assignments. If the ST contained, for instance, ten rules in the FDP_ACC.1
+assignment, and these ten rules were covered by three different TSFI, it
+would be inadequate for the evaluator to map FDP_ACC.1 to TSFI A, B, and
+C and claim they had completed the work unit. Instead, the evaluator would
+map FDP_ACC.1 (rule 1) to TSFI A; FDP_ACC.1 (rule 2) to TSFI B; etc. It
+might also be the case that the interface is a wrapper interface (e.g., IOCTL),
+in which case the mapping would need to be specific to certain set of
+parameters for a given interface.
+
+
+705 The evaluator must recognise that for requirements that have little or no
+manifestation at the TSF boundary (e.g., FDP_RIP) it is not expected that
+they completely map those requirements to the TSFI. The analysis for those
+requirements will be performed in the analysis for the TOE design
+(ADV_TDS) when included in the ST. It is also important to note that since
+the parameters, actions, and error messages associated with TSFIs must be
+fully specified, the evaluator should be able to determine if all aspects of an
+SFR appear to be implemented at the interface level.
+
+
+ADV_FSP.4-12 The evaluator _**shall examine**_ the functional specification to determine that it
+is an accurate instantiation of the SFRs.
+
+
+706 For each functional requirement in the ST that results in effects visible at the
+TSF boundary, the information in the associated TSFI for that requirement
+specifies the required functionality described by the requirement. For
+example, if the ST contains a requirement for access control lists, and the
+only TSFI that map to that requirement specify functionality for Unix-style
+
+
+April 2017 Version 3.1 Page 151 of 430
+
+
+**Class ADV: Development**
+
+
+protection bits, then the functional specification is not accurate with respect
+to the requirements.
+
+
+707 The evaluator must recognise that for requirements that have little or no
+manifestation at the TSF boundary (e.g., FDP_RIP) it is not expected that the
+evaluator completely map those requirements to the TSFI. The analysis for
+those requirements will be performed in the analysis for the TOE design
+(ADV_TDS) when included in the ST.
+
+
+**12.4.5** **Evaluation of sub-activity (ADV_FSP.5)**
+
+
+12.4.5.1 Objectives
+
+
+708 The objective of this sub-activity is to determine whether the developer has
+completely described all of the TSFI in a manner such that the evaluator is
+able to determine whether the TSFI are completely and accurately described,
+and appears to implement the security functional requirements of the ST. The
+completeness of the interfaces is judged based upon the implementation
+representation.
+
+
+12.4.5.2 Input
+
+
+709 The evaluation evidence for this sub-activity that is required by the workunits is:
+
+
+a) the ST;
+
+
+b) the functional specification;
+
+
+c) the TOE design;
+
+
+d) the implementation representation.
+
+
+710 The evaluation evidence for this sub-activity that is used if included in the
+ST for the TOE is:
+
+
+a) the security architecture description;
+
+
+b) the TSF internals description;
+
+
+c) the formal security policy model;
+
+
+d) the operational user guidance;
+
+
+12.4.5.3 Action ADV_FSP.5.1E
+
+
+ADV_FSP.5.1C _**The functional specification shall completely represent the TSF.**_
+
+
+ADV_FSP.5-1 The evaluator _**shall examine**_ the functional specification to determine that
+the TSF is fully represented.
+
+
+711 The identification of the TSFI is a necessary prerequisite to all other
+activities in this sub-activity. The TSF must be identified (done as part of the
+
+
+Page 152 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+TOE design (ADV_TDS) work units) in order to identify the TSFI. This
+activity can be done at a high level to ensure that no large groups of
+interfaces have been missed (network protocols, hardware interfaces,
+configuration files), or at a low level as the evaluation of the functional
+specification proceeds.
+
+
+712 In making an assessment for this work unit, the evaluator determines that all
+portions of the TSF are addressed in terms of the interfaces listed in the
+functional specification. All portions of the TSF should have a corresponding
+interface description, or if there are no corresponding interfaces for a portion
+of the TSF, the evaluator determines that that is acceptable.
+
+
+ADV_FSP.5.2C _**The functional specification shall describe the TSFI using a semi-formal**_
+_**style.**_
+
+
+ADV_FSP.5-2 The evaluator _**shall examine**_ the functional specification to determine that it
+is presented using a semiformal style.
+
+
+713 A semi-formal presentation is characterised by a standardised format with a
+well-defined syntax that reduces ambiguity that may occur in informal
+presentations. Since the intent of the semi-formal format is to enhance the
+reader's ability to understand the presentation, use of certain structured
+presentation methods (pseudo-code, flow charts, block diagrams) are
+appropriate, though not required.
+
+
+714 For the purposes of this activity, the evaluator should ensure that the
+interface descriptions are formatted in a structured, consistent manner and
+use common terminology. A semiformal presentation of the interfaces also
+implies that the level of detail of the presentation for the interfaces is largely
+consistent across all TSFI. For the functional specification, it is acceptable to
+refer to external specifications for portions of the interface as long as those
+external specifications are themselves semiformal.
+
+
+ADV_FSP.5.3C _**The functional specification shall describe the purpose and method of use**_
+_**for all TSFI.**_
+
+
+ADV_FSP.5-3 The evaluator _**shall examine**_ the functional specification to determine that it
+states the purpose of each TSFI.
+
+
+715 The purpose of a TSFI is a general statement summarising the functionality
+provided by the interface. It is not intended to be a complete statement of the
+actions and results related to the interface, but rather a statement to help the
+reader understand in general what the interface is intended to be used for.
+The evaluator should not only determine that the purpose exists, but also that
+it accurately reflects the TSFI by taking into account other information about
+the interface, such as the description of actions and error messages.
+
+
+ADV_FSP.5-4 The evaluator _**shall examine**_ the functional specification to determine that
+the method of use for each TSFI is given.
+
+
+April 2017 Version 3.1 Page 153 of 430
+
+
+**Class ADV: Development**
+
+
+716 The method of use for a TSFI summarises how the interface is manipulated
+in order to invoke the actions and obtain the results associated with the TSFI.
+The evaluator should be able to determine, from reading this material in the
+functional specification, how to use each interface. This does not necessarily
+mean that there needs to be a separate method of use for each TSFI, as it may
+be possible to describe in general how kernel calls are invoked, for instance,
+and then identify each interface using that general style. Different types of
+interfaces will require different method of use specifications. APIs, network
+protocol interfaces, system configuration parameters, and hardware bus
+interfaces all have very different methods of use, and this should be taken
+into account by the developer when developing the functional specification,
+as well as by the evaluator evaluating the functional specification.
+
+
+717 For administrative interfaces whose functionality is documented as being
+inaccessible to untrusted users, the evaluator ensures that the method of
+making the functions inaccessible is described in the functional specification.
+It should be noted that this inaccessibility needs to be tested by the developer
+in their test suite.
+
+
+718 The evaluator should not only determine that the set of method of use
+descriptions exist, but also that they accurately cover each TSFI.
+
+
+ADV_FSP.5-5 The evaluator _**shall examine**_ the functional specification to determine the
+completeness of the TSFI
+
+
+719 The evaluator shall use the design documentation to identify the possible
+types of interfaces. The evaluator shall search the design documentation and
+the guidance documentation for potential TSFI not contained in the
+developer's documentation, thus indicating that the set of TSFI defined by
+the developer is incomplete. The evaluator _**shall examine**_ the arguments
+presented by the developer that the TSFI is complete and check down to the
+lowest level of design or with the implementation representation that no
+additional TSFI exist.
+
+
+ADV_FSP.5.4C _**The functional specification shall identify and describe all parameters**_
+_**associated with each TSFI.**_
+
+
+ADV_FSP.5-6 The evaluator _**shall examine**_ the presentation of the TSFI to determine that it
+completely identifies all parameters associated with every TSFI.
+
+
+720 The evaluator examines the functional specification to ensure that all of the
+parameters are described for each TSFI. Parameters are explicit inputs or
+outputs to an interface that control the behaviour of that interface. For
+examples, parameters are the arguments supplied to an API; the various
+fields in packet for a given network protocol; the individual key values in the
+Windows Registry; the signals across a set of pins on a chip; etc.
+
+
+721 In order to determine that all of the parameters are present in the TSFI, the
+evaluator should examine the rest of the interface description (actions, error
+messages, etc.) to determine if the effects of the parameter are accounted for
+in the description. The evaluator should also check other evidence provided
+
+
+Page 154 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+for the evaluation (e.g., TOE design, security architecture description,
+operational user guidance, implementation representation) to see if behaviour
+or additional parameters are described there but not in the functional
+specification.
+
+
+ADV_FSP.5-7 The evaluator _**shall examine**_ the presentation of the TSFI to determine that it
+completely and accurately describes all parameters associated with every
+TSFI.
+
+
+722 Once all of the parameters have been identified, the evaluator needs to ensure
+that they are accurately described, and that the description of the parameters
+is complete. A parameter description tells what the parameter is in some
+meaningful way. For instance, the interface _foo(i)_ could be described as
+having โparameter i which is an integerโ; this is not an acceptable parameter
+description. A description such as โparameter i is an integer that indicates the
+number of users currently logged in to the systemโ. is much more acceptable.
+
+
+723 In order to determine that the description of the parameters is complete, the
+evaluator should examine the rest of the interface description (purpose,
+method of use, actions, error messages, etc.) to determine if the descriptions
+of the parameter(s) are accounted for in the description. The evaluator should
+also check other evidence provided (e.g., TOE design, architectural design,
+operational user guidance, implementation representation) to see if behaviour
+or additional parameters are described there but not in the functional
+specification.
+
+
+ADV_FSP.5.5C _**The functional specification shall describe all actions associated with each**_
+_**TSFI.**_
+
+
+ADV_FSP.5-8 The evaluator _**shall examine**_ the presentation of the TSFI to determine that it
+completely and accurately describes all actions associated with every TSFI.
+
+
+724 The evaluator checks to ensure that all of the actions are described. actions
+available through an interface describe what the interface does (as opposed to
+the TOE design, which describes how the actions are provided by the TSF).
+
+
+725 actions of an interface describe functionality that can be invoked through the
+interface, and can be categorised as _regular_ actions, and _SFR-related_ actions.
+Regular actions are descriptions of what the interface does. The amount of
+information provided for this description is dependant on the complexity of
+the interface. The SFR-related actions are those that are visible at any
+external interface (for instance, audit activity caused by the invocation of an
+interface (assuming audit requirements are included in the ST) should be
+described, even though the result of that action is generally not visible
+through the invoked interface). Depending on the parameters of an interface,
+there may be many different actions able to be invoked through the interface
+(for instance, an API might have the first parameter be a โsubcommandโ, and
+the following parameters be specific to that subcommand. The IOCTL API
+in some Unix systems is an example of such an interface).
+
+
+April 2017 Version 3.1 Page 155 of 430
+
+
+**Class ADV: Development**
+
+
+726 In order to determine that the description of the actions of a TSFI is complete,
+the evaluator should review the rest of the interface description (parameter
+descriptions, error messages, etc.) to determine if the actions described are
+accounted for. The evaluator should also analyse other evidence provided for
+the evaluation (e.g., TOE design, security architecture description,
+operational user guidance, implementation representation) to see if there is
+evidence of actions that are described there but not in the functional
+specification.
+
+
+ADV_FSP.5.6C _**The functional specification shall describe all direct error messages that**_
+_**may result from an invocation of each TSFI.**_
+
+
+ADV_FSP.5-9 The evaluator _**shall examine**_ the presentation of the TSFI to determine that it
+completely and accurately describes all errors messages resulting from an
+invocation of each TSFI.
+
+
+727 Errors can take many forms, depending on the interface being described. For
+an API, the interface itself may return an error code; set a global error
+condition, or set a certain parameter with an error code. For a configuration
+file, an incorrectly configured parameter may cause an error message to be
+written to a log file. For a hardware PCI card, an error condition may raise a
+signal on the bus, or trigger an exception condition to the CPU.
+
+
+728 Errors (and the associated error messages) come about through the
+invocation of an interface. The processing that occurs in response to the
+interface invocation may encounter error conditions, which trigger (through
+an implementation-specific mechanism) an error message to be generated. In
+some instances this may be a return value from the interface itself; in other
+instances a global value may be set and checked after the invocation of an
+interface. It is likely that a TOE will have a number of low-level error
+messages that may result from fundamental resource conditions, such as
+โdisk fullโ or โresource lockedโ. While these error messages may map to a
+large number of TSFI, they could be used to detect instances where detail
+from an interface description has been omitted. For instance, a TSFI that
+produces a โdisk fullโ message, but has no obvious description of why that
+TSFI should cause an access to the disk in its description of actions, might
+cause the evaluator to examine other evidence (ADV_ARC, ADV_TDS)
+related that TSFI to determine if the description is complete and accurate.
+
+
+729 The evaluator determines that, for each TSFI, the exact set of error messages
+that can be returned on invoking that interface can be determined. The
+evaluator reviews the evidence provided for the interface to determine if the
+set of errors seems complete. They cross-check this information with other
+evidence provided for the evaluation (e.g., TOE design, security architecture
+description, operational user guidance, implementation representation) to
+ensure that there are no errors steaming from processing mentioned that are
+not included in the functional specification.
+
+
+ADV_FSP.5-10 The evaluator _**shall examine**_ the presentation of the TSFI to determine that it
+completely and accurately describes the meaning of all error messages
+resulting from an invocation of each TSFI.
+
+
+Page 156 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+730 In order to determine accuracy, the evaluator must be able to understand
+meaning of the error. For example, if an interface returns a numeric code of 0,
+1, or 2, the evaluator would not be able to understand the error if the
+functional specification only listed: โpossible errors resulting from
+invocation of the _foo()_ interface are 0, 1, or 2โ. Instead the evaluator checks
+to ensure that the errors are described such as: โpossible errors resulting from
+invocation of the _foo()_ interface are 0 (processing successful), 1 (file not
+found), or 2 (incorrect filename specification)โ.
+
+
+731 In order to determine that the description of the errors due to invoking a
+TSFI is complete, the evaluator examines the rest of the interface description
+(parameter descriptions, actions, etc.) to determine if potential error
+conditions that might be caused by using such an interface are accounted for.
+The evaluator also checks other evidence provided for the evaluation (e.g.,
+TOE design, security architecture description, operational user guidance,
+implementation representation) to see if error processing related to the TSFI
+is described there but is not described in the functional specification.
+
+
+ADV_FSP.5.7C _**The functional specification shall describe all error messages that do not**_
+_**result from an invocation of a TSFI.**_
+
+
+ADV_FSP.5-11 The evaluator _**shall examine**_ the functional specification to determine that it
+completely and accurately describes all errors messages that do not result
+from an invocation of any TSFI.
+
+
+732 This work unit complements work unit ADV_FSP.5-9, which describes
+those error messages that result from an invocation of the TSFI. Taken
+together, these work units cover all error messages that might be generated
+by the TSF.
+
+
+733 The evaluator assesses the completeness and accuracy of the functional
+specification by comparing its contents to instances of error message
+generation within the implementation representation. Most of these error
+messages will have already been covered by work unit ADV_FSP.5-9.
+
+
+734 The error messages related to this work unit are typically those that are not
+expected to be generated, but are constructed as a matter of good
+programming practises. For example, a case statement that defines actions
+resulting from each of a list of cases may end with a final _else_ statement to
+apply to anything that might not be expected; this practise ensures the TSF
+does not get into an undefined state. However, it is not expected that the path
+of execution would ever get to this _else_ statement; therefore, any error
+message generation within this _else_ statement would never be generated.
+Although it would not get generated, it must still be included in the
+functional specification.
+
+
+ADV_FSP.5.8C _**The functional specification shall provide a rationale for each error**_
+_**message contained in the TSF implementation yet does not result from an**_
+_**invocation of a TSFI.**_
+
+
+April 2017 Version 3.1 Page 157 of 430
+
+
+**Class ADV: Development**
+
+
+ADV_FSP.5-12 The evaluator _**shall examine**_ the functional specification to determine that it
+provides a rationale for each error message contained in the TSF
+implementation yet does not result from an invocation of a TSFI.
+
+
+735 The evaluator ensures that every error message found under work unit
+ADV_FSP.5-11 contains a rationale describing why it cannot be invoked
+from the TSFI.
+
+
+736 As was described in the previous work unit, this rationale might be as
+straightforward as the fact that the error message in question is provided for
+completeness of execution logic and that it is never expected to be generated.
+The evaluator ensures that the rationale for each such error message is
+logical.
+
+
+ADV_FSP.5.9C _**The tracing shall demonstrate that the SFRs trace to TSFIs in the**_
+_**functional specification.**_
+
+
+ADV_FSP.5-13 The evaluator _**shall check**_ that the tracing links the SFRs to the
+corresponding TSFIs.
+
+
+737 The tracing is provided by the developer to serve as a guide to which SFRs
+are related to which TSFIs. This tracing can be as simple as a table; it is used
+as input to the evaluator for use in the following work units, in which the
+evaluator verifies its completeness and accuracy.
+
+
+12.4.5.4 Action ADV_FSP.5.2E
+
+
+ADV_FSP.5-14 The evaluator _**shall examine**_ the functional specification to determine that it
+is a complete instantiation of the SFRs.
+
+
+738 To ensure that all SFRs are covered by the functional specification, as well
+as the test coverage analysis, the evaluator may build upon the developer's
+tracing (see ADV_FSP.5-13 a map between the TOE security functional
+requirements and the TSFI. Note that this map may have to be at a level of
+detail below the component or even element level of the requirements,
+because of operations (assignments, refinements, selections) performed on
+the functional requirement by the ST author.
+
+
+739 For example, the FDP_ACC.1 component contains an element with
+assignments. If the ST contained, for instance, ten rules in the FDP_ACC.1
+assignment, and these ten rules were covered by three different TSFI, it
+would be inadequate for the evaluator to map FDP_ACC.1 to TSFI A, B, and
+C and claim they had completed the work unit. Instead, the evaluator would
+map FDP_ACC.1 (rule 1) to TSFI A; FDP_ACC.1 (rule 2) to TSFI B; etc. It
+might also be the case that the interface is a wrapper interface (e.g., IOCTL),
+in which case the mapping would need to be specific to certain set of
+parameters for a given interface.
+
+
+740 The evaluator must recognise that for requirements that have little or no
+manifestation at the TSF boundary (e.g., FDP_RIP) it is not expected that
+they completely map those requirements to the TSFI. The analysis for those
+
+
+Page 158 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+requirements will be performed in the analysis for the TOE design
+(ADV_TDS) when included in the ST. It is also important to note that since
+the parameters, actions, and error messages associated with TSFIs must be
+fully specified, the evaluator should be able to determine if all aspects of an
+SFR appear to be implemented at the interface level.
+
+
+ADV_FSP.5-15 The evaluator _**shall examine**_ the functional specification to determine that it
+is an accurate instantiation of the SFRs.
+
+
+741 For each functional requirement in the ST that results in effects visible at the
+TSF boundary, the information in the associated TSFI for that requirement
+specifies the required functionality described by the requirement. For
+example, if the ST contains a requirement for access control lists, and the
+only TSFI that map to that requirement specify functionality for Unix-style
+protection bits, then the functional specification is not accurate with respect
+to the requirements.
+
+
+742 The evaluator must recognise that for requirements that have little or no
+manifestation at the TSF boundary (e.g., FDP_RIP) it is not expected that the
+evaluator completely map those requirements to the TSFI. The analysis for
+those requirements will be performed in the analysis for the TOE design
+(ADV_TDS) when included in the ST.
+
+
+**12.4.6** **Evaluation of sub-activity (ADV_FSP.6)**
+
+
+743 There is no general guidance; the scheme should be consulted for guidance
+on this sub-activity.
+
+
+April 2017 Version 3.1 Page 159 of 430
+
+
+**Class ADV: Development**
+
+## **12.5 Implementation representation (ADV_IMP)**
+
+
+**12.5.1** **Evaluation of sub-activity (ADV_IMP.1)**
+
+
+12.5.1.1 Objectives
+
+
+744 The objective of this sub-activity is to determine that the implementation
+representation made available by the developer is suitable for use in other
+analysis activities; _suitability_ is judged by its conformance to the
+requirements for this component.
+
+
+12.5.1.2 Input
+
+
+745 The evaluation evidence for this sub-activity is:
+
+
+a) the implementation representation;
+
+
+b) the documentation of the development tools, as resulting from
+ALC_TAT ;
+
+
+c) TOE design description.
+
+
+12.5.1.3 Application notes
+
+
+746 The entire implementation representation is made available to ensure that
+analysis activities are not curtailed due to lack of information. This does not,
+however, imply that all of the representation is examined when the analysis
+activities are being performed. This is likely impractical in almost all cases,
+in addition to the fact that it most likely will not result in a higher-assurance
+TOE vs. targeted sampling of the implementation representation. For this
+sub-activity, this is even truer. It would not be productive for the evaluator to
+spend large amounts of time verifying the requirements for one portion of the
+implementation representation, and then use a different portion of the
+implementation representation in performing analysis for other work units.
+Therefore, the evaluator is encouraged to select the sample of the
+implementation representation from the areas of the TOE that will be of most
+interest during the analysis performed during work units from other families
+(e.g. ATE_IND, AVA_VAN and ADV_INT).
+
+
+12.5.1.4 Action ADV_IMP.1.1E
+
+
+ADV_IMP.1.1C _**The implementation representation shall define the TSF to a level of detail**_
+_**such that the TSF can be generated without further design decisions.**_
+
+
+ADV_IMP.1-1 The evaluator _**shall check**_ that the implementation representation defines the
+TSF to a level of detail such that the TSF can be generated without further
+design decisions.
+
+
+747 Source code or hardware diagrams and/or IC hardware design language code
+or layout data that are used to build the actual hardware are examples of parts
+of an implementation representation. The evaluator samples the
+implementation representation to gain confidence that it is at the appropriate
+
+
+Page 160 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+level and not, for instance, a pseudo-code level which requires additional
+design decisions to be made. The evaluator is encouraged to perform a quick
+check when first looking at the implementation representation to assure
+themselves that the developer is on the right track. However, the evaluator is
+also encourage to perform the bulk of this check while working on other
+work units that call for examining the implementation; this will ensure the
+sample examined for this work unit is relevant.
+
+
+ADV_IMP.1.2C _**The implementation representation shall be in the form used by the**_
+_**development personnel.**_
+
+
+ADV_IMP.1-2 The evaluator _**shall check**_ that the implementation representation is in the
+form used by development personnel.
+
+
+748 The implementation representation is manipulated by the developer in form
+that it suitable for transformation to the actual implementation. For instance,
+the developer may work with files containing source code, which is
+eventually compiled to become part of the TSF. The developer makes
+available the implementation representation in the form they use, so that the
+evaluator may use automated techniques in the analysis. This also increases
+the confidence that the implementation representation examined is actually
+the one used in the production of the TSF (as opposed to the case where it is
+supplied in an alternate presentation format, such as a word processor
+document). It should be noted that other forms of the implementation
+representation may also be used by the developer; these forms are supplied
+as well. The overall goal is to supply the evaluator with the information that
+will maximise the evaluator's analysis efforts.
+
+
+749 The evaluator samples the implementation representation to gain confidence
+that it is the version that is usable by the developer. The sample is such that
+the evaluator has assurance that all areas of the implementation
+representation are in conformance with the requirement; however, a
+complete examination of the entire implementation representation is
+unnecessary.
+
+
+750 Conventions in some forms of the implementation representation may make
+it difficult or impossible to determine from just the implementation
+representation itself what the actual result of the compilation or run-time
+interpretation will be. For example, compiler directives for C language
+compilers will cause the compiler to exclude or include entire portions of the
+code.
+
+
+751 Some forms of the implementation representation may require additional
+information because they introduce significant barriers to understanding and
+analysis. Examples include shrouded source code or source code that has
+been obfuscated in other ways such that it prevents understanding and/or
+analysis. These forms of implementation representation typically result from
+by taking a version of the implementation representation that is used by the
+TOE developer and running a shrouding or obfuscation program on it. While
+the shrouded representation is what is compiled and may be closer to the
+implementation (in terms of structure) than the original, un-shrouded
+
+
+April 2017 Version 3.1 Page 161 of 430
+
+
+**Class ADV: Development**
+
+
+representation, supplying such obfuscated code may cause significantly more
+time to be spent in analysis tasks involving the representation. When such
+forms of representation are created, the components require details on the
+shrouding tools/algorithms used so that the un-shrouded representation can
+be supplied, and the additional information can be used to gain confidence
+that the shrouding process does not compromise any security mechanisms.
+
+
+752 The evaluator samples the implementation representation to gain confidence
+that all of the information needed to interpret the implementation
+representation has been supplied. Note that the tools are among those
+referenced by Tools and techniques (ALC_TAT) components. The evaluator
+is encouraged to perform a quick check when first looking at the
+implementation representation to assure themselves that the developer is on
+the right track. However, the evaluator is also encouraged to perform the
+bulk of this check while working on other work units that call for examining
+the implementation; this will ensure the sample examined for this work unit
+is relevant.
+
+
+ADV_IMP.1.3C _**The mapping between the TOE design description and the sample of the**_
+_**implementation representation shall demonstrate their correspondence.**_
+
+
+ADV_IMP.1-3 The evaluator _**shall examine**_ the mapping between the TOE design
+description and the sample of the implementation representation to determine
+that it is accurate.
+
+
+753 The evaluator augments the determination of existence (specified in work
+unit ADV_IMP.1-1) by verifying the accuracy of a portion of the
+implementation representation and the TOE design description. For parts of
+the TOE design description that are interesting, the evaluator would verify
+the implementation representation accurately reflects the description
+provided in the TOE design description.
+
+
+754 For example, the TOE design description might identify a login module that
+is used to identify and authenticate users. If user authentication is sufficiently
+significant, the evaluator would verify that the corresponding code in fact
+implements that service as described in the TOE design description. It might
+also be worthwhile to verify that the code accepts the parameters as
+described in the functional specification.
+
+
+755 It is worth pointing out the developer must choose whether to perform the
+mapping for the entire implementation representation, thereby guaranteeing
+that the chosen sample will be covered, or waiting for the sample to be
+chosen before performing the mapping. The first option is likely more work,
+but may be completed before the evaluation begins. The second option is less
+work, but will produce a suspension of evaluation activity while the
+necessary evidence is being produced.
+
+
+**12.5.2** **Evaluation of sub-activity (ADV_IMP.2)**
+
+
+756 There is no general guidance; the scheme should be consulted for guidance
+on this sub-activity.
+
+
+Page 162 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+## **12.6 TSF internals (ADV_INT)**
+
+
+**12.6.1** **Evaluation of sub-activity (ADV_INT.1)**
+
+
+12.6.1.1 Objectives
+
+
+757 The objective of this sub-activity is to determine whether the defined subset
+of the TSF is designed and structured such that the likelihood of flaws is
+reduced and that maintenance can be more readily performed without the
+introduction of flaws.
+
+
+12.6.1.2 Input
+
+
+758 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the TOE design description;
+
+
+c) the implementation representation (if ADV_IMP is part of the
+claimed assurance);
+
+
+d) the TSF internals description and justification;
+
+
+e) the documentation of the coding standards, as resulting from
+ALC_TAT.
+
+
+12.6.1.3 Application notes
+
+
+759 The role of the internals description is to provide evidence of the structure of
+the design and implementation of the TSF.
+
+
+760 The structure of the design has two aspects: the constituent parts of the TSF
+and the procedures used to design the TSF. In cases where the TSF is
+designed in a manner consistent with the design represented by the TOE
+design (see ADV_TDS), the assessment of the TSF design is obvious. In
+cases where the design procedures (see ALC_TAT) are being followed, the
+assessment of the TSF design procedures is similarly obvious.
+
+
+761 In cases where the TSF is implemented using procedure-based software, this
+structure is assessed on the basis of its _modularity_ ; the modules identified in
+the internals description are the same as the modules identified in the TOE
+design (TOE design (ADV_TDS)). A module consists of one or more source
+code files that cannot be decomposed into smaller compilable units.
+
+
+762 The use of the assignment in this component levies stricter constraints on the
+subset of the TSF that is explicitly identified in the assignment
+ADV_INT.1.1D than on the remainder of the TSF. While the entire TSF is to
+be designed using good engineering principles and result in a well-structured
+TSF, only the specified subset is specifically analysed for this characteristic.
+The evaluator determines that the developer's application of coding standards
+result in a TSF that is understandable.
+
+
+April 2017 Version 3.1 Page 163 of 430
+
+
+**Class ADV: Development**
+
+
+763 The primary goal of this component is to ensure the TSF subset's
+implementation representation is understandable to facilitate maintenance
+and analysis (of both the developer and evaluator).
+
+
+12.6.1.4 Action ADV_INT.1.1E
+
+
+ADV_INT.1.1C _**The justification shall explain the characteristics used to judge the**_
+_**meaning of โwell-structuredโ.**_
+
+
+ADV_INT.1-1 The evaluator _**shall examine**_ the justification to determine that it identifies
+the basis for determining whether the TSF is well-structured.
+
+
+764 The evaluator verifies that the criteria for determining the characteristic of
+being well-structured are clearly defined in the justification. Acceptable
+criteria typically originate from industry standards for the technology
+discipline. For example, procedural software that executes linearly is
+traditionally viewed as well-structured if it adheres to software engineering
+programming practises, such as those defined in the IEEE Standard ( _IEEE_
+_Std 610.12-1990_ ). For example, it would identify the criteria for the
+procedural software portions of the TSF subset:
+
+
+a) the process used for modular decomposition
+
+
+b) coding standards used in the development of the implementation
+
+
+c) a description of the maximum acceptable level of intermodule
+coupling exhibited by the TSF subset
+
+
+d) a description of the minimum acceptable level of cohesion exhibited
+the modules of the TSF subset
+
+
+765 For other types of technologies used in the TOE - such as non-procedural
+software (e.g. object-oriented programming), widespread commodity
+hardware (e.g. PC microprocessors), and special-purpose hardware (e.g.
+smart-card processors) - the evaluator should seek guidance from the
+evaluation authority for determining the adequacy of criteria for being โwellstructuredโ.
+
+
+ADV_INT.1.2C _**The TSF internals description shall demonstrate that the assigned subset**_
+_**of the TSF is well-structured.**_
+
+
+ADV_INT.1-2 The evaluator _**shall check**_ the TSF internals description to determine that it
+identifies the Assigned subset of the TSF.
+
+
+766 This subset may be identified in terms of the internals of the TSF at any layer
+of abstraction. For example, it may be in terms of the structural elements of
+the TSF as identified in the TOE design (e.g. the audit subsystem), or in
+terms of the implementation (e.g. _encrypt.c_ and _decrypt.c_ files, or the 6227
+IC chip).
+
+
+Page 164 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+767 It is insufficient to identify this subset in terms of the claimed SFRs (e.g. the
+portion of the TSF that provide anonymity as defined in FPR_ANO.2)
+because this does not indicate where to focus the analysis.
+
+
+ADV_INT.1-3 The evaluator _**shall examine**_ the TSF internals description to determine that
+it demonstrates that the assigned TSF subset is well-structured.
+
+
+768 The evaluator examines the internals description to ensure that it provides a
+sound explanation of how the TSF subset meets the criteria from
+ADV_INT.1-1
+
+
+769 For example, it would explain how the procedural software portions of the
+TSF subset meets the following:
+
+
+a) that there is a one-to-one correspondence between the modules
+identified in the TSF subset and the modules described in the TOE
+design (ADV_TDS)
+
+
+b) how the TSF design is a reflection of the modular decomposition
+process
+
+
+c) a justification for all instances where the coding standards were not
+used or met
+
+
+d) a justification for any coupling or cohesion outside the acceptable
+bounds
+
+
+12.6.1.5 Action ADV_INT.1.2E
+
+
+ADV_INT.1-4 The evaluator _**shall determine**_ that the TOE design for the assigned TSF
+subset is well-structured.
+
+
+770 The evaluator examines a sample of the TOE design to verify the accuracy of
+the justification. For example, a sample of the TOE design is analysed to
+determine its adherence to the design standards, etc. As with all areas where
+the evaluator performs activities on a subset the evaluator provides a
+justification of the sample size and scope
+
+
+771 The description of the TOE's decomposition into subsystems and modules
+will make the argument that the TSF subset is well-structured self-evident.
+Verification that the procedures for structuring the TSF (as examined in
+ALC_TAT) are being followed will make it self-evident that the TSF subset
+is well-structured.
+
+
+ADV_INT.1-5 The evaluator _**shall determine**_ that the assigned TSF subset is well-structured.
+
+
+772 If ADV_IMP is not part of the claimed assurance, then this work unit is not
+applicable and is therefore considered to be satisfied.
+
+
+773 The evaluator examines a sample of the TSF subset to verify the accuracy of
+the internals description. For example, a sample of the procedural software
+portions of the TSF subset is analysed to determine its cohesion and coupling,
+
+
+April 2017 Version 3.1 Page 165 of 430
+
+
+**Class ADV: Development**
+
+
+its adherence to the coding standards, etc. As with all areas where the
+evaluator performs activities on a subset the evaluator provides a justification
+of the sample size and scope.
+
+
+**12.6.2** **Evaluation of sub-activity (ADV_INT.2)**
+
+
+12.6.2.1 Objectives
+
+
+774 The objective of this sub-activity is to determine whether the TSF is
+designed and structured such that the likelihood of flaws is reduced and that
+maintenance can be more readily performed without the introduction of
+flaws.
+
+
+12.6.2.2 Input
+
+
+775 The evaluation evidence for this sub-activity is:
+
+
+a) the modular design description;
+
+
+b) the implementation representation (if ADV_IMP is part of the
+claimed assurance));
+
+
+c) the TSF internals description;
+
+
+d) the documentation of the coding standards, as resulting from
+ALC_TAT.
+
+
+12.6.2.3 Application notes
+
+
+776 The role of the internals description is to provide evidence of the structure of
+the design and implementation of the TSF.
+
+
+777 The structure of the design has two aspects: the constituent parts of the TSF
+and the procedures used to design the TSF. In cases where the TSF is
+designed in a manner consistent with the design represented by the TOE
+design (see ADV_TDS), the assessment of the TSF design is obvious. In
+cases where the design procedures (see ALC_TAT) are being followed, the
+assessment of the TSF design procedures is similarly obvious.
+
+
+778 In cases where the TSF is implemented using procedure-based software, this
+structure is assessed on the basis of its _modularity_ ; the modules identified in
+the internals description are the same as the modules identified in the TOE
+design (TOE design (ADV_TDS)). A module consists of one or more source
+code files that cannot be decomposed into smaller compilable units.
+
+
+779 The primary goal of this component is to ensure the TSF's implementation
+representation is understandable to facilitate maintenance and analysis (of
+both the developer and evaluator).
+
+
+Page 166 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+12.6.2.4 Action ADV_INT.2.1E
+
+
+ADV_INT.2.1C _**The justification shall describe the characteristics used to judge the**_
+_**meaning of โwell-structuredโ.**_
+
+
+ADV_INT.2-1 The evaluator _**shall examine**_ the justification to determine that it identifies
+the basis for determining whether the TSF is well-structured.
+
+
+780 The evaluator verifies that the criteria for determining the characteristic of
+being well-structured are clearly defined in the justification. Acceptable
+criteria typically originate from industry standards for the technology
+discipline. For example, procedural software that executes linearly is
+traditionally viewed as well-structured if it adheres to software engineering
+programming practises, such as those defined in the IEEE Standard ( _IEEE_
+_Std 610.12-1990_ ). For example, it would identify the criteria for the
+procedural software portions of the TSF:
+
+
+a) the process used for modular decomposition
+
+
+b) coding standards used in the development of the implementation
+
+
+c) a description of the maximum acceptable level of intermodule
+coupling exhibited by the TSF
+
+
+d) a description of the minimum acceptable level of cohesion exhibited
+the modules of the TSF
+
+
+781 For other types of technologies used in the TOE - such as non-procedural
+software (e.g. object-oriented programming), widespread commodity
+hardware (e.g. PC microprocessors), and special-purpose hardware (e.g.
+smart-card processors) - the evaluation authority should be consulted for
+determining the adequacy of criteria for being โwell-structuredโ.
+
+
+ADV_INT.2.2C _**The TSF internals description shall demonstrate that the entire TSF is**_
+_**well-structured.**_
+
+
+ADV_INT.2-2 The evaluator _**shall examine**_ the TSF internals description to determine that
+it demonstrates that the TSF is well-structured.
+
+
+782 The evaluator examines the internals description to ensure that it provides a
+sound explanation of how the TSF meets the criteria from ADV_INT.2-1
+
+
+783 For example, it would explain how the procedural software portions of the
+TSF meet the following:
+
+
+a) that there is a one-to-one correspondence between the modules
+identified in the TSF and the modules described in the TOE design
+(ADV_TDS)
+
+
+b) how the TSF design is a reflection of the modular decomposition
+process
+
+
+April 2017 Version 3.1 Page 167 of 430
+
+
+**Class ADV: Development**
+
+
+c) a justification for all instances where the coding standards were not
+used or met
+
+
+d) a justification for any coupling or cohesion outside the acceptable
+bounds
+
+
+12.6.2.5 Action ADV_INT.2.2E
+
+
+ADV_INT.2-3 The evaluator _**shall determine**_ that the TOE design is well-structured.
+
+
+784 The evaluator examines the TOE design of a sample of the TSF to verify the
+accuracy of the justification. For example, a sample of the TOE design is
+analysed to determine its adherence to the design standards, etc. As with all
+areas where the evaluator performs activities on a subset the evaluator
+provides a justification of the sample size and scope
+
+
+785 The description of the TOE's decomposition into subsystems and modules
+will make the argument that the TSF subset is well-structured self-evident.
+Verification that the procedures for structuring the TSF (as examined in
+ALC_TAT) are being followed will make it self-evident that the TSF subset
+is well-structured.
+
+
+ADV_INT.2-4 The evaluator _**shall determine**_ that the TSF is well-structured.
+
+
+786 If ADV_IMP is not part of the claimed assurance, then this work unit is not
+applicable and is therefore considered to be satisfied.
+
+
+787 The evaluator examines a sample of the TSF to verify the accuracy of the
+internals description. For example, a sample of the procedural software
+portions of the TSF is analysed to determine its cohesion and coupling, its
+adherence to the coding standards, etc. As with all areas where the evaluator
+performs activities on a subset the evaluator provides a justification of the
+sample size and scope.
+
+
+**12.6.3** **Evaluation of sub-activity (ADV_INT.3)**
+
+
+788 There is no general guidance; the scheme should be consulted for guidance
+on this sub-activity.
+
+
+Page 168 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+## **12.7 Security policy modelling (ADV_SPM)**
+
+
+**12.7.1** **Evaluation of sub-activity (ADV_SPM.1)**
+
+
+789 There is no general guidance; the scheme should be consulted for guidance
+on this sub-activity.
+
+
+April 2017 Version 3.1 Page 169 of 430
+
+
+**Class ADV: Development**
+
+## **12.8 TOE design (ADV_TDS)**
+
+
+**12.8.1** **Evaluation of sub-activity (ADV_TDS.1)**
+
+
+12.8.1.1 Input
+
+
+790 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the functional specification;
+
+
+c) security architecture description;
+
+
+d) the TOE design.
+
+
+12.8.1.2 Action ADV_TDS.1.1E
+
+
+ADV_TDS.1.1C _**The design shall describe the structure of the TOE in terms of subsystems.**_
+
+
+ADV_TDS.1-1 The evaluator _**shall examine**_ the TOE design to determine that the structure
+of the entire TOE is described in terms of subsystems.
+
+
+791 The evaluator ensures that all of the subsystems of the TOE are identified.
+This description of the TOE will be used as input to work unit ADV_TDS.12, where the parts of the TOE that make up the TSF are identified. That is,
+this requirement is on the entire TOE rather than on only the TSF.
+
+
+792 The TOE (and TSF) may be described in multiple layers of abstraction (i.e.
+subsystems and modules) Depending upon the complexity of the TOE, its
+design may be described in terms of subsystems and modules, as described
+in CC Part 3 Annex A.4, ADV_TDS: Subsystems and Modules. At this level
+of assurance, the decomposition only need be at the โsubsystemโ level.
+
+
+793 In performing this activity, the evaluator examines other evidence presented
+for the TOE (e.g., ST, operator user guidance) to determine that the
+description of the TOE in such evidence is consistent with the description
+contained in the TOE design.
+
+
+ADV_TDS.1.2C _**The design shall identify all subsystems of the TSF.**_
+
+
+ADV_TDS.1-2 The evaluator _**shall examine**_ the TOE design to determine that all
+subsystems of the TSF are identified.
+
+
+794 In work unit ADV_TDS.1-1 all of the subsystems of the TOE were identified,
+and a determination made that the non-TSF subsystems were correctly
+characterised. Building on that work, the subsystems that were not
+characterised as non-TSF subsystems should be precisely identified. The
+evaluator determines that, of the hardware and software installed and
+configured according to the Preparative procedures (AGD_PRE) guidance,
+each subsystem has been accounted for as either one that is part of the TSF,
+or one that is not.
+
+
+Page 170 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+ADV_TDS.1.3C _**The design shall provide the behaviour summary of each SFR-supporting**_
+_**or SFR-non-interfering TSF subsystem.**_
+
+
+ADV_TDS.1-3 The evaluator _**shall examine**_ the TOE design to determine that each SFRsupporting or SFR-non-interfering subsystem of the TSF is described such
+that the evaluator can determine that the subsystem is SFR-supporting or
+SFR-non-interfering.
+
+
+795 SFR-supporting and SFR-non-interfering subsystems do not need to be
+described in detail as to how they function in the system. However, the
+evaluator makes a determination, based on the evidence provided by the
+developer, that the subsystems that do not have high-level descriptions are
+SFR-supporting or SFR-non-interfering. Note that if the developer provides a
+uniform level of detailed documentation then this work unit will be largely
+satisfied, since the point of categorising the subsystems is to allow the
+developer to provide less information for SFR-supporting and SFR-noninterfering subsystems than for SFR-enforcing subsystems.
+
+
+796 An SFR-supporting subsystem is one that is depended on by an SFRenforcing subsystem in order to implement an SFR, but does not play as
+direct a role as an SFR-enforcing subsystem. An SFR-non-interfering
+subsystem is one that is not depended upon, in either a supporting or
+enforcing role, to implement an SFR.
+
+
+ADV_TDS.1.4C _**The design shall summarise the SFR-enforcing behaviour of the SFR-**_
+_**enforcing subsystems.**_
+
+
+ADV_TDS.1-4 The evaluator _**shall examine**_ the TOE design to determine that it provides a
+complete, accurate, and high-level summary of the SFR-enforcing behaviour
+of the SFR-enforcing subsystems.
+
+
+797 The developer may designate subsystems as SFR-enforcing, SFR-supporting,
+and SFR non-interfering, but these โtagsโ are used only to describe the
+amount and type of information the developer must provide, and can be used
+to limit the amount of information the developer has to develop if their
+engineering process does not produce the documentation required. Whether
+the subsystems have been categorised by the developer or not, it is the
+evaluator's responsibility to determine that the subsystems have the
+appropriate information for their role (SFR-enforcing, etc.) in the TOE, and
+to obtain the appropriate information from the developer should the
+developer fail to provide the required information for a particular subsystem.
+
+
+798 SFR-enforcing behaviour refers to _how_ a subsystem provides the
+functionality that implements an SFR. The goal of evaluator's assessment is
+to give the evaluator with an understanding of the way each SFR-enforcing
+subsystem works. The information provided for the behaviour summary does
+not have to be as detailed as that provided by the behaviour description. For
+example, data structures or data items will likely not need to be described in
+detail. It is the evaluator's determination, however, with respect to what
+โhigh-levelโ means for a particular TOE, and the evaluator obtains enough
+information from the developer (even if it turns out to be equivalent to
+
+
+April 2017 Version 3.1 Page 171 of 430
+
+
+**Class ADV: Development**
+
+
+information provided for subsystem behaviour) to make a sound verdict for
+this work unit.
+
+
+799 The evaluator is cautioned, however, that โperfectโ assurance is not a goal
+nor required by this work unit, so judgement will have to be exercised in
+determine the amount and composition of the evidence required to make a
+verdict on this work unit.
+
+
+800 To determine completeness and accuracy, the evaluator examines other
+information available (e.g., functional specification, security architecture
+description). Summaries of functionality in these documents should be
+consistent with what is provided for evidence for this work unit.
+
+
+ADV_TDS.1.5C _**The design shall provide a description of the interactions among SFR-**_
+_**enforcing subsystems of the TSF, and between the SFR-enforcing**_
+_**subsystems of the TSF and other subsystems of the TSF.**_
+
+
+ADV_TDS.1-5 The evaluator _**shall examine**_ the TOE design to determine that interactions
+between the subsystems of the TSF are described.
+
+
+801 The goal of describing the interactions between the SFR-enforcing
+subsystems and other subsystems is to help provide the reader a better
+understanding of how the TSF performs it functions. These interactions do
+not need to be characterised at the implementation level (e.g., parameters
+passed from one routine in a subsystem to a routine in a different subsystem;
+global variables; hardware signals (e.g., interrupts) from a hardware
+subsystem to an interrupt-handling subsystem), but the data elements
+identified for a particular subsystem that are going to be used by another
+subsystem need to be covered in this discussion. Any control relationships
+between subsystems (e.g., a subsystem responsible for configuring a rule
+base for a firewall system and the subsystem that actually implements these
+rules) should also be described.
+
+
+802 The evaluators need to use their own judgement in assessing the
+completeness of the description. If the reason for an interaction is unclear, or
+if there are SFR-related interactions (discovered, for instance, in examining
+the descriptions of subsystem behaviour) that do not appear to be described,
+the evaluator ensures that this information is provided by the developer.
+However, if the evaluator can determine that interactions among a particular
+set of subsystems, while incompletely described by the developer, will not
+aid in understanding the overall functionality nor security functionality
+provided by the TSF, then the evaluator may choose to consider the
+description sufficient, and not pursue completeness for its own sake.
+
+
+ADV_TDS.1.6C _**The mapping shall demonstrate that all TSFIs trace to the behaviour**_
+_**described in the TOE design that they invoke.**_
+
+
+ADV_TDS.1-6 The evaluator _**shall examine**_ the TOE design to determine that it contains a
+complete and accurate mapping from the TSFI described in the functional
+specification to the subsystems of the TSF described in the TOE design.
+
+
+Page 172 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+803 The subsystems described in the TOE design provide a description of how
+the TSF works at a detailed level for SFR-enforcing portions of the TSF, and
+at a higher level for other portions of the TSF. The TSFI provide a
+description of how the implementation is exercised. The evidence from the
+developer identifies the subsystem that is initially involved when an
+operation is requested at the TSFI, and identify the various subsystems that
+are primarily responsible for implementing the functionality. Note that a
+complete โcall treeโ for each TSFI is not required for this work unit.
+
+
+804 The evaluator assesses the completeness of the mapping by ensuring that all
+of the TSFI map to at least one subsystem. The verification of accuracy is
+more complex.
+
+
+805 The first aspect of accuracy is that each TSFI is mapped to a subsystem at the
+TSF boundary. This determination can be made by reviewing the subsystem
+description and interactions, and from this information determining its place
+in the architecture. The next aspect of accuracy is that the mapping makes
+sense. For instance, mapping a TSFI dealing with access control to a
+subsystem that checks passwords is not accurate. The evaluator should again
+use judgement in making this determination. The goal is that this information
+aids the evaluator in understanding the system and implementation of the
+SFRs, and ways in which entities at the TSF boundary can interact with the
+TSF. The bulk of the assessment of whether the SFRs are described
+accurately by the subsystems is performed in other work units.
+
+
+12.8.1.3 Action ADV_TDS.1.2E
+
+
+ADV_TDS.1-7 The evaluator _**shall examine**_ the TOE security functional requirements and
+the TOE design, to determine that all ST security functional requirements are
+covered by the TOE design.
+
+
+806 The evaluator may construct a map between the TOE security functional
+requirements and the TOE design. This map will likely be from a functional
+requirement to a set of subsystems. Note that this map may have to be at a
+level of detail below the component or even element level of the
+requirements, because of operations (assignments, refinements, selections)
+performed on the functional requirement by the ST author.
+
+
+807 For example, the FDP_ACC.1 Subset access control component contains an
+element with assignments. If the ST contained, for instance, ten rules in the
+FDP_ACC.1 Subset access control assignment, and these ten rules were
+implemented in specific places within fifteen modules, it would be
+inadequate for the evaluator to map FDP_ACC.1 Subset access control to
+one subsystem and claim the work unit had been completed. Instead, the
+evaluator would map FDP_ACC.1 Subset access control (rule 1) to
+subsystem A, behaviours x, y, and z; FDP_ACC.1 Subset access control
+(rule 2) to subsystem A, behaviours x, p, and q; etc.
+
+
+ADV_TDS.1-8 The evaluator _**shall examine**_ the TOE design to determine that it is an
+accurate instantiation of all security functional requirements.
+
+
+April 2017 Version 3.1 Page 173 of 430
+
+
+**Class ADV: Development**
+
+
+808 The evaluator ensures that each security requirement listed in the TOE
+security functional requirements section of the ST has a corresponding
+design description in the TOE design that accurately details how the TSF
+meets that requirement. This requires that the evaluator identify a collection
+of subsystems that are responsible for implementing a given functional
+requirement, and then examine those subsystems to understand how the
+requirement is implemented. Finally, the evaluator would assess whether the
+requirement was accurately implemented.
+
+
+809 As an example, if the ST requirements specified a role-based access control
+mechanism, the evaluator would first identify the subsystems that contribute
+to this mechanism's implementation. This could be done by in-depth
+knowledge or understanding of the TOE design or by work done in the
+previous work unit. Note that this trace is only to identify the subsystems,
+and is not the complete analysis.
+
+
+810 The next step would be to understand what mechanism the subsystems
+implemented. For instance, if the design described an implementation of
+access control based on UNIX-style protection bits, the design would not be
+an accurate instantiation of those access control requirements present in the
+ST example used above. If the evaluator could not determine that the
+mechanism was accurately implemented because of a lack of detail, the
+evaluator would have to assess whether all of the SFR-enforcing subsystems
+have been identified, or if adequate detail had been provided for those
+subsystems.
+
+
+**12.8.2** **Evaluation of sub-activity (ADV_TDS.2)**
+
+
+12.8.2.1 Input
+
+
+811 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the functional specification;
+
+
+c) security architecture description;
+
+
+d) the TOE design.
+
+
+12.8.2.2 Action ADV_TDS.2.1E
+
+
+ADV_TDS.2.1C _**The design shall describe the structure of the TOE in terms of subsystems.**_
+
+
+ADV_TDS.2-1 The evaluator _**shall examine**_ the TOE design to determine that the structure
+of the entire TOE is described in terms of subsystems.
+
+
+812 The evaluator ensures that all of the subsystems of the TOE are identified.
+This description of the TOE will be used as input to work unit ADV_TDS.22, where the parts of the TOE that make up the TSF are identified. That is,
+this requirement is on the entire TOE rather than on only the TSF.
+
+
+Page 174 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+813 The TOE (and TSF) may be described in multiple layers of abstraction (i.e.
+subsystems and modules) Depending upon the complexity of the TOE, its
+design may be described in terms of subsystems and modules, as described
+in CC Part 3 Annex A.4, ADV_TDS: Subsystems and Modules. At this level
+of assurance, the decomposition only need be at the โsubsystemโ level.
+
+
+814 In performing this activity, the evaluator examines other evidence presented
+for the TOE (e.g., ST, operator user guidance) to determine that the
+description of the TOE in such evidence is consistent with the description
+contained in the TOE design.
+
+
+ADV_TDS.2.2C _**The design shall identify all subsystems of the TSF.**_
+
+
+ADV_TDS.2-2 The evaluator _**shall examine**_ the TOE design to determine that all
+subsystems of the TSF are identified.
+
+
+815 In work unit ADV_TDS.2-1 all of the subsystems of the TOE were identified,
+and a determination made that the non-TSF subsystems were correctly
+characterised. Building on that work, the subsystems that were not
+characterised as non-TSF subsystems should be precisely identified. The
+evaluator determines that, of the hardware and software installed and
+configured according to the Preparative procedures (AGD_PRE) guidance,
+each subsystem has been accounted for as either one that is part of the TSF,
+or one that is not.
+
+
+ADV_TDS.2.3C _**The design shall provide the behaviour summary of each SFR non-**_
+_**interfering subsystem of the TSF.**_
+
+
+ADV_TDS.2-3 The evaluator _**shall examine**_ the TOE design to determine that each SFRnon-interfering subsystem of the TSF is described such that the evaluator can
+determine that the subsystem is SFR-non-interfering.
+
+
+816 SFR-non-interfering subsystems do not need to be described in detail as to
+how they function in the system. However, the evaluator makes a
+determination, based on the evidence provided by the developer, that the
+subsystems that do not have detailed descriptions are SFR-non-interfering.
+Note that if the developer provides a uniform level of detailed documentation
+then this work unit will be largely satisfied, since the point of categorising
+the subsystems is to allow the developer to provide less information for SFRnon-interfering subsystems than for SFR-enforcing and SFR-supporting
+subsystems.
+
+
+817 An SFR-non-interfering subsystem is one on which the SFR-enforcing and
+SFR-supporting subsystems have no dependence; that is, they play no role in
+implementing SFR functionality.
+
+
+ADV_TDS.2.4C _**The design shall describe the SFR-enforcing behaviour of the SFR-**_
+_**enforcing subsystems.**_
+
+
+April 2017 Version 3.1 Page 175 of 430
+
+
+**Class ADV: Development**
+
+
+ADV_TDS.2-4 The evaluator _**shall examine**_ the TOE design to determine that it provides a
+complete, accurate, and detailed description of the SFR-enforcing behaviour
+of the SFR-enforcing subsystems.
+
+
+818 The developer may designate subsystems as SFR-enforcing, SFR-supporting,
+and SFR non-interfering, but these โtagsโ are used only to describe the
+amount and type of information the developer must provide, and can be used
+to limit the amount of information the developer has to develop if their
+engineering process does not produce the documentation required. Whether
+the subsystems have been categorised by the developer or not, it is the
+evaluator's responsibility to determine that the subsystems have the
+appropriate information for their role (SFR-enforcing, etc.) in the TOE, and
+to obtain the appropriate information from the developer should the
+developer fail to provide the required information for a particular subsystem.
+
+
+819 SFR-enforcing behaviour refers to _how_ a subsystem provides the
+functionality that implements an SFR. While not at the level of an
+algorithmic description, a detailed description of behaviour typically
+discusses how the functionality is provided in terms of what key data and
+data structures are, what control relationships exist within a subsystem, and
+how these elements work together to provide the SFR-enforcing behaviour.
+Such a description also references SFR-supporting behaviour, which the
+evaluator should consider in performing subsequent work units.
+
+
+820 To determine completeness and accuracy, the evaluator examines other
+information available (e.g., functional specification, security architecture
+description). Descriptions of functionality in these documents should be
+consistent with what is provided for evidence for this work unit.
+
+
+ADV_TDS.2.5C _**The design shall summarise the SFR-supporting and SFR-non-interfering**_
+_**behaviour of the SFR-enforcing subsystems.**_
+
+
+ADV_TDS.2-5 The evaluator _**shall examine**_ the TOE design to determine that it provides a
+complete and accurate high-level summary of the SFR-supporting and SFRnon-interfering behaviour of the SFR-enforcing subsystems.
+
+
+821 The developer may designate subsystems as SFR-enforcing, SFR-supporting,
+and SFR non-interfering, but these โtagsโ are used only to describe the
+amount and type of information the developer must provide, and can be used
+to limit the amount of information the developer has to develop if their
+engineering process does not produce the documentation required. Whether
+the subsystems have been categorised by the developer or not, it is the
+evaluator's responsibility to determine that the subsystems have the
+appropriate information for their role (SFR-enforcing, etc.) in the TOE, and
+to obtain the appropriate information from the developer should the
+developer fail to provide the required information for a particular subsystem.
+
+
+822 In contrast to the previous work unit, this work unit calls for the evaluator to
+assess the information provided for SFR-enforcing subsystems that is SFRsupporting or SFR-non-interfering. The goal of this assessment is two-fold.
+First, it should provide the evaluator greater understanding of the way each
+
+
+Page 176 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+subsystem works. Second, this assessment will help the evaluator to
+determine that all SFR-enforcing behaviour exhibited by a SFR-enforcing
+subsystem has been described. Unlike the previous work unit, the
+information provided for the SFR-supporting or SFR-non-interfering
+behaviour does not have to be as detailed as that provided by the SFRenforcing behaviour. For example, data structures or data items that do not
+pertain to SFR-enforcing functionality will likely not need to be described in
+detail, if at all. It is the evaluator's determination, however, with respect to
+what โhigh-levelโ means for a particular TOE, and the evaluator obtains
+enough information from the developer (even if it turns out to be equivalent
+to information provided for the parts of the subsystem that are SFRenforcing) to make a sound verdict for this work unit.
+
+
+823 The evaluator is cautioned, however, that โperfectโ assurance is not a goal
+nor required by this work unit, so judgement will have to be exercised in
+determine the amount and composition of the evidence required to make a
+verdict on this work unit.
+
+
+824 To determine completeness and accuracy, the evaluator examines other
+information available (e.g., functional specification, security architecture
+description). Summaries of functionality in these documents should be
+consistent with what is provided for evidence for this work unit. In particular,
+the functional specification should be used to determine that the behaviour
+required to implement the TSF Interfaces described by the functional
+specification are completely described by the subsystem, since the behaviour
+will either be SFR-enforcing, SFR-supporting or SFR-non-interfering.
+
+
+ADV_TDS.2.6C _**The design shall summarise the behaviour of the SFR-supporting**_
+_**subsystems.**_
+
+
+ADV_TDS.2-6 The evaluator _**shall examine**_ the TOE design to determine that it provides a
+complete and accurate high-level summary of the behaviour of the SFRsupporting subsystems.
+
+
+825 The developer may designate subsystems as SFR-enforcing, SFR-supporting,
+and SFR non-interfering, but these โtagsโ are used only to describe the
+amount and type of information the developer must provide, and can be used
+to limit the amount of information the developer has to develop if their
+engineering process does not produce the documentation required. Whether
+the subsystems have been categorised by the developer or not, it is the
+evaluator's responsibility to determine that the subsystems have the
+appropriate information for their role (SFR-enforcing, etc.) in the TOE, and
+to obtain the appropriate information from the developer should the
+developer fail to provide the required information for a particular subsystem.
+
+
+826 In contrast to the previous two work units, this work unit calls for the
+developer to provide (and the evaluator to assess) information about SFR
+supporting subsystems. Such subsystems should be referenced by the
+descriptions of the SFR-enforcing subsystems, as well as by the descriptions
+of interactions in work unit ADV_TDS.2-7. The goal of evaluator's
+assessment, like that for the previous work unit, is two-fold. First, it should
+
+
+April 2017 Version 3.1 Page 177 of 430
+
+
+**Class ADV: Development**
+
+
+provide the evaluator with an understanding of the way each SFR-supporting
+subsystem works. Second, the evaluator determines that the behaviour is
+summarized in enough detail so that the way in which the subsystem
+supports the SFR-enforcing behaviour is clear, and that the behaviour is not
+itself SFR-enforcing. The information provided for SFR-supporting
+subsystem's behaviour does not have to be as detailed as that provided by the
+SFR-enforcing behaviour. For example, data structures or data items that do
+not pertain to SFR-enforcing functionality will likely not need to be
+described in detail, if at all. It is the evaluator's determination, however, with
+respect to what โhigh-levelโ means for a particular TOE, and the evaluator
+obtains enough information from the developer (even if it turns out to be
+equivalent to information provided for the parts of the subsystem that are
+SFR-enforcing) to make a sound verdict for this work unit.
+
+
+827 The evaluator is cautioned, however, that โperfectโ assurance is not a goal
+nor required by this work unit, so judgement will have to be exercised in
+determine the amount and composition of the evidence required to make a
+verdict on this work unit.
+
+
+828 To determine completeness and accuracy, the evaluator examines other
+information available (e.g., functional specification, security architecture
+description). Summaries of functionality in these documents should be
+consistent with what is provided for evidence for this work unit.
+
+
+ADV_TDS.2.7C _**The design shall provide a description of the interactions among all**_
+_**subsystems of the TSF.**_
+
+
+ADV_TDS.2-7 The evaluator _**shall examine**_ the TOE design to determine that interactions
+between the subsystems of the TSF are described.
+
+
+829 The goal of describing the interactions between the subsystems is to help
+provide the reader a better understanding of how the TSF performs it
+functions. These interactions do not need to be characterised at the
+implementation level (e.g., parameters passed from one routine in a
+subsystem to a routine in a different subsystem; global variables; hardware
+signals (e.g., interrupts) from a hardware subsystem to an interrupt-handling
+subsystem), but the data elements identified for a particular subsystem that
+are going to be used by another subsystem need to be covered in this
+discussion. Any control relationships between subsystems (e.g., a subsystem
+responsible for configuring a rule base for a firewall system and the
+subsystem that actually implements these rules) should also be described.
+
+
+830 It should be noted while the developer should characterise all interactions
+between subsystems, the evaluators need to use their own judgement in
+assessing the completeness of the description. If the reason for an interaction
+is unclear, or if there are SFR-related interactions (discovered, for instance,
+in examining the descriptions of subsystem behaviour) that do not appear to
+be described, the evaluator ensures that this information is provided by the
+developer. However, if the evaluator can determine that interactions among a
+particular set of subsystems, while incompletely described by the developer,
+will not aid in understanding the overall functionality nor security
+
+
+Page 178 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+functionality provided by the TSF, then the evaluator may choose to consider
+the description sufficient, and not pursue completeness for its own sake.
+
+
+ADV_TDS.2.8C _**The mapping shall demonstrate that all TSFIs trace to the behaviour**_
+_**described in the TOE design that they invoke.**_
+
+
+ADV_TDS.2-8 The evaluator _**shall examine**_ the TOE design to determine that it contains a
+complete and accurate mapping from the TSFI described in the functional
+specification to the subsystems of the TSF described in the TOE design.
+
+
+831 The subsystems described in the TOE design provide a description of how
+the TSF works at a detailed level for SFR-enforcing portions of the TSF, and
+at a higher level for other portions of the TSF. The TSFI provide a
+description of how the implementation is exercised. The evidence from the
+developer identifies the subsystem that is initially involved when an
+operation is requested at the TSFI, and identify the various subsystems that
+are primarily responsible for implementing the functionality. Note that a
+complete โcall treeโ for each TSFI is not required for this work unit.
+
+
+832 The evaluator assesses the completeness of the mapping by ensuring that all
+of the TSFI map to at least one subsystem. The verification of accuracy is
+more complex.
+
+
+833 The first aspect of accuracy is that each TSFI is mapped to a subsystem at the
+TSF boundary. This determination can be made by reviewing the subsystem
+description and interactions, and from this information determining its place
+in the architecture. The next aspect of accuracy is that the mapping makes
+sense. For instance, mapping a TSFI dealing with access control to a
+subsystem that checks passwords is not accurate. The evaluator should again
+use judgement in making this determination. The goal is that this information
+aids the evaluator in understanding the system and implementation of the
+SFRs, and ways in which entities at the TSF boundary can interact with the
+TSF. The bulk of the assessment of whether the SFRs are described
+accurately by the subsystems is performed in other work units.
+
+
+12.8.2.3 Action ADV_TDS.2.2E
+
+
+ADV_TDS.2-9 The evaluator _**shall examine**_ the TOE security functional requirements and
+the TOE design, to determine that all ST security functional requirements are
+covered by the TOE design.
+
+
+834 The evaluator may construct a map between the TOE security functional
+requirements and the TOE design. This map will likely be from a functional
+requirement to a set of subsystems. Note that this map may have to be at a
+level of detail below the component or even element level of the
+requirements, because of operations (assignments, refinements, selections)
+performed on the functional requirement by the ST author.
+
+
+835 For example, the FDP_ACC.1 Subset access control component contains an
+element with assignments. If the ST contained, for instance, ten rules in the
+FDP_ACC.1 Subset access control assignment, and these ten rules were
+
+
+April 2017 Version 3.1 Page 179 of 430
+
+
+**Class ADV: Development**
+
+
+implemented in specific places within fifteen modules, it would be
+inadequate for the evaluator to map FDP_ACC.1 Subset access control to
+one subsystem and claim the work unit had been completed. Instead, the
+evaluator would map FDP_ACC.1 Subset access control (rule 1) to
+subsystem A, behaviours x, y, and z; FDP_ACC.1 Subset access control
+(rule 2) to subsystem A, behaviours x, p, and q; etc.
+
+
+ADV_TDS.2-10 The evaluator _**shall examine**_ the TOE design to determine that it is an
+accurate instantiation of all security functional requirements.
+
+
+836 The evaluator ensures that each security requirement listed in the TOE
+security functional requirements section of the ST has a corresponding
+design description in the TOE design that accurately details how the TSF
+meets that requirement. This requires that the evaluator identify a collection
+of subsystems that are responsible for implementing a given functional
+requirement, and then examine those subsystems to understand how the
+requirement is implemented. Finally, the evaluator would assess whether the
+requirement was accurately implemented.
+
+
+837 As an example, if the ST requirements specified a role-based access control
+mechanism, the evaluator would first identify the subsystems that contribute
+to this mechanism's implementation. This could be done by in-depth
+knowledge or understanding of the TOE design or by work done in the
+previous work unit. Note that this trace is only to identify the subsystems,
+and is not the complete analysis.
+
+
+838 The next step would be to understand what mechanism the subsystems
+implemented. For instance, if the design described an implementation of
+access control based on UNIX-style protection bits, the design would not be
+an accurate instantiation of those access control requirements present in the
+ST example used above. If the evaluator could not determine that the
+mechanism was accurately implemented because of a lack of detail, the
+evaluator would have to assess whether all of the SFR-enforcing subsystems
+have been identified, or if adequate detail had been provided for those
+subsystems.
+
+
+**12.8.3** **Evaluation of sub-activity (ADV_TDS.3)**
+
+
+12.8.3.1 Objectives
+
+
+839 The objective of this sub-activity is to determine whether the TOE design
+provides a description of the TOE in terms of subsystems sufficient to
+determine the TSF boundary, and provides a description of the TSF internals
+in terms of modules (and optionally higher-level abstractions). It provides a
+detailed description of the SFR-enforcing modules and enough information
+about the SFR-supporting and SFR-non-interfering modules for the evaluator
+to determine that the SFRs are completely and accurately implemented; as
+such, the TOE design provides an explanation of the implementation
+representation.
+
+
+Page 180 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+12.8.3.2 Input
+
+
+840 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the functional specification;
+
+
+c) security architecture description;
+
+
+d) the TOE design.
+
+
+12.8.3.3 Application notes
+
+
+841 There are three types of activity that the evaluator must undertake with
+respect to the TOE design. First, the evaluator determines that the TSF
+boundary has been adequately described. Second, the evaluator determines
+that the developer has provided documentation that conforms to the content
+and presentation requirements for this subsystem, and that is consistent with
+other documentation provided for the TOE. Finally, the evaluator must
+analyse the design information provided for the SFR-enforcing modules (at a
+detailed level) and the SFR-supporting and SFR-non-interfering modules (at
+a less detailed level) to understand how the system is implemented, and with
+that knowledge ensure that the TSFI in the functional specification are
+adequately described, and that the test information adequately tests the TSF
+(done in the Class ATE: Tests work units).
+
+
+842 It is important to note that while the developer is obligated to provide a
+complete description of the TSF (although SFR-enforcing modules will have
+more detail than the SFR-supporting or SFR-non-interfering modules), the
+evaluator is expected to use their judgement in performing their analysis.
+While the evaluator is expected to look at every module, the detail to which
+they examine each module may vary. The evaluator analyses each module in
+order to gain enough understanding to determine the effect of the
+functionality of the module on the security of the system, and the depth to
+which they need to analyse the module may vary depending on the module's
+role in the system. An important aspect of this analysis is that the evaluator
+should use the other documentation provided (TSS, functional specification,
+security architecture description, and the TSF internal document) in order to
+determine that the functionality that is described is correct, and that the
+implicit designation of SFR-supporting or SFR-non-interfering modules (see
+below) is supported by their role in the system architecture.
+
+
+843 The developer may designate modules as SFR-enforcing, SFR-supporting,
+and SFR non-interfering, but these โtagsโ are used only to describe the
+amount and type of information the developer must provide, and can be used
+to limit the amount of information the developer has to develop if their
+engineering process does not produce the documentation required. Whether
+the modules have been categorised by the developer or not, it is the
+evaluator's responsibility to determine that the modules have the appropriate
+information for their role (SFR-enforcing, etc.) in the TOE, and to obtain the
+
+
+April 2017 Version 3.1 Page 181 of 430
+
+
+**Class ADV: Development**
+
+
+appropriate information from the developer should the developer fail to
+provide the required information for a particular module.
+
+
+12.8.3.4 Action ADV_TDS.3.1E
+
+
+ADV_TDS.3.1C _**The design shall describe the structure of the TOE in terms of subsystems.**_
+
+
+ADV_TDS.3-1 The evaluator _**shall examine**_ the TOE design to determine that the structure
+of the entire TOE is described in terms of subsystems.
+
+
+844 The evaluator ensures that all of the subsystems of the TOE are identified.
+This description of the TOE will be used as input to work unit ADV_TDS.32, where the parts of the TOE that make up the TSF are identified. That is,
+this requirement is on the entire TOE rather than on only the TSF.
+
+
+845 The TOE (and TSF) may be described in multiple layers of abstraction (i.e.
+subsystems and modules). Depending upon the complexity of the TOE, its
+design may be described in terms of subsystems and modules, as described
+in CC Part 3 Annex A.4, ADV_TDS: Subsystems and Modules. For a very
+simple TOE that can be described solely at the โmoduleโ level (see
+ADV_TDS.3-2), this work unit is not applicable and therefore considered to
+be satisfied.
+
+
+846 In performing this activity, the evaluator examines other evidence presented
+for the TOE (e.g., ST, operator user guidance) to determine that the
+description of the TOE in such evidence is consistent with the description
+contained in the TOE design.
+
+
+ADV_TDS.3.2C _**The design shall describe the TSF in terms of modules.**_
+
+
+ADV_TDS.3-2 The evaluator _**shall examine**_ the TOE design to determine that the entire
+TSF is described in terms of modules.
+
+
+847 The evaluator will examine the modules for specific properties in other work
+units; in this work unit the evaluator determines that the modular description
+covers the entire TSF, and not just a portion of the TSF. The evaluator uses
+other evidence provided for the evaluation (e.g., functional specification,
+security architecture description) in making this determination. For example,
+if the functional specification contains interfaces to functionality that does
+not appear to be described in the TOE design description, it may be the case
+that a portion of the TSF has not been included appropriately. Making this
+determination will likely be an iterative process, where as more analysis is
+done on the other evidence, more confidence can be gained with respect to
+the completeness of the documentation.
+
+
+848 Unlike subsystems, modules describe the implementation in a level of detail
+that can serve as a guide to reviewing the implementation representation. A
+description of a module should be such that one could create an
+implementation of the module from the description, and the resulting
+implementation would be 1) identical to the actual TSF implementation in
+terms of the interfaces presented, 2) identical in the use of interfaces that are
+
+
+Page 182 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+mentioned in the design, and 3) functionally equivalent to the description of
+the purpose of the TSF module. For instance, RFC 793 provides a high-level
+description of the TCP protocol. It is necessarily implementation
+independent. While it provides a wealth of detail, it is _**not**_ a suitable design
+description because it is not specific to an implementation. An actual
+implementation can add to the protocol specified in the RFC, and
+implementation choices (for instance, the use of global data vs. local data in
+various parts of the implementation) may have an impact on the analysis that
+is performed. The design description of the TCP module would list the
+interfaces presented by the implementation (rather than just those defined in
+RFC 793), as well as an algorithm description of the processing associated
+with the modules implementing TCP (assuming it was part of the TSF).
+
+
+ADV_TDS.3.3C _**The design shall identify all subsystems of the TSF.**_
+
+
+ADV_TDS.3-3 The evaluator _**shall examine**_ the TOE design to determine that all
+subsystems of the TSF are identified.
+
+
+849 If the design is presented solely in terms of modules, then subsystems in
+these requirements are equivalent to modules and the activity should be
+performed at the module level.
+
+
+850 In work unit ADV_TDS.3-1 all of the subsystems of the TOE were identified,
+and a determination made that the non-TSF subsystems were correctly
+characterised. Building on that work, the subsystems that were not
+characterised as non-TSF subsystems should be precisely identified. The
+evaluator determines that, of the hardware and software installed and
+configured according to the Preparative procedures (AGD_PRE) guidance,
+each subsystem has been accounted for as either one that is part of the TSF,
+or one that is not.
+
+
+ADV_TDS.3.4C _**The design shall provide a description of each subsystem of the TSF.**_
+
+
+ADV_TDS.3-4 The evaluator _**shall examine**_ the TOE design to determine that each
+subsystem of the TSF describes its role in the enforcement of SFRs described
+in the ST.
+
+
+851 If the design is presented solely in terms of modules, then this work unit will
+be considered satisfied by the assessment done in subsequent work units; no
+explicit action on the part of the evaluator is necessary in this case.
+
+
+852 On systems that are complex enough to warrant a subsystem-level
+description of the TSF in addition to the modular description, the goal of the
+subsystem-level description is to give the evaluator context for the modular
+description that follows. Therefore, the evaluator ensures that the subsystemlevel description contains a description of how the security functional
+requirements are achieved in the design, but at a level of abstraction above
+the modular description. This description should discuss the mechanisms
+used at a level that is aligned with the module description; this will provide
+the evaluators the road map needed to intelligently assess the information
+contained in the module description. A well-written set of subsystem
+
+
+April 2017 Version 3.1 Page 183 of 430
+
+
+**Class ADV: Development**
+
+
+descriptions will help guide the evaluator in determining the modules that are
+most important to examine, thus focusing the evaluation activity on the
+portions of the TSF that have the most relevance with respect to the
+enforcement of the SFRs.
+
+
+853 The evaluator ensures that all subsystems of the TSF have a description.
+While the description should focus on the role that the subsystem plays in
+enforcing or supporting the implementation of the SFRs, enough information
+must be present so that a context for understanding the SFR-related
+functionality is provided.
+
+
+ADV_TDS.3-5 The evaluator _**shall examine**_ the TOE design to determine that each SFRnon-interfering subsystem of the TSF is described such that the evaluator can
+determine that the subsystem is SFR-non-interfering.
+
+
+854 If the design is presented solely in terms of modules, then this work unit will
+be considered satisfied by the assessment done in subsequent work units; no
+explicit action on the part of the evaluator is necessary in this case.
+
+
+855 An SFR-non-interfering subsystem is one on which the SFR-enforcing and
+SFR-supporting subsystems have no dependence; that is, they play no role in
+implementing SFR functionality.
+
+
+856 The evaluator ensures that all subsystems of the TSF have a description.
+While the description should focus on the role that the subsystem do not
+plays in enforcing or supporting the implementation of the SFRs, enough
+information must be present so that a context for understanding the SFRnon-interfering functionality is provided.
+
+
+ADV_TDS.3.5C _**The design shall provide a description of the interactions among all**_
+_**subsystems of the TSF.**_
+
+
+ADV_TDS.3-6 The evaluator _**shall examine**_ the TOE design to determine that interactions
+between the subsystems of the TSF are described.
+
+
+857 If the design is presented solely in terms of modules, then this work unit will
+be considered satisfied by the assessment done in subsequent work units; no
+explicit action on the part of the evaluator is necessary in this case.
+
+
+858 On systems that are complex enough to warrant a subsystem-level
+description of the TSF in addition to the modular description, the goal of
+describing the interactions between the subsystems is to help provide the
+reader a better understanding of how the TSF performs its functions. These
+interactions do not need to be characterised at the implementation level (e.g.,
+parameters passed from one routine in a subsystem to a routine in a different
+subsystem; global variables; hardware signals (e.g., interrupts) from a
+hardware subsystem to an interrupt-handling subsystem), but the data
+elements identified for a particular subsystem that are going to be used by
+another subsystem should be covered in this discussion. Any control
+relationships between subsystems (e.g., a subsystem responsible for
+
+
+Page 184 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+configuring a rule base for a firewall system and the subsystem that actually
+implements these rules) should also be described.
+
+
+859 It should be noted while the developer should characterise all interactions
+between subsystems, the evaluators need to use their own judgement in
+assessing the completeness of the description. If the reason for an interaction
+is unclear, or if there are SFR-related interactions (discovered, for instance,
+in examining the module-level documentation) that do not appear to be
+described, the evaluator ensures that this information is provided by the
+developer. However, if the evaluator can determine that interactions among a
+particular set of subsystems, while incompletely described by the developer,
+and a complete description will not aid in understanding the overall
+functionality nor security functionality provided by the TSF, then the
+evaluator may choose to consider the description sufficient, and not pursue
+completeness for its own sake.
+
+
+ADV_TDS.3.6C _**The design shall provide a mapping from the subsystems of the TSF to the**_
+_**modules of the TSF.**_
+
+
+ADV_TDS.3-7 The evaluator _**shall examine**_ the TOE design to determine that the mapping
+between the subsystems of the TSF and the modules of the TSF is complete.
+
+
+860 If the design is presented solely in terms of modules, then this work unit is
+considered satisfied.
+
+
+861 For TOEs that are complex enough to warrant a subsystem-level description
+of the TSF in addition to the modular description, the developer provides a
+simple mapping showing how the modules of the TSF are allocated to the
+subsystems. This will provide the evaluator a guide in performing their
+module-level assessment. To determine completeness, the evaluator
+examines each mapping and determines that all subsystems map to at least
+one module, and that all modules map to exactly one subsystem.
+
+
+ADV_TDS.3-8 The evaluator _**shall examine**_ the TOE design to determine that the mapping
+between the subsystems of the TSF and the modules of the TSF is accurate.
+
+
+862 If the design is presented solely in terms of modules, then this work unit is
+considered satisfied.
+
+
+863 For TOEs that are complex enough to warrant a subsystem-level description
+of the TSF in addition to the modular description, the developer provides a
+simple mapping showing how the modules of the TSF are allocated to the
+subsystems. This will provide the evaluator a guide in performing their
+module-level assessment. The evaluator may choose to check the accuracy of
+the mapping in conjunction with performing other work units. An
+โinaccurateโ mapping is one where the module is mistakenly associated with
+a subsystem where its functions are not used within the subsystem. Because
+the mapping is intended to be a guide supporting more detailed analysis, the
+evaluator is cautioned to apply appropriate effort to this work unit.
+Expending extensive evaluator resources verifying the accuracy of the
+mapping is not necessary. Inaccuracies that lead to mis-understandings
+
+
+April 2017 Version 3.1 Page 185 of 430
+
+
+**Class ADV: Development**
+
+
+related to the design that are uncovered as part of this or other work units are
+the ones that should be associated with this work unit and corrected.
+
+
+ADV_TDS.3.7C _**The design shall describe each SFR-enforcing module in terms of its**_
+_**purpose and relationship with other modules.**_
+
+
+ADV_TDS.3-9 The evaluator _**shall examine**_ the TOE design to determine that the
+description of the purpose of each SFR-enforcing module and relationship
+with other modules is complete and accurate.
+
+
+864 The developer may designate modules as SFR-enforcing, SFR-supporting,
+and SFR non-interfering, but these โtagsโ are used only to describe the
+amount and type of information the developer must provide, and can be used
+to limit the amount of information the developer has to develop if their
+engineering process does not produce the documentation required. Whether
+the modules have been categorised by the developer or not, it is the
+evaluator's responsibility to determine that the modules have the appropriate
+information for their role (SFR-enforcing, etc.) in the TOE, and to obtain the
+appropriate information from the developer should the developer fail to
+provide the required information for a particular module.
+
+
+865 The purpose of a module provides a description indicating what function the
+module is fulfilling. A word of caution to evaluator is in order. The focus of
+this work unit should be to provide the evaluator an understanding of how
+the module works so that determinations can be made about the soundness of
+the implementation of the SFRs, as well as to support architectural analysis
+performed for ADV_ARC component. As long as the evaluator has a sound
+understanding of the module's operation, and its relationship to other
+modules and the TOE as a whole, the evaluator should consider the objective
+of the work achieved and not engage in a documentation exercise for the
+developer (by requiring, for example, a complete algorithmic description for
+a self-evident implementation representation).
+
+
+866 Because the modules are at such a low level, it may be difficult determine
+completeness and accuracy impacts from other documentation, such as
+operational user guidance, the functional specification, the TSF internals, or
+the security architecture description. However, the evaluator uses the
+information present in those documents to the extent possible to help ensure
+that the purpose is accurately and completely described. This analysis can be
+aided by the analysis performed for the work units for the _**ADV_TDS.3.10C**_
+element, which maps the TSFI in the functional specification to the modules
+of the TSF.
+
+
+ADV_TDS.3.8C _**The design shall describe each SFR-enforcing module in terms of its SFR-**_
+_**related interfaces, return values from those interfaces, interaction with**_
+_**other modules and called SFR-related interfaces to other SFR-enforcing**_
+_**modules.**_
+
+
+ADV_TDS.3-10 The evaluator _**shall examine**_ the TOE design to determine that the
+description of the interfaces presented by each SFR-enforcing module
+contain an accurate and complete description of the SFR-related parameters,
+
+
+Page 186 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+the invocation conventions for each interface, and any values returned
+directly by the interface.
+
+
+867 The SFR-related interfaces of a module are those interfaces used by other
+modules as a means to invoke the SFR-related operations provided, and to
+provide inputs to or receive outputs from the module. The purpose in the
+specification of these interfaces is to permit the exercise of them during
+testing. Inter-module interfaces that are not SFR-related need not be
+specified or described, since they are not a factor in testing. Likewise, other
+internal interfaces that are not a factor in traversing SFR-related paths of
+execution (such as those internal paths that are fixed) need not be specified
+or described, since they are not a factor in testing.
+
+
+868 SFR-related interfaces are described in terms of how they are invoked, and
+any values that are returned. This description would include a list of SFRrelated parameters, and descriptions of these parameters. Note that global
+data would also be considered parameters if used by the module (either as
+inputs or outputs) when invoked. If a parameter were expected to take on a
+set of values (e.g., a โflagโ parameter), the complete set of values the
+parameter could take on that would have an effect on module processing
+would be specified. Likewise, parameters representing data structures are
+described such that each field of the data structure is identified and described.
+Note that different programming languages may have additional โinterfacesโ
+that would be non-obvious; an example would be operator/function
+overloading in C++. This โimplicit interfaceโ in the class description would
+also be described as part of the low-level TOE design. Note that although a
+module could present only one interface, it is more common that a module
+presents a small set of related interfaces.
+
+
+869 In terms of the assessment of parameters (inputs and outputs) to a module,
+any use of global data must also be considered. A module โusesโ global data
+if it either reads or writes the data. In order to assure the description of such
+parameters (if used) is complete, the evaluator uses other information
+provided about the module in the TOE design (interfaces, algorithmic
+description, etc.), as well as the description of the particular set of global data
+assessed in work unit ADV_TDS.3-10. For instance, the evaluator could first
+determine the processing the module performs by examining its function and
+interfaces presented (particularly the parameters of the interfaces). They
+could then check to see if the processing appears to โtouchโ any of the global
+data areas identified in the TOE design. The evaluator then determines that,
+for each global data area that appears to be โtouchedโ, that global data area is
+listed as a means of input or output by the module the evaluator is examining.
+
+
+870 Invocation conventions are a programming-reference-type description that
+one could use to correctly invoke a module's interface if one were writing a
+program to make use of the module's functionality through that interface.
+This includes necessary inputs and outputs, including any set-up that may
+need to be performed with respect to global variables.
+
+
+871 Values returned through the interface refer to values that are either passed
+through parameters or messages; values that the function call itself returns in
+
+
+April 2017 Version 3.1 Page 187 of 430
+
+
+**Class ADV: Development**
+
+
+the style of a โCโ program function call; or values passed through global
+means (such as certain error routines in *ix-style operating systems).
+
+
+872 In order to assure the description is complete, the evaluator uses other
+information provided about the module in the TOE design (e.g., algorithmic
+description, global data used) to ensure that it appears all data necessary for
+performing the functions of the module is presented to the module, and that
+any values that other modules expect the module under examination to
+provide are identified as being returned by the module. The evaluator
+determines accuracy by ensuring that the description of the processing
+matches the information listed as being passed to or from an interface.
+
+
+ADV_TDS.3.9C _**The design shall describe each SFR-supporting or SFR-non-interfering**_
+_**module in terms of its purpose and interaction with other modules.**_
+
+
+ADV_TDS.3-11 The evaluator _**shall examine**_ the TOE design to determine that SFRsupporting and SFR-non-interfering modules are correctly categorised.
+
+
+873 In the cases where the developer has provided different amounts of
+information for different modules, an implicit categorisation has been done.
+That is, modules (for instance) with detail presented on their SFR-related
+interfaces (see _**ADV_TDS.3.10C**_ ) are candidate SFR-enforcing modules,
+although examination by the evaluator may lead to a determination that some
+set of them are SFR-supporting or SFR-non-interfering. Those with only a
+description of their purpose and interaction with other modules (for instance)
+are โimplicitly categorisedโ as SFR-supporting or SFR-non-interfering.
+
+
+874 In these cases, a key focus of the evaluator for this work unit is attempting to
+determine from the evidence provided for each module implicitly categorised
+as SFR-supporting or SFR-non-interfering and the evaluation information
+about other modules (in the TOE design, the functional specification, the
+security architecture description, and the operational user guidance), whether
+the module is indeed SFR-supporting or SFR-non-interfering. At this level of
+assurance some error should be tolerated; the evaluator does not have to be
+absolutely sure that a given module is SFR-supporting or SFR-noninterfering, even though it is labelled as such. However, if the evidence
+provided indicates that a SFR-supporting or SFR-non-interfering module is
+SFR-enforcing, the evaluator requests additional information from the
+developer in order to resolve the apparent inconsistency. For instance,
+suppose the documentation for Module A (an SFR-enforcing module)
+indicates that it calls Module B to perform an access check on a certain type
+of construct. When the evaluator examines the information associated with
+Module B, they find that all the developer has provided is a purpose and a set
+of interactions (thus implicitly categorising Module B as SFR-supporting or
+SFR-non-interfering). On examining the purpose and interactions from
+Module A, the evaluator finds no mention of Module B performing any
+access checks, and Module A is not listed as a module with which Module B
+interacts. At this point the evaluator should approach the developer to resolve
+the discrepancies between the information provided in Module A and that in
+Module B.
+
+
+Page 188 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+875 Another example would be where the evaluator examines the mapping of the
+TSFI to the modules as provided by ADV_TDS.3.2D. This examination
+shows that Module C is associated with an SFR requiring identification of
+the user. Again, when the evaluator examines the information associated
+with Module C, they find that all the developer has provided is a purpose and
+a set of interactions (thus implicitly categorising Module C as SFRsupporting or SFR-non-interfering). Examining the purpose and interactions
+presented for Module C, the evaluator is unable to determine why Module C,
+listed as mapping to a TSFI concerned with user identification, would not be
+classified as SFR-enforcing. Again, the evaluator should approach the
+developer to resolve this discrepancy.
+
+
+876 A final example is from the opposite point of view. As before, the developer
+has provided information associated with Module D consisting of a purpose
+and a set of interactions (thus implicitly categorising Module D as SFRsupporting or SFR-non-interfering). The evaluator examines all of the
+evidence provided, including the purpose and interactions for Module D. The
+purpose appears to give a meaningful description of Module D's function in
+the TOE, the interactions are consistent with that description, and there is
+nothing to indicate that Module D is SFR-enforcing. In this case, the
+evaluator should not demand more information about Module D โjust be to
+sureโ it is correctly categorised. The developer has met their obligations and
+the resulting assurance the evaluator has in the implicit categorisation of
+Module D is (by definition) appropriate for this assurance level.
+
+
+ADV_TDS.3-12 The evaluator _**shall examine**_ the TOE design to determine that the
+description of the purpose of each SFR-supporting or SFR-non-interfering
+module is complete and accurate.
+
+
+877 The description of the purpose of a module indicates what function the
+module is fulfilling. From the description, the evaluator should be able to
+obtain a general idea of the module's role. In order to assure the description
+is complete, the evaluator uses the information provided about the module's
+interactions with other modules to assess whether the reasons for the module
+being called are consistent with the module's purpose. If the interaction
+description contains functionality that is not apparent from, or in conflict
+with, the module's purpose, the evaluator needs to determine whether the
+problem is one of accuracy or of completeness. The evaluator should be wary
+of purposes that are too short, since meaningful analysis based on a onesentence purpose is likely to be impossible.
+
+
+878 Because the modules are at such a low level, it may be difficult determine
+completeness and accuracy impacts from other documentation, such as
+administrative guidance, the functional specification, the security
+architecture description, or the TSF internals document. However, the
+evaluator uses the information present in those documents to the extent
+possible to help ensure that the function is accurately and completely
+described. This analysis can be aided by the analysis performed for the work
+units for the ADV_TDS.3.10C element, which maps the TSFI in the
+functional specification to the modules of the TSF.
+
+
+April 2017 Version 3.1 Page 189 of 430
+
+
+**Class ADV: Development**
+
+
+ADV_TDS.3-13 The evaluator _**shall examine**_ the TOE design to determine that the
+description of a SFR-supporting or SFR-non-interfering module's interaction
+with other modules is complete and accurate.
+
+
+879 It is important to note that, in terms of the Part 3 requirement and this work
+unit, the term _interaction_ is intended to convey less rigour than _interface_ . An
+interaction does not need to be characterised at the implementation level (e.g.,
+parameters passed from one routine in a module to a routine in a different
+module; global variables; hardware signals (e.g., interrupts) from a hardware
+subsystem to an interrupt-handling subsystem), but the data elements
+identified for a particular module that are going to be used by another
+module should be covered in this discussion. Any control relationships
+between modules (e.g., a module responsible for configuring a rule base for a
+firewall system and the module that actually implements these rules) should
+also be described.
+
+
+880 Because the modules are at such a low level, it may be difficult determine
+completeness and accuracy impacts from other documentation, such as
+operational user guidance, the functional specification, the security
+architecture description, or the TSF internals document. However, the
+evaluator uses the information present in those documents to the extent
+possible to help ensure that the function is accurately and completely
+described. This analysis can be aided by the analysis performed for the work
+units for the _**ADV_TDS.3.10C**_ element, which maps the TSFI in the
+functional specification to the modules of the TSF.
+
+
+881 A module's interaction with other modules goes beyond just a call-tree-type
+document. The interaction is described from a functional perspective of why
+a module interacts with other modules. The module's purpose describes what
+functions the module provides to other modules; the interactions should
+describe what the module depends on from other modules in order to
+accomplish this function.
+
+
+ADV_TDS.3.10C _**The mapping shall demonstrate that all TSFIs trace to the behaviour**_
+_**described in the TOE design that they invoke.**_
+
+
+ADV_TDS.3-14 The evaluator _**shall examine**_ the TOE design to determine that it contains a
+complete and accurate mapping from the TSFI described in the functional
+specification to the modules of the TSF described in the TOE design.
+
+
+882 The modules described in the TOE design provide a description of the
+implementation of the TSF. The TSFI provide a description of how the
+implementation is exercised. The evidence from the developer identifies the
+module that is initially invoked when an operation is requested at the TSFI,
+and identifies the chain of modules invoked up to the module that is
+primarily responsible for implementing the functionality. However, a
+complete call tree for each TSFI is not required for this work unit. The cases
+in which more than one module would have to be identified are where there
+are โentry pointโ modules or wrapper modules that have no functionality
+other than conditioning inputs or de-multiplexing an input. Mapping to one
+of these modules would not provide any useful information to the evaluator.
+
+
+Page 190 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+883 The evaluator assesses the completeness of the mapping by ensuring that all
+of the TSFI map to at least one module. The verification of accuracy is more
+complex.
+
+
+884 The first aspect of accuracy is that each TSFI is mapped to a module at the
+TSF boundary. This determination can be made by reviewing the module
+description and its interfaces/interactions. The next aspect of accuracy is that
+each TSFI identifies a chain of modules between the initial module identified
+and a module that is primarily responsible for implementing the function
+presented at the TSF. Note that this may be the initial module, or there may
+be several modules, depending on how much pre-conditioning of the inputs
+is done. It should be noted that one indicator of a pre-conditioning module is
+that it is invoked for a large number of the TSFI, where the TSFI are all of
+similar type (e.g., system call). The final aspect of accuracy is that the
+mapping makes sense. For instance, mapping a TSFI dealing with access
+control to a module that checks passwords is not accurate. The evaluator
+should again use judgement in making this determination. The goal is that
+this information aids the evaluator in understanding the system and
+implementation of the SFRs, and ways in which entities at the TSF boundary
+can interact with the TSF. The bulk of the assessment of whether the SFRs
+are described accurately by the modules is performed in other work units.
+
+
+12.8.3.5 Action ADV_TDS.3.2E
+
+
+ADV_TDS.3-15 The evaluator _**shall examine**_ the TOE security functional requirements and
+the TOE design, to determine that all ST security functional requirements are
+covered by the TOE design.
+
+
+885 The evaluator may construct a map between the TOE security functional
+requirements and the TOE design. This map will likely be from a functional
+requirement to a set of subsystems, and later to modules. Note that this map
+may have to be at a level of detail below the component or even element
+level of the requirements, because of operations (assignments, refinements,
+selections) performed on the functional requirement by the ST author.
+
+
+886 For example, the FDP_ACC.1 Subset access control component contains an
+element with assignments. If the ST contained, for instance, ten rules in the
+FDP_ACC.1 Subset access control assignment, and these ten rules were
+implemented in specific places within fifteen modules, it would be
+inadequate for the evaluator to map FDP_ACC.1 Subset access control to
+one subsystem and claim the work unit had been completed. Instead, the
+evaluator would map FDP_ACC.1 Subset access control (rule 1) to modules
+x, y, and z of subsystem A; FDP_ACC.1 Subset access control (rule 2) to
+modules x, p, and q of subsystem A; etc.
+
+
+ADV_TDS.3-16 The evaluator _**shall examine**_ the TOE design to determine that it is an
+accurate instantiation of all security functional requirements.
+
+
+887 The evaluator may construct a map between the TOE security functional
+requirements and the TOE design. This map will likely be from a functional
+requirement to a set of subsystems. Note that this map may have to be at a
+
+
+April 2017 Version 3.1 Page 191 of 430
+
+
+**Class ADV: Development**
+
+
+level of detail below the component or even element level of the
+requirements, because of operations (assignments, refinements, selections)
+performed on the functional requirement by the ST author.
+
+
+888 As an example, if the ST requirements specified a role-based access control
+mechanism, the evaluator would first identify the subsystems, and modules
+that contribute to this mechanism's implementation. This could be done by
+in-depth knowledge or understanding of the TOE design or by work done in
+the previous work unit. Note that this trace is only to identify the subsystems,
+and modules, and is not the complete analysis.
+
+
+889 The next step would be to understand what mechanism the subsystems, and
+modules implemented. For instance, if the design described an
+implementation of access control based on UNIX-style protection bits, the
+design would not be an accurate instantiation of those access control
+requirements present in the ST example used above. If the evaluator could
+not determine that the mechanism was accurately implemented because of a
+lack of detail, the evaluator would have to assess whether all of the SFRenforcing subsystems and modules have been identified, or if adequate detail
+had been provided for those subsystems and modules.
+
+
+**12.8.4** **Evaluation of sub-activity (ADV_TDS.4)**
+
+
+12.8.4.1 Objectives
+
+
+890 The objective of this sub-activity is to determine whether the TOE design
+provides a description of the TOE in terms of subsystems sufficient to
+determine the TSF boundary, and provides a description of the TSF internals
+in terms of modules (and optionally higher-level abstractions). It provides a
+detailed description of the SFR-enforcing and SFR-supporting modules and
+enough information about the SFR-non-interfering modules for the evaluator
+to determine that the SFRs are completely and accurately implemented; as
+such, the TOE design provides an explanation of the implementation
+representation.
+
+
+12.8.4.2 Input
+
+
+891 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the functional specification;
+
+
+c) security architecture description;
+
+
+d) the TOE design.
+
+
+12.8.4.3 Application notes
+
+
+892 There are three types of activity that the evaluator must undertake with
+respect to the TOE design. First, the evaluator determines that the TSF
+boundary has been adequately described. Second, the evaluator determines
+
+
+Page 192 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+that the developer has provided documentation that conforms to the content
+and presentation requirements this subsystem, and that is consistent with
+other documentation provided for the TOE. Finally, the evaluator must
+analyse the design information provided for the SFR-enforcing modules (at a
+detailed level) and the SFR-supporting and SFR-non-interfering modules (at
+a less detailed level) to understand how the system is implemented, and with
+that knowledge ensure that the TSFI in the functional specification are
+adequately described, and that the test information adequately tests the TSF
+(done in the Class ATE: Tests work units).
+
+
+12.8.4.4 Action ADV_TDS.4.1E
+
+
+ADV_TDS.4.1C _**The design shall describe the structure of the TOE in terms of subsystems.**_
+
+
+ADV_TDS.4-1 The evaluator _**shall examine**_ the TOE design to determine that the structure
+of the entire TOE is described in terms of subsystems.
+
+
+893 The evaluator ensures that all of the subsystems of the TOE are identified.
+This description of the TOE will be used as input to work unit ADV_TDS.44, where the parts of the TOE that make up the TSF are identified. That is,
+this requirement is on the entire TOE rather than on only the TSF.
+
+
+894 The TOE (and TSF) may be described in multiple layers of abstraction (i.e.
+subsystems and modules) Depending upon the complexity of the TOE, its
+design may be described in terms of subsystems and modules, as described
+in CC Part 3 Annex A.4, ADV_TDS: Subsystems and Modules. For a very
+simple TOE that can be described solely at the โmoduleโ level (see
+ADV_TDS.4-2), this work unit is not applicable and therefore considered to
+be satisfied.
+
+
+895 In performing this activity, the evaluator examines other evidence presented
+for the TOE (e.g., ST, operator user guidance) to determine that the
+description of the TOE in such evidence is consistent with the description
+contained in the TOE design.
+
+
+ADV_TDS.4.2C _**The design shall describe the TSF in terms of modules, designating each**_
+_**module as SFR-enforcing, SFR-supporting, or SFR-non-interfering.**_
+
+
+ADV_TDS.4-2 The evaluator _**shall examine**_ the TOE design to determine that the entire
+TSF is described in terms of modules.
+
+
+896 The evaluator will examine the modules for specific properties in other work
+units; in this work unit the evaluator determines that the modular description
+covers the entire TSF, and not just a portion of the TSF. The evaluator uses
+other evidence provided for the evaluation (e.g., functional specification,
+architectural description) in making this determination. For example, if the
+functional specification contains interfaces to functionality that does not
+appear to be described in the TOE design description, it may be the case that
+a portion of the TSF has not been included appropriately. Making this
+determination will likely be an iterative process, where as more analysis is
+
+
+April 2017 Version 3.1 Page 193 of 430
+
+
+**Class ADV: Development**
+
+
+done on the other evidence, more confidence can be gained with respect to
+the completeness of the documentation.
+
+
+897 Unlike subsystems, modules describe the implementation in a level of detail
+that can serve as a guide to reviewing the implementation representation. A
+description of a module should be such that one could create an
+implementation of the module from the description, and the resulting
+implementation would be 1) identical to the actual TSF implementation in
+terms of the interfaces presented, 2) identical in the use of interfaces that are
+mentioned in the design, and 3) functionally equivalent to the description of
+the purpose of the TSF module. For instance, RFC 793 provides a high-level
+description of the TCP protocol. It is necessarily implementation
+independent. While it provides a wealth of detail, it is _**not**_ a suitable design
+description because it is not specific to an implementation. An actual
+implementation can add to the protocol specified in the RFC, and
+implementation choices (for instance, the use of global data vs. local data in
+various parts of the implementation) may have an impact on the analysis that
+is performed. The design description of the TCP module would list the
+interfaces presented by the implementation (rather than just those defined in
+RFC 793), as well as an algorithm description of the processing associated
+with the modules implementing TCP (assuming it was part of the TSF).
+
+
+ADV_TDS.4-3 The evaluator _**shall check**_ the TOE design to determine that the TSF
+modules are identified as either SFR-enforcing, SFR-supporting, or SFRnon-interfering.
+
+
+898 The purpose of designating each module (according to the role a particular
+module plays in the enforcement of the SFRs) is to allow developers to
+provide less information about the parts of the TSF that have little role in
+security. It is always permissible for the developer to provide more
+information or detail than the requirements demand, as might occur when the
+information has been gathered outside the evaluation context. In such cases
+the developer must still designate the modules as either SFR-enforcing, SFRsupporting, or SFR-non-interfering.
+
+
+899 The accuracy of these designations is continuously reviewed as the
+evaluation progresses. The concern is the mis-designation of modules as
+being less important (and hence, having less information) than is really the
+case. While blatant mis-designations may be immediately apparent (e.g.,
+designating an authentication module as anything but SFR-enforcing when
+User identification (FIA_UID) is one of the SFRs being claimed), other misdesignations might not be discovered until the TSF is better understood. The
+evaluator must therefore keep in mind that these designations are the
+developer's initial best effort, but are subject to change. Further guidance is
+provided under work unit ADV_TDS.4-17, which examines the accuracy of
+these designations.
+
+
+ADV_TDS.4.3C _**The design shall identify all subsystems of the TSF.**_
+
+
+ADV_TDS.4-4 The evaluator _**shall examine**_ the TOE design to determine that all
+subsystems of the TSF are identified.
+
+
+Page 194 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+900 If the design is presented solely in terms of modules, then subsystems in
+these requirements are equivalent to modules and the activity should be
+performed at the module level.
+
+
+901 In work unit ADV_TDS.4-1 all of the subsystems of the TOE were identified,
+and a determination made that the non-TSF subsystems were correctly
+characterised. Building on that work, the subsystems that were not
+characterised as non-TSF subsystems should be precisely identified. The
+evaluator determines that, of the hardware and software installed and
+configured according to the Preparative procedures (AGD_PRE) guidance,
+each subsystem has been accounted for as either one that is part of the TSF,
+or one that is not.
+
+
+ADV_TDS.4.4C _**The design shall provide a semiformal description of each subsystem of the**_
+_**TSF, supported by informal, explanatory text where appropriate.**_
+
+
+ADV_TDS.4-5 The evaluator _**shall examine**_ the TDS documentation to determine that the
+semiformal notation used for describing the subsystems, modules and their
+interfaces is defined or referenced.
+
+
+902 A semiformal notation can be either defined by the sponsor or a
+corresponding standard be referenced. The evaluator should provide a
+mapping of security functions and their interfaces outlining in what part of
+the documentation a function or interface is semiformal described and what
+notation is used. The evaluator examines all semiformal notations used to
+make sure that they are of a semiformal style and to justify the
+appropriateness of the manner how the semiformal notations are used for the
+TOE.
+
+
+903 The evaluator is reminded that a semi-formal presentation is characterised by
+a standardised format with a well-defined syntax that reduces ambiguity that
+may occur in informal presentations. The syntax of all semiformal notations
+used in the functional specification shall be defined or a corresponding
+standard be referenced. The evaluator verifies that the semiformal notations
+used for expressing the functional specification are capable of expressing
+features relevant to security. In order to determine this, the evaluator can
+refer to the SFR and compare the TSF security features stated in the ST and
+those described in the FSP using the semiformal notations.
+
+
+ADV_TDS.4-6 The evaluator _**shall examine**_ the TOE design to determine that each
+subsystem of the TSF describes its role in the enforcement of SFRs described
+in the ST.
+
+
+904 If the design is presented solely in terms of modules, then this work unit will
+be considered satisfied by the assessment done in subsequent work units; no
+explicit action on the part of the evaluator is necessary in this case.
+
+
+905 On systems that are complex enough to warrant a subsystem-level
+description of the TSF in addition to the modular description, the goal of the
+subsystem-level description is to give the evaluator context for the modular
+description that follows. Therefore, the evaluator ensures that the subsystem
+
+April 2017 Version 3.1 Page 195 of 430
+
+
+**Class ADV: Development**
+
+
+level description contains a description of how the security functional
+requirements are achieved in the design, but at a level of abstraction above
+the modular description. This description should discuss the mechanisms
+used at a level that is aligned with the module description; this will provide
+the evaluators the road map needed to intelligently assess the information
+contained in the module description. A well-written set of subsystem
+descriptions will help guide the evaluator in determining the modules that are
+most important to examine, thus focusing the evaluation activity on the
+portions of the TSF that have the most relevance with respect to the
+enforcement of the SFRs.
+
+
+906 The evaluator ensures that all subsystems of the TSF have a description.
+While the description should focus on the role that the subsystem plays in
+enforcing or supporting the implementation of the SFRs, enough information
+must be present so that a context for understanding the SFR-related
+functionality is provided.
+
+
+ADV_TDS.4-7 The evaluator _**shall examine**_ the TOE design to determine that each SFRnon-interfering subsystem of the TSF is described such that the evaluator can
+determine that the subsystem is SFR-non-interfering.
+
+
+907 If the design is presented solely in terms of modules, then this work unit will
+be considered satisfied by the assessment done in subsequent work units; no
+explicit action on the part of the evaluator is necessary in this case.
+
+
+908 An SFR-non-interfering subsystem is one on which the SFR-enforcing and
+SFR-supporting subsystems have no dependence; that is, they play no role in
+implementing SFR functionality.
+
+
+909 The evaluator ensures that all subsystems of the TSF have a description.
+While the description should focus on the role that the subsystem do not
+plays in enforcing or supporting the implementation of the SFRs, enough
+information must be present so that a context for understanding the SFRnon-interfering functionality is provided.
+
+
+ADV_TDS.4.5C _**The design shall provide a description of the interactions among all**_
+_**subsystems of the TSF.**_
+
+
+ADV_TDS.4-8 The evaluator _**shall examine**_ the TOE design to determine that interactions
+between the subsystems of the TSF are described.
+
+
+910 If the design is presented solely in terms of modules, then this work unit will
+be considered satisfied by the assessment done in subsequent work units; no
+explicit action on the part of the evaluator is necessary in this case.
+
+
+911 On systems that are complex enough to warrant a subsystem-level
+description of the TSF in addition to the modular description, the goal of
+describing the interactions between the subsystems is to help provide the
+reader a better understanding of how the TSF performs it functions. These
+interactions do not need to be characterised at the implementation level (e.g.,
+parameters passed from one routine in a subsystem to a routine in a different
+
+
+Page 196 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+subsystem; global variables; hardware signals (e.g., interrupts) from a
+hardware subsystem to an interrupt-handling subsystem), but the data
+elements identified for a particular subsystem that are going to be used by
+another subsystem need to be covered in this discussion. Any control
+relationships between subsystems (e.g., a subsystem responsible for
+configuring a rule base for a firewall system and the subsystem that actually
+implements these rules) should also be described.
+
+
+912 It should be noted while the developer should characterise all interactions
+between subsystems, the evaluators need to use their own judgement in
+assessing the completeness of the description. If the reason for an interaction
+is unclear, or if there are SFR-related interactions (discovered, for instance,
+in examining the module-level documentation) that do not appear to be
+described, the evaluator ensures that this information is provided by the
+developer. However, if the evaluator can determine that interactions among a
+particular set of subsystems, while incompletely described by the developer,
+and a complete description will not aid in understanding the overall
+functionality nor security functionality provided by the TSF, then the
+evaluator may choose to consider the description sufficient, and not pursue
+completeness for its own sake.
+
+
+ADV_TDS.4.6C _**The design shall provide a mapping from the subsystems of the TSF to the**_
+_**modules of the TSF.**_
+
+
+ADV_TDS.4-9 The evaluator _**shall examine**_ the TOE design to determine that the mapping
+between the subsystems of the TSF and the modules of the TSF is complete.
+
+
+913 If the design is presented solely in terms of modules, then this work unit is
+considered satisfied.
+
+
+914 For TOEs that are complex enough to warrant a subsystem-level description
+of the TSF in addition to the modular description, the developer provides a
+simple mapping showing how the modules of the TSF are allocated to the
+subsystems. This will provide the evaluator a guide in performing their
+module-level assessment. To determine completeness, the evaluator
+examines each mapping and determines that all subsystems map to at least
+one module, and that all modules map to exactly one subsystem.
+
+
+ADV_TDS.4-10 The evaluator _**shall examine**_ the TOE design to determine that the mapping
+between the subsystems of the TSF to the modules of the TSF is accurate.
+
+
+915 If the design is presented solely in terms of modules, then this work unit is
+considered satisfied.
+
+
+916 For TOEs that are complex enough to warrant a subsystem-level description
+of the TSF in addition to the modular description, the developer provides a
+simple mapping showing how the modules of the TSF are allocated to the
+subsystems. This will provide the evaluator a guide in performing their
+module-level assessment. The evaluator may choose to check the accuracy of
+the mapping in conjunction with performing other work units. An
+โinaccurateโ mapping is one where the module is mistakenly associated with
+
+
+April 2017 Version 3.1 Page 197 of 430
+
+
+**Class ADV: Development**
+
+
+a subsystem where its functions are not used within the subsystem. Because
+the mapping is intended to be a guide supporting more detailed analysis, the
+evaluator is cautioned to apply appropriate effort to this work unit.
+Expending extensive evaluator resources verifying the accuracy of the
+mapping is not necessary. Inaccuracies that lead to mis-understandings
+related to the design that are uncovered as part of this or other work units are
+the ones that should be associated with this work unit and corrected.
+
+
+ADV_TDS.4.7C _**The design shall describe each SFR-enforcing and SFR-supporting**_
+_**module in terms of its purpose and relationship with other modules.**_
+
+
+ADV_TDS.4-11 The evaluator _**shall examine**_ the TOE design to determine that the
+description of the purpose of each SFR-enforcing and SFR-supporting
+module, and relationship with other modules is complete and accurate.
+
+
+917 The developer may designate modules as SFR-enforcing, SFR-supporting,
+and SFR non-interfering, but these โtagsโ are used only to describe the
+amount and type of information the developer must provide, and can be used
+to limit the amount of information the developer has to develop if their
+engineering process does not produce the documentation required. Whether
+the modules have been categorised by the developer or not, it is the
+evaluator's responsibility to determine that the modules have the appropriate
+information for their role (SFR-enforcing, etc.) in the TOE, and to obtain the
+appropriate information from the developer should the developer fail to
+provide the required information for a particular module.
+
+
+918 The purpose of a module provides a description indicating what function the
+module is fulfilling. A word of caution to evaluator is in order. The focus of
+this work unit should be to provide the evaluator an understanding of how
+the module works so that determinations can be made about the soundness of
+the implementation of the SFRs, as well as to support architectural analysis
+performed for ADV_ARC subsystems. As long as the evaluator has a sound
+understanding of the module's operation, and its relationship to other
+modules and the TOE as a whole, the evaluator should consider the objective
+of the work achieved and not engage in a documentation exercise for the
+developer (by requiring, for example, a complete algorithmic description for
+a self-evident implementation representation).
+
+
+919 Because the modules are at such a low level, it may be difficult determine
+completeness and accuracy impacts from other documentation, such as
+operational user guidance, the functional specification, the TSF internals, or
+the security architecture description. However, the evaluator uses the
+information present in those documents to the extent possible to help ensure
+that the purpose is accurately and completely described. This analysis can be
+aided by the analysis performed for the work units for the _**ADV_TDS.4.10C**_
+element, which maps the TSFI in the functional specification to the modules
+of the TSF.
+
+
+ADV_TDS.4.8C _**The design shall describe each SFR-enforcing and SFR-supporting**_
+_**module in terms of its SFR-related interfaces, return values from those**_
+
+
+Page 198 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+_**interfaces, interaction with other modules and called SFR-related**_
+_**interfaces to other SFR-enforcing or SFR-supporting modules.**_
+
+
+ADV_TDS.4-12 The evaluator _**shall examine**_ the TOE design to determine that the
+description of the interfaces presented by each SFR-enforcing and SFRsupporting module contain an accurate and complete description of the SFRrelated parameters, the invocation conventions for each interface, and any
+values returned directly by the interface.
+
+
+920 The SFR-related interfaces of a module are those interfaces used by other
+modules as a means to invoke the SFR-related operations provided, and to
+provide inputs to or receive outputs from the module. The purpose in the
+specification of these interfaces is to permit the exercise of them during
+testing. Inter-module interfaces that are not SFR-related need not be
+specified or described, since they are not a factor in testing. Likewise, other
+internal interfaces that are not a factor in traversing SFR-related paths of
+execution (such as those internal paths that are fixed).
+
+
+921 SFR-related interfaces of SFR-supporting modules are all interfaces of SFRsupporting modules that are called directly or indirectly from SFR-enforcing
+modules. Those interfaces need to be described with all the parameter used in
+such a call. This allows the evaluator to understand the purpose of the call to
+the SFR-supporting module in the context of operation of the SFR-enforcing
+modules.
+
+
+922 SFR-related interfaces are described in terms of how they are invoked, and
+any values that are returned. This description would include a list of
+parameters, and descriptions of these parameters. Note that global data
+would also be considered parameters if used by the module (either as inputs
+or outputs) when invoked. If a parameter were expected to take on a set of
+values (e.g., a โflagโ parameter), the complete set of values the parameter
+could take on that would have an effect on module processing would be
+specified. Likewise, parameters representing data structures are described
+such that each field of the data structure is identified and described. Note that
+different programming languages may have additional โinterfacesโ that
+would be non-obvious; an example would be operator/function overloading
+in C++. This โimplicit interfaceโ in the class description would also be
+described as part of the low-level TOE design. Note that although a module
+could present only one interface, it is more common that a module presents a
+small set of related interfaces.
+
+
+923 In terms of the assessment of parameters (inputs and outputs) to a module,
+any use of global data must also be considered. A module โusesโ global data
+if it either reads or writes the data. In order to assure the description of such
+parameters (if used) is complete, the evaluator uses other information
+provided about the module in the TOE design (interfaces, algorithmic
+description, etc.), as well as the description of the particular set of global data
+assessed in work unit ADV_TDS.4-12. For instance, the evaluator could first
+determine the processing the module performs by examining its function and
+interfaces presented (particularly the parameters of the interfaces). They
+could then check to see if the processing appears to โtouchโ any of the global
+
+
+April 2017 Version 3.1 Page 199 of 430
+
+
+**Class ADV: Development**
+
+
+data areas identified in the TDS design. The evaluator then determines that,
+for each global data area that appears to be โtouchedโ, that global data area is
+listed as a means of input or output by the module the evaluator is examining.
+
+
+924 Invocation conventions are a programming-reference-type description that
+one could use to correctly invoke a module's interface if one were writing a
+program to make use of the module's functionality through that interface.
+This includes necessary inputs and outputs, including any set-up that may
+need to be performed with respect to global variables.
+
+
+925 Values returned through the interface refer to values that are either passed
+through parameters or messages; values that the function call itself returns in
+the style of a โCโ program function call; or values passed through global
+means (such as certain error routines in *ix-style operating systems).
+
+
+926 In order to assure the description is complete, the evaluator uses other
+information provided about the module in the TOE design (e.g., algorithmic
+description, global data used) to ensure that it appears all data necessary for
+performing the functions of the module is presented to the module, and that
+any values that other modules expect the module under examination to
+provide are identified as being returned by the module. The evaluator
+determines accuracy by ensuring that the description of the processing
+matches the information listed as being passed to or from an interface.
+
+
+ADV_TDS.4.9C _**The design shall describe each SFR-non-interfering module in terms of its**_
+_**purpose and interaction with other modules.**_
+
+
+ADV_TDS.4-13 The evaluator _**shall examine**_ the TOE design to determine that SFR-noninterfering modules are correctly categorised.
+
+
+927 As mentioned in work unit ADV_TDS.4-2, less information is required
+about modules that are SFR-non-interfering. A key focus of the evaluator for
+this work unit is attempting to determine from the evidence provided for
+each module implicitly categorised as SFR-non-interfering and the
+evaluation (information about other modules in the TOE design, the
+functional specification, the security architecture description, the operational
+user guidance, the TSF internals document, and perhaps even the
+implementation representation) whether the module is indeed SFR-noninterfering. At this level of assurance some error should be tolerated; the
+evaluator does not have to be absolutely sure that a given module is SFRnon-interfering, even though it is labelled as such. However, if the evidence
+provided indicates that a SFR-non-interfering module is SFR-enforcing or
+SFR-supporting, the evaluator requests additional information from the
+developer in order to resolve the apparent inconsistency. For example,
+suppose the documentation for Module A (an SFR-enforcing module)
+indicates that it calls Module B to perform an access check on a certain type
+of construct. When the evaluator examines the information associated with
+Module B, it is discovered that the only information the developer has
+provided is a purpose and a set of interactions (thus implicitly categorising
+Module B as SFR-supporting or SFR-non-interfering). On examining the
+purpose and interactions from Module A, the evaluator finds no mention of
+
+
+Page 200 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+Module B performing any access checks, and Module A is not listed as a
+module with which Module B interacts. At this point the evaluator should
+approach the developer to resolve the discrepancies between the information
+provided in Module A and that in Module B.
+
+
+928 Another example would be where the evaluator examines the mapping of the
+TSFI to the modules as provided by ADV_TDS.4.2D. This examination
+shows that Module C is associated with an SFR requiring identification of
+the user. Again, when the evaluator examines the information associated
+with Module C, they find that all the developer has provided is a purpose and
+a set of interactions (thus implicitly categorising Module C as SFR-noninterfering). Examining the purpose and interactions presented for Module C,
+the evaluator is unable to determine why Module C, listed as mapping to a
+TSFI concerned with user identification, would not be classified as SFRenforcing or SFR-supporting. Again, the evaluator should approach the
+developer to resolve this discrepancy.
+
+
+929 A final example illustrates the opposite situation. As before, the developer
+has provided information associated with Module D consisting of a purpose
+and a set of interactions (thus implicitly categorising Module D as SFR-noninterfering). The evaluator examines all of the evidence provided, including
+the purpose and interactions for Module D. The purpose appears to give a
+meaningful description of Module D's function in the TOE, the interactions
+are consistent with that description, and there is nothing to indicate that
+Module D is SFR-enforcing or SFR-supporting. In this case, the evaluator
+should not demand more information about Module D โjust be to sureโ it is
+correctly categorised. The developer has met the obligations and the resulting
+assurance the evaluator has in the implicit categorisation of Module D is (by
+definition) appropriate for this assurance level.
+
+
+ADV_TDS.4-14 The evaluator _**shall examine**_ the TOE design to determine that the
+description of the purpose of each SFR-non-interfering module is complete
+and accurate.
+
+
+930 The description of the purpose of a module indicates what function the
+module is fulfilling. From the description, the evaluator should be able to
+obtain a general idea of the module's role. In order to assure the description
+is complete, the evaluator uses the information provided about the module's
+interactions with other modules to assess whether the reasons for the module
+being called are consistent with the module's purpose. If the interaction
+description contains functionality that is not apparent from, or in conflict
+with, the module's purpose, the evaluator needs to determine whether the
+problem is one of accuracy or of completeness. The evaluator should be wary
+of purposes that are too short, since meaningful analysis based on a onesentence purpose is likely to be impossible.
+
+
+931 Because the modules are at such a low level, it may be difficult determine
+completeness and accuracy impacts from other documentation, such as
+operational user guidance, the functional specification, the security
+architecture description, or the TSF internals document. However, the
+evaluator uses the information present in those documents to the extent
+
+
+April 2017 Version 3.1 Page 201 of 430
+
+
+**Class ADV: Development**
+
+
+possible to help ensure that the function is accurately and completely
+described. This analysis can be aided by the analysis performed for the work
+units for the _**ADV_TDS.4.10C**_ element, which maps the TSFI in the
+functional specification to the modules of the TSF.
+
+
+ADV_TDS.4-15 The evaluator _**shall examine**_ the TOE design to determine that the
+description of a SFR-non-interfering module's interaction with other modules
+is complete and accurate.
+
+
+932 It is important to note that, in terms of the Part 3 requirement and this work
+unit, the term _interaction_ is intended to convey less rigour than _interface_ . An
+interaction does not need to be characterised at the implementation level (e.g.,
+parameters passed from one routine in a module to a routine in a different
+module; global variables; hardware signals (e.g., interrupts) from a hardware
+subsystem to an interrupt-handling subsystem), but the data elements
+identified for a particular module that are going to be used by another
+module should be covered in this discussion. Any control relationships
+between modules (e.g., a module responsible for configuring a rule base for a
+firewall system and the module that actually implements these rules) should
+also be described.
+
+
+933 A module's interaction with other modules can be captured in many ways.
+The intent for the TOE design is to allow the evaluator to understand (in part
+through analysis of module interactions) the role of the SFR-supporting and
+SFR-non-interfering modules in the overall TOE design. Understanding of
+this role will aid the evaluator in performing work unit ADV_TDS.4-8.
+
+
+934 A module's interaction with other modules goes beyond just a call-tree-type
+document. The interaction is described from a functional perspective of why
+a module interacts with other modules. The module's purpose describes what
+functions the module provides to other modules; the interactions should
+describe what the module depends on from other modules in order to
+accomplish this function.
+
+
+935 Because the modules are at such a low level, it may be difficult determine
+completeness and accuracy impacts from other documentation, such as
+operational user guidance, the functional specification, the security
+architecture description, or the TSF internals document. However, the
+evaluator uses the information present in those documents to the extent
+possible to help ensure that the interactions are accurately and completely
+described.
+
+
+ADV_TDS.4.10C _**The mapping shall demonstrate that all TSFIs trace to the behaviour**_
+_**described in the TOE design that they invoke.**_
+
+
+ADV_TDS.4-16 The evaluator _**shall examine**_ the TOE design to determine that it contains a
+complete and accurate mapping from the TSFI described in the functional
+specification to the modules of the TSF described in the TOE design.
+
+
+936 The modules described in the TOE design provide a description of the
+implementation of the TSF. The TSFI provide a description of how the
+
+
+Page 202 of 430 Version 3.1 April 2017
+
+
+**Class ADV: Development**
+
+
+implementation is exercised. The evidence from the developer identifies the
+module that is initially invoked when an operation is requested at the TSFI,
+and identify the chain of modules invoked up to the module that is primarily
+responsible for implementing the functionality. However, a complete call
+tree for each TSFI is not required for this work unit. The cases in which more
+than one module would have to be identified are where there are โentry
+pointโ modules or wrapper modules that have no functionality other than
+conditioning inputs or de-multiplexing an input. Mapping to one of these
+modules would not provide any useful information to the evaluator.
+
+
+937 The evaluator assesses the completeness of the mapping by ensuring that all
+of the TSFI map to at least one module. The verification of accuracy is more
+complex.
+
+
+938 The first aspect of accuracy is that each TSFI is mapped to a module at the
+TSF boundary. This determination can be made by reviewing the module
+description and its interfaces/interactions. The next aspect of accuracy is that
+each TSFI identifies a chain of modules between the initial module identified
+and a module that is primarily responsible for implementing the function
+presented at the TSF. Note that this may be the initial module, or there may
+be several modules, depending on how much pre-conditioning of the inputs
+is done. It should be noted that one indicator of a pre-conditioning module is
+that it is invoked for a large number of the TSFI, where the TSFI are all of
+similar type (e.g., system call). The final aspect of accuracy is that the
+mapping makes sense. For instance, mapping a TSFI dealing with access
+control to a module that checks passwords is not accurate. The evaluator
+should again use judgement in making this determination. The goal is that
+this information aids the evaluator in understanding the system and
+implementation of the SFRs, and ways in which entities at the TSF boundary
+can interact with the TSF. The bulk of the assessment of whether the SFRs
+are described accurately by the modules is performed in other work units.
+
+
+12.8.4.5 Action ADV_TDS.4.2E
+
+
+ADV_TDS.4-17 The evaluator _**shall examine**_ the TOE security functional requirements and
+the TOE design, to determine that all ST security functional requirements are
+covered by the TOE design.
+
+
+939 The evaluator may construct a map between the TOE security functional
+requirements and the TOE design. This map will likely be from a functional
+requirement to a set of subsystems, and later to modules. Note that this map
+may have to be at a level of detail below the component or even element
+level of the requirements, because of operations (assignments, refinements,
+selections) performed on the functional requirement by the ST author.
+
+
+940 For example, the FDP_ACC.1 Subset access control component contains an
+element with assignments. If the ST contained, for instance, ten rules in the
+FDP_ACC.1 Subset access control assignment, and these ten rules were
+implemented in specific places within fifteen modules, it would be
+inadequate for the evaluator to map FDP_ACC.1 Subset access control to
+one subsystem and claim the work unit had been completed. Instead, the
+
+
+April 2017 Version 3.1 Page 203 of 430
+
+
+**Class ADV: Development**
+
+
+evaluator would map FDP_ACC.1 Subset access control (rule 1) to modules
+x, y and z of subsystem A; FDP_ACC.1 Subset access control (rule 2) to x, p,
+and q of subsystem A; etc.
+
+
+ADV_TDS.4-18 The evaluator _**shall examine**_ the TOE design to determine that it is an
+accurate instantiation of all security functional requirements.
+
+
+941 The evaluator may construct a map between the TOE security functional
+requirements and the TOE design. This map will likely be from a functional
+requirement to a set of subsystems. Note that this map may have to be at a
+level of detail below the component or even element level of the
+requirements, because of operations (assignments, refinements, selections)
+performed on the functional requirement by the ST author.
+
+
+942 As an example, if the ST requirements specified a role-based access control
+mechanism, the evaluator would first identify the subsystems, and modules
+that contribute to this mechanism's implementation. This could be done by
+in-depth knowledge or understanding of the TOE design or by work done in
+the previous work unit. Note that this trace is only to identify the subsystems,
+and modules, and is not the complete analysis.
+
+
+943 The next step would be to understand what mechanism the subsystems, and
+modules implemented. For instance, if the design described an
+implementation of access control based on UNIX-style protection bits, the
+design would not be an accurate instantiation of those access control
+requirements present in the ST example used above. If the evaluator could
+not determine that the mechanism was accurately implemented because of a
+lack of detail, the evaluator would have to assess whether all of the SFRenforcing subsystems and modules have been identified, or if adequate detail
+had been provided for those subsystems and modules.
+
+
+**12.8.5** **Evaluation of sub-activity (ADV_TDS.5)**
+
+
+944 There is no general guidance; the scheme should be consulted for guidance
+on this sub-activity.
+
+
+**12.8.6** **Evaluation of sub-activity (ADV_TDS.6)**
+
+
+945 There is no general guidance; the scheme should be consulted for guidance
+on this sub-activity.
+
+
+Page 204 of 430 Version 3.1 April 2017
+
+
+**Class AGD: Guidance documents**
+
+# **13 Class AGD: Guidance documents**
+
+## **13.1 Introduction**
+
+
+946 The purpose of the guidance document activity is to judge the adequacy of
+the documentation describing how the user can handle the TOE in a secure
+manner. Such documentation should take into account the various types of
+users (e.g. those who accept, install, administrate or operate the TOE) whose
+incorrect actions could adversely affect the security of the TOE or of their
+own data.
+
+
+947 The guidance documents class is subdivided into two families which are
+concerned firstly with the preparative procedures (all that has to be done to
+transform the delivered TOE into its evaluated configuration in the
+environment as described in the ST, i.e. accepting and installing the TOE)
+and secondly with the operational user guidance (all that has to be done
+during the operation of the TOE in its evaluated configuration, i.e. operation
+and administration).
+
+## **13.2 Application notes**
+
+
+948 The guidance documents activity applies to those functions and interfaces
+which are related to the security of the TOE. The secure configuration of the
+TOE is described in the ST.
+
+
+April 2017 Version 3.1 Page 205 of 430
+
+
+**Class AGD: Guidance documents**
+
+## **13.3 Operational user guidance (AGD_OPE)**
+
+
+**13.3.1** **Evaluation of sub-activity (AGD_OPE.1)**
+
+
+13.3.1.1 Objectives
+
+
+949 The objectives of this sub-activity are to determine whether the user
+guidance describes for each user role the security functionality and interfaces
+provided by the TSF, provides instructions and guidelines for the secure use
+of the TOE, addresses secure procedures for all modes of operation,
+facilitates prevention and detection of insecure TOE states, or whether it is
+misleading or unreasonable.
+
+
+13.3.1.2 Input
+
+
+950 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the functional specification;
+
+
+c) the TOE design, if applicable;
+
+
+d) the user guidance;
+
+
+13.3.1.3 Action AGD_OPE.1.1E
+
+
+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-1 The evaluator _**shall examine**_ the operational user guidance to determine that
+it describes, for each user role, the user-accessible functions and privileges
+that should be controlled in a secure processing environment, including
+appropriate warnings.
+
+
+951 The configuration of the TOE may allow different user roles to have
+dissimilar privileges in making use of the different functions of the TOE.
+This means that some users are authorised to perform certain functions,
+while other users may not be so authorised. These functions and privileges
+should be described, for each user role, by the user guidance.
+
+
+952 The user guidance identifies, for each user role, the functions and privileges
+that must be controlled, the types of commands required for them, and the
+reasons for such commands. The user guidance should contain warnings
+regarding the use of these functions and privileges. Warnings should address
+expected effects, possible side effects, and possible interactions with other
+functions and privileges.
+
+
+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.**_
+
+
+Page 206 of 430 Version 3.1 April 2017
+
+
+**Class AGD: Guidance documents**
+
+
+AGD_OPE.1-2 The evaluator _**shall examine**_ the operational user guidance to determine that
+it describes, for each user role, the secure use of the available interfaces
+provided by the TOE.
+
+
+953 The user guidance should provide advice regarding effective use of the TSF
+(e.g. reviewing password composition practises, suggested frequency of user
+file backups, discussion on the effects of changing user access privileges).
+
+
+AGD_OPE.1.3C _**The operational user guidance shall describe, for each user role, the**_
+_**available functions and interfaces, in particular all security parameters**_
+_**under the control of the user, indicating secure values as appropriate.**_
+
+
+AGD_OPE.1-3 The evaluator _**shall examine**_ the operational user guidance to determine that
+it describes, for each user role, the available security functionality and
+interfaces, in particular all security parameters under the control of the user,
+indicating secure values as appropriate.
+
+
+954 The user guidance should contain an overview of the security functionality
+that is visible at the user interfaces.
+
+
+955 The user guidance should identify and describe the purpose, behaviour, and
+interrelationships of the security interfaces and functionality.
+
+
+956 For each user-accessible interface, the user guidance should:
+
+
+a) describe the method(s) by which the interface is invoked (e.g.
+command-line, programming-language system call, menu selection,
+command button);
+
+
+b) describe the parameters to be set by the user, their particular purposes,
+valid and default values, and secure and insecure use settings of such
+parameters, both individually or in combination;
+
+
+c) describe the immediate TSF response, message, or code returned.
+
+
+957 The evaluator should consider the functional specification and the ST to
+determine that the TSF described in these documents is consistent to the
+operational user guidance. The evaluator has to ensure that the operational
+user guidance is complete to allow the secure use through the TSFI available
+to all types of human users. The evaluator may, as an aid, prepare an
+informal mapping between the guidance and these documents. Any
+omissions in this mapping may indicate incompleteness.
+
+
+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-4 The evaluator _**shall examine**_ the operational user guidance to determine that
+it describes, for each user role, each type of security-relevant event relative
+to the user functions that need to be performed, including changing the
+
+
+April 2017 Version 3.1 Page 207 of 430
+
+
+**Class AGD: Guidance documents**
+
+
+security characteristics of entities under the control of the TSF and operation
+following failure or operational error.
+
+
+958 All types of security-relevant events are detailed for each user role, such that
+each user knows what events may occur and what action (if any) he may
+have to take in order to maintain security. Security-relevant events that may
+occur during operation of the TOE (e.g. audit trail overflow, system crash,
+updates to user records, such as when a user account is removed when the
+user leaves the organisation) are adequately defined to allow user
+intervention to maintain secure operation.
+
+
+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-5 The evaluator _**shall examine**_ the operational user guidance and other
+evaluation evidence to determine that the guidance identifies all possible
+modes of operation of the TOE (including, if applicable, operation following
+failure or operational error), their consequences and implications for
+maintaining secure operation.
+
+
+959 Other evaluation evidence, particularly the functional specification, provide
+an information source that the evaluator should use to determine that the
+guidance contains sufficient guidance information.
+
+
+960 If test documentation is included in the assurance package, then the
+information provided in this evidence can also be used to determine that the
+guidance contains sufficient guidance documentation. The detail provided in
+the test steps can be used to confirm that the guidance provided is sufficient
+for the use and administration of the TOE.
+
+
+961 The evaluator should focus on a single human visible TSFI at a time,
+comparing the guidance for securely using the TSFI with other evaluation
+evidence, to determine that the guidance related to the TSFI is sufficient for
+the secure usage (i.e. consistent with the SFRs) of that TSFI. The evaluator
+should also consider the relationships between interfaces, searching for
+potential conflicts.
+
+
+AGD_OPE.1.6C _**The operational user guidance shall, for each user role, describe the**_
+_**security measures to be followed in order to fulfil the security objectives for**_
+_**the operational environment as described in the ST.**_
+
+
+AGD_OPE.1-6 The evaluator _**shall examine**_ the operational user guidance to determine that
+it describes, for each user role, the security measures to be followed in order
+to fulfil the security objectives for the operational environment as described
+in the ST.
+
+
+962 The evaluator analyses the security objectives for the operational
+environment in the ST and determines that for each user role, the relevant
+security measures are described appropriately in the user guidance.
+
+
+Page 208 of 430 Version 3.1 April 2017
+
+
+**Class AGD: Guidance documents**
+
+
+963 The security measures described in the user guidance should include all
+relevant external procedural, physical, personnel and connectivity measures.
+
+
+964 Note that those measures relevant for secure installation of the TOE are
+examined in Preparative procedures (AGD_PRE).
+
+
+AGD_OPE.1.7C _**The operational user guidance shall be clear and reasonable.**_
+
+
+AGD_OPE.1-7 The evaluator _**shall examine**_ the operational user guidance to determine that
+it is clear.
+
+
+965 The guidance is unclear if it can reasonably be misconstrued by an
+administrator or user, and used in a way detrimental to the TOE, or to the
+security provided by the TOE.
+
+
+AGD_OPE.1-8 The evaluator _**shall examine**_ the operational user guidance to determine that
+it is reasonable.
+
+
+966 The guidance is unreasonable if it makes demands on the TOE's usage or
+operational environment that are inconsistent with the ST or unduly onerous
+to maintain security.
+
+
+April 2017 Version 3.1 Page 209 of 430
+
+
+**Class AGD: Guidance documents**
+
+## **13.4 Preparative procedures (AGD_PRE)**
+
+
+**13.4.1** **Evaluation of sub-activity (AGD_PRE.1)**
+
+
+13.4.1.1 Objectives
+
+
+967 The objective of this sub-activity is to determine whether the procedures and
+steps for the secure preparation of the TOE have been documented and result
+in a secure configuration.
+
+
+13.4.1.2 Input
+
+
+968 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the TOE including its preparative procedures;
+
+
+c) the description of developer's delivery procedures, if applicable;
+
+
+13.4.1.3 Application notes
+
+
+969 The preparative procedures refer to all acceptance and installation procedures,
+that are necessary to progress the TOE to the secure configuration as
+described in the ST.
+
+
+13.4.1.4 Action AGD_PRE.1.1E
+
+
+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-1 The evaluator _**shall examine**_ the provided acceptance procedures to
+determine that they describe the steps necessary for secure acceptance of the
+TOE in accordance with the developer's delivery procedures.
+
+
+970 If it is not anticipated by the developer's delivery procedures that acceptance
+procedures will or can be applied, this work unit is not applicable, and is
+therefore considered to be satisfied.
+
+
+971 The acceptance procedures should include as a minimum, that the user has to
+check that all parts of the TOE as indicated in the ST have been delivered in
+the correct version.
+
+
+972 The acceptance procedures should reflect the steps the user has to perform in
+order to accept the delivered TOE that are implied by the developer's
+delivery procedures.
+
+
+973 The acceptance procedures should provide detailed information about the
+following, if applicable:
+
+
+Page 210 of 430 Version 3.1 April 2017
+
+
+**Class AGD: Guidance documents**
+
+
+a) making sure that the delivered TOE is the complete evaluated
+instance;
+
+
+b) detecting modification/masquerading of the delivered TOE.
+
+
+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.**_
+
+
+AGD_PRE.1-2 The evaluator _**shall examine**_ the provided installation procedures to
+determine that they describe the steps necessary for secure installation of the
+TOE and the secure preparation of the operational environment in
+accordance with the security objectives in the ST.
+
+
+974 If it is not anticipated that installation procedures will or can be applied (e.g.
+because the TOE may already be delivered in an operational state), this work
+unit is not applicable, and is therefore considered to be satisfied.
+
+
+975 The installation procedures should provide detailed information about the
+following, if applicable:
+
+
+a) minimum system requirements for secure installation;
+
+
+b) requirements for the operational environment in accordance with the
+security objectives provided by the ST;
+
+
+c) the steps the user has to perform in order to get to an operational TOE
+being commensurate with its evaluated configuration. Such a
+description shall include - for each step - a clear scheme for the
+decision on the next step depended on success, failure or problems at
+the current step;
+
+
+d) changing the installation specific security characteristics of entities
+under the control of the TSF (for example parameters, settings,
+passwords);
+
+
+e) handling exceptions and problems.
+
+
+13.4.1.5 Action AGD_PRE.1.2E
+
+
+AGD_PRE.1-3 The evaluator _**shall perform**_ all user procedures necessary to prepare the
+TOE to determine that the TOE and its operational environment can be
+prepared securely using only the supplied preparative procedures.
+
+
+976 Preparation requires the evaluator to advance the TOE from a deliverable
+state to the state in which it is operational, including acceptance and
+installation of the TOE, and enforcing the SFRs consistent with the security
+objectives for the TOE specified in the ST.
+
+
+977 The evaluator should follow only the developer's procedures and may
+perform the activities that customers are usually expected to perform to
+
+
+April 2017 Version 3.1 Page 211 of 430
+
+
+**Class AGD: Guidance documents**
+
+
+accept and install the TOE, using the supplied preparative procedures only.
+Any difficulties encountered during such an exercise may be indicative of
+incomplete, unclear or unreasonable guidance.
+
+
+978 This work unit may be performed in conjunction with the evaluation
+activities under Independent testing (ATE_IND).
+
+
+979 If it is known that the TOE will be used as a dependent component for a
+composed TOE evaluation, then the evaluator should ensure that the
+operational environment is satisfied by the base component used in the
+composed TOE.
+
+
+Page 212 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+# **14 Class ALC: Life-cycle support**
+
+## **14.1 Introduction**
+
+
+980 The purpose of the life-cycle support activity is to determine the adequacy of
+the security procedures that the developer uses during the development and
+maintenance of the TOE. These procedures include the life-cycle model used
+by the developer, the configuration management, the security measures used
+throughout TOE development, the tools used by the developer throughout
+the life-cycle of the TOE, the handling of security flaws, and the delivery
+activity.
+
+
+981 Poorly controlled development and maintenance of the TOE can result in
+vulnerabilities in the implementation. Conformance to a defined life-cycle
+model can help to improve controls in this area. A measurable life-cycle
+model used for the TOE can remove ambiguity in assessing the development
+progress of the TOE.
+
+
+982 The purpose of the configuration management activity is to assist the
+consumer in identifying the evaluated TOE, to ensure that configuration
+items are uniquely identified, and the adequacy of the procedures that are
+used by the developer to control and track changes that are made to the TOE.
+This includes details on what changes are tracked, how potential changes are
+incorporated, and the degree to which automation is used to reduce the scope
+for error.
+
+
+983 Developer security procedures are intended to protect the TOE and its
+associated design information from interference or disclosure. Interference in
+the development process may allow the deliberate introduction of
+vulnerabilities. Disclosure of design information may allow vulnerabilities to
+be more easily exploited. The adequacy of the procedures will depend on the
+nature of the TOE and the development process.
+
+
+984 The use of well-defined development tools and the application of
+implementation standards by the developer and by third parties involved in
+the development process help to ensure that vulnerabilities are not
+inadvertently introduced during refinement.
+
+
+985 The flaw remediation activity is intended to track security flaws, to identify
+corrective actions, and to distribute the corrective action information to TOE
+users.
+
+
+986 The purpose of the delivery activity is to judge the adequacy of the
+documentation of the procedures used to ensure that the TOE is delivered to
+the consumer without modification.
+
+
+April 2017 Version 3.1 Page 213 of 430
+
+
+**Class ALC: Life-cycle support**
+
+## **14.2 CM capabilities (ALC_CMC)**
+
+
+**14.2.1** **Evaluation of sub-activity (ALC_CMC.1)**
+
+
+14.2.1.1 Objectives
+
+
+987 The objectives of this sub-activity are to determine whether the developer
+has clearly identified the TOE.
+
+
+14.2.1.2 Input
+
+
+988 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the TOE suitable for testing.
+
+
+14.2.1.3 Action ALC_CMC.1.1E
+
+
+ALC_CMC.1.1C _**The TOE shall be labelled with its unique reference.**_
+
+
+ALC_CMC.1-1 The evaluator _**shall check**_ that the TOE provided for evaluation is labelled
+with its reference.
+
+
+989 The evaluator should ensure that the TOE contains the unique reference
+which is stated in the ST. This could be achieved through labelled packaging
+or media, or by a label displayed by the operational TOE. This is to ensure
+that it would be possible for consumers to identify the TOE (e.g. at the point
+of purchase or use).
+
+
+990 The TOE may provide a method by which it can be easily identified. For
+example, a software TOE may display its name and version number during
+the start up routine, or in response to a command line entry. A hardware or
+firmware TOE may be identified by a part number physically stamped on the
+TOE.
+
+
+991 Alternatively, the unique reference provided for the TOE may be the
+combination of the unique reference of each component from which the TOE
+is comprised (e.g. in the case of a composed TOE).
+
+
+ALC_CMC.1-2 The evaluator _**shall check**_ that the TOE references used are consistent.
+
+
+992 If the TOE is labelled more than once then the labels have to be consistent.
+For example, it should be possible to relate any labelled guidance
+documentation supplied as part of the TOE to the evaluated operational TOE.
+This ensures that consumers can be confident that they have purchased the
+evaluated version of the TOE, that they have installed this version, and that
+they have the correct version of the guidance to operate the TOE in
+accordance with its ST.
+
+
+993 The evaluator also verifies that the TOE reference is consistent with the ST.
+
+
+Page 214 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+994 If this work unit is applied to a composed TOE, the following will apply. The
+composed IT TOE will not be labelled with its unique (composite) reference,
+but only the individual components will be labelled with their appropriate
+TOE reference. It would require further development for the IT TOE to be
+labelled, i.e. during start-up and/or operation, with the composite reference.
+If the composed TOE is delivered as the constituent component TOEs, then
+the TOE items delivered will not contain the composite reference. However,
+the composed TOE ST will include the unique reference for the composed
+TOE and will identify the components comprising the composed TOE
+through which the consumers will be able to determine whether they have
+the appropriate items.
+
+
+**14.2.2** **Evaluation of sub-activity (ALC_CMC.2)**
+
+
+14.2.2.1 Objectives
+
+
+995 The objectives of this sub-activity are to determine whether the developer
+uses a CM system that uniquely identifies all configuration items.
+
+
+14.2.2.2 Input
+
+
+996 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the TOE suitable for testing;
+
+
+c) the configuration management documentation.
+
+
+14.2.2.3 Application notes
+
+
+997 This component contains an implicit evaluator action to determine that the
+CM system is being used. As the requirements here are limited to
+identification of the TOE and provision of a configuration list, this action is
+already covered by, and limited to, the existing work units. At Evaluation of
+sub-activity (ALC_CMC.3) the requirements are expanded beyond these two
+items, and more explicit evidence of operation is required.
+
+
+14.2.2.4 Action ALC_CMC.2.1E
+
+
+ALC_CMC.2.1C _**The TOE shall be labelled with its unique reference.**_
+
+
+ALC_CMC.2-1 The evaluator _**shall check**_ that the TOE provided for evaluation is labelled
+with its reference.
+
+
+998 The evaluator should ensure that the TOE contains the unique reference
+which is stated in the ST. This could be achieved through labelled packaging
+or media, or by a label displayed by the operational TOE. This is to ensure
+that it would be possible for consumers to identify the TOE (e.g. at the point
+of purchase or use).
+
+
+April 2017 Version 3.1 Page 215 of 430
+
+
+**Class ALC: Life-cycle support**
+
+
+999 The TOE may provide a method by which it can be easily identified. For
+example, a software TOE may display its name and version number during
+the start up routine, or in response to a command line entry. A hardware or
+firmware TOE may be identified by a part number physically stamped on the
+TOE.
+
+
+1000 Alternatively, the unique reference provided for the TOE may be the
+combination of the unique reference of each component from which the TOE
+is comprised (e.g. in the case of a composed TOE).
+
+
+ALC_CMC.2-2 The evaluator _**shall check**_ that the TOE references used are consistent.
+
+
+1001 If the TOE is labelled more than once then the labels have to be consistent.
+For example, it should be possible to relate any labelled guidance
+documentation supplied as part of the TOE to the evaluated operational TOE.
+This ensures that consumers can be confident that they have purchased the
+evaluated version of the TOE, that they have installed this version, and that
+they have the correct version of the guidance to operate the TOE in
+accordance with its ST.
+
+
+1002 The evaluator also verifies that the TOE reference is consistent with the ST.
+
+
+1003 If this work unit is applied to a composed TOE, the following will apply. The
+composed IT TOE will not be labelled with its unique (composite) reference,
+but only the individual components will be labelled with their appropriate
+TOE reference. It would require further development for the IT TOE to be
+labelled, i.e. during start-up and/or operation, with the composite reference.
+If the composed TOE is delivered as the constituent component TOEs, then
+the TOE items delivered will not contain the composite reference. However,
+the composed TOE ST will include the unique reference for the composed
+TOE and will identify the components comprising the composed TOE
+through which the consumers will be able to determine whether they have
+the appropriate items.
+
+
+ALC_CMC.2.2C _**The CM documentation shall describe the method used to uniquely identify**_
+_**the configuration items.**_
+
+
+ALC_CMC.2-3 The evaluator _**shall examine**_ the method of identifying configuration items
+to determine that it describes how configuration items are uniquely identified.
+
+
+1004 Procedures should describe how the status of each configuration item can be
+tracked throughout the life-cycle of the TOE. The procedures may be
+detailed in the CM plan or throughout the CM documentation. The
+information included should describe:
+
+
+a) the method how each configuration item is uniquely identified, such
+that it is possible to track versions of the same configuration item;
+
+
+b) the method how configuration items are assigned unique identifiers
+and how they are entered into the CM system;
+
+
+Page 216 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+c) the method to be used to identify superseded versions of a
+configuration item.
+
+
+ALC_CMC.2.3C _**The CM system shall uniquely identify all configuration items.**_
+
+
+ALC_CMC.2-4 The evaluator _**shall examine**_ the configuration items to determine that they
+are identified in a way that is consistent with the CM documentation.
+
+
+1005 Assurance that the CM system uniquely identifies all configuration items is
+gained by examining the identifiers for the configuration items. For both
+configuration items that comprise the TOE, and drafts of configuration items
+that are submitted by the developer as evaluation evidence, the evaluator
+confirms that each configuration item possesses a unique identifier in a
+manner consistent with the unique identification method that is described in
+the CM documentation.
+
+
+**14.2.3** **Evaluation of sub-activity (ALC_CMC.3)**
+
+
+14.2.3.1 Objectives
+
+
+1006 The objectives of this sub-activity are to determine whether the developer
+uses a CM system that uniquely identifies all configuration items, and
+whether the ability to modify these items is properly controlled.
+
+
+14.2.3.2 Input
+
+
+1007 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the TOE suitable for testing;
+
+
+c) the configuration management documentation.
+
+
+14.2.3.3 Action ALC_CMC.3.1E
+
+
+ALC_CMC.3.1C _**The TOE shall be labelled with its unique reference.**_
+
+
+ALC_CMC.3-1 The evaluator _**shall check**_ that the TOE provided for evaluation is labelled
+with its reference.
+
+
+1008 The evaluator should ensure that the TOE contains the unique reference
+which is stated in the ST. This could be achieved through labelled packaging
+or media, or by a label displayed by the operational TOE. This is to ensure
+that it would be possible for consumers to identify the TOE (e.g. at the point
+of purchase or use).
+
+
+1009 The TOE may provide a method by which it can be easily identified. For
+example, a software TOE may display its name and version number during
+the start up routine, or in response to a command line entry. A hardware or
+firmware TOE may be identified by a part number physically stamped on the
+TOE.
+
+
+April 2017 Version 3.1 Page 217 of 430
+
+
+**Class ALC: Life-cycle support**
+
+
+1010 Alternatively, the unique reference provided for the TOE may be the
+combination of the unique reference of each component from which the TOE
+is comprised (e.g. in the case of a composed TOE).
+
+
+ALC_CMC.3-2 The evaluator _**shall check**_ that the TOE references used are consistent.
+
+
+1011 If the TOE is labelled more than once then the labels have to be consistent.
+For example, it should be possible to relate any labelled guidance
+documentation supplied as part of the TOE to the evaluated operational TOE.
+This ensures that consumers can be confident that they have purchased the
+evaluated version of the TOE, that they have installed this version, and that
+they have the correct version of the guidance to operate the TOE in
+accordance with its ST.
+
+
+1012 The evaluator also verifies that the TOE reference is consistent with the ST.
+
+
+1013 If this work unit is applied to a composed TOE, the following will apply. The
+composed IT TOE will not be labelled with its unique (composite) reference,
+but only the individual components will be labelled with their appropriate
+TOE reference. It would require further development for the IT TOE to be
+labelled, i.e. during start-up and/or operation, with the composite reference.
+If the composed TOE is delivered as the constituent component TOEs, then
+the TOE items delivered will not contain the composite reference. However,
+the composed TOE ST will include the unique reference for the composed
+TOE and will identify the components comprising the composed TOE
+through which the consumers will be able to determine whether they have
+the appropriate items.
+
+
+ALC_CMC.3.2C _**The CM documentation shall describe the method used to uniquely identify**_
+_**the configuration items.**_
+
+
+ALC_CMC.3-3 The evaluator _**shall examine**_ the method of identifying configuration items
+to determine that it describes how configuration items are uniquely identified.
+
+
+1014 Procedures should describe how the status of each configuration item can be
+tracked throughout the life-cycle of the TOE. The procedures may be
+detailed in the CM plan or throughout the CM documentation. The
+information included should describe:
+
+
+a) the method how each configuration item is uniquely identified, such
+that it is possible to track versions of the same configuration item;
+
+
+b) the method how configuration items are assigned unique identifiers
+and how they are entered into the CM system;
+
+
+c) the method to be used to identify superseded versions of a
+configuration item.
+
+
+ALC_CMC.3.3C _**The CM system shall uniquely identify all configuration items.**_
+
+
+ALC_CMC.3-4 The evaluator _**shall examine**_ the configuration items to determine that they
+are identified in a way that is consistent with the CM documentation.
+
+
+Page 218 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+1015 Assurance that the CM system uniquely identifies all configuration items is
+gained by examining the identifiers for the configuration items. For both
+configuration items that comprise the TOE, and drafts of configuration items
+that are submitted by the developer as evaluation evidence, the evaluator
+confirms that each configuration item possesses a unique identifier in a
+manner consistent with the unique identification method that is described in
+the CM documentation.
+
+
+ALC_CMC.3.4C _**The CM system shall provide measures such that only authorised changes**_
+_**are made to the configuration items.**_
+
+
+ALC_CMC.3-5 The evaluator _**shall examine**_ the CM access control measures described in
+the CM plan to determine that they are effective in preventing unauthorised
+access to the configuration items.
+
+
+1016 The evaluator may use a number of methods to determine that the CM access
+control measures are effective. For example, the evaluator may exercise the
+access control measures to ensure that the procedures could not be bypassed.
+The evaluator may use the outputs generated by the CM system procedures
+required by _**ALC_CMC.3.8C**_ . The evaluator may also witness a
+demonstration of the CM system to ensure that the access control measures
+employed are operating effectively.
+
+
+ALC_CMC.3.5C _**The CM documentation shall include a CM plan.**_
+
+
+ALC_CMC.3-6 The evaluator _**shall check**_ that the CM documentation provided includes a
+CM plan.
+
+
+1017 The CM plan needs not to be a connected document, but it is recommended
+that there is a single document that describes where the various parts of the
+CM plan can be found. If the CM plan is no single document, the list in the
+following work unit gives hints regarding which context is expected.
+
+
+ALC_CMC.3.6C _**The CM plan shall describe how the CM system is used for the**_
+_**development of the TOE.**_
+
+
+ALC_CMC.3-7 The evaluator _**shall examine**_ the CM plan to determine that it describes how
+the CM system is used for the development of the TOE.
+
+
+1018 The descriptions contained in a CM plan include, if applicable:
+
+
+a) all activities performed in the TOE development that are subject to
+configuration management procedures (e.g. creation, modification or
+deletion of a configuration item, data-backup, archiving);
+
+
+b) which means (e.g. CM tools, forms) have to be made available;
+
+
+c) the usage of the CM tools: the necessary details for a user of the CM
+system to be able to operate the CM tools correctly in order to
+maintain the integrity of the TOE;
+
+
+April 2017 Version 3.1 Page 219 of 430
+
+
+**Class ALC: Life-cycle support**
+
+
+d) which other objects (development components, tools, assessment
+environments, etc) are taken under CM control;
+
+
+e) the roles and responsibilities of individuals required to perform
+operations on individual configuration items (different roles may be
+identified for different types of configuration items (e.g. design
+documentation or source code));
+
+
+f) how CM instances (e.g. change control boards, interface control
+working groups) are introduced and staffed;
+
+
+g) the description of the change management;
+
+
+h) the procedures that are used to ensure that only authorised individuals
+can make changes to configuration items;
+
+
+i) the procedures that are used to ensure that concurrency problems do
+not occur as a result of simultaneous changes to configuration items;
+
+
+j) the evidence that is generated as a result of application of the
+procedures. For example, for a change to a configuration item, the
+CM system might record a description of the change, accountability
+for the change, identification of all configuration items affected,
+status (e.g. pending or completed), and date and time of the change.
+This might be recorded in an audit trail of changes made or change
+control records;
+
+
+k) the approach to version control and unique referencing of TOE
+versions (e.g. covering the release of patches in operating systems,
+and the subsequent detection of their application).
+
+
+ALC_CMC.3.7C _**The evidence shall demonstrate that all configuration items are being**_
+_**maintained under the CM system.**_
+
+
+ALC_CMC.3-8 The evaluator _**shall check**_ that the configuration items identified in the
+configuration list are being maintained by the CM system.
+
+
+1019 The CM system employed by the developer should maintain the integrity of
+the TOE. The evaluator should check that for each type of configuration item
+(e.g. design documents or source code modules) contained in the
+configuration list there are examples of the evidence generated by the
+procedures described in the CM plan. In this case, the approach to sampling
+will depend upon the level of granularity used in the CM system to control
+CM items. Where, for example, 10,000 source code modules are identified in
+the configuration list, a different sampling strategy needs to be applied
+compared to the case in which there are only 5, or even 1. The emphasis of
+this activity should be on ensuring that the CM system is being operated
+correctly, rather than on the detection of any minor error.
+
+
+1020 For guidance on sampling see A.2, Sampling.
+
+
+Page 220 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+ALC_CMC.3.8C _**The evidence shall demonstrate that the CM system is being operated in**_
+_**accordance with the CM plan.**_
+
+
+ALC_CMC.3-9 The evaluator _**shall check**_ the CM documentation to ascertain that it includes
+the CM system records identified by the CM plan.
+
+
+1021 The output produced by the CM system should provide the evidence that the
+evaluator needs to be confident that the CM plan is being applied, and also
+that all configuration items are being maintained by the CM system as
+required by _**ALC_CMC.3.7C**_ . Example output could include change control
+forms, or configuration item access approval forms.
+
+
+ALC_CMC.3-10 The evaluator _**shall examine**_ the evidence to determine that the CM system
+is being operated in accordance with the CM plan.
+
+
+1022 The evaluator should select and examine a sample of evidence covering each
+type of CM-relevant operation that has been performed on a configuration
+item (e.g. creation, modification, deletion, reversion to an earlier version) to
+confirm that all operations of the CM system have been carried out in line
+with documented procedures. The evaluator confirms that the evidence
+includes all the information identified for that operation in the CM plan.
+Examination of the evidence may require access to a CM tool that is used.
+The evaluator may choose to sample the evidence.
+
+
+1023 For guidance on sampling see A.2, Sampling.
+
+
+1024 Further confidence in the correct operation of the CM system and the
+effective maintenance of configuration items may be established by means of
+interviews with selected development staff. In conducting such interviews,
+the evaluator aims to gain a deeper understanding of how the CM system is
+used in practise as well as to confirm that the CM procedures are being
+applied as described in the CM documentation. Note that such interviews
+should complement rather than replace the examination of documentary
+evidence, and may not be necessary if the documentary evidence alone
+satisfies the requirement. However, given the wide scope of the CM plan it is
+possible that some aspects (e.g. roles and responsibilities) may not be clear
+from the CM plan and records alone. This is one case where clarification
+may be necessary through interviews.
+
+
+1025 It is expected that the evaluator will visit the development site in support of
+this activity.
+
+
+1026 For guidance on site visits see A.4, Site Visits.
+
+
+**14.2.4** **Evaluation of sub-activity (ALC_CMC.4)**
+
+
+14.2.4.1 Objectives
+
+
+1027 The objectives of this sub-activity are to determine whether the developer
+has clearly identified the TOE and its associated configuration items, and
+whether the ability to modify these items is properly controlled by automated
+
+
+April 2017 Version 3.1 Page 221 of 430
+
+
+**Class ALC: Life-cycle support**
+
+
+tools, thus making the CM system less susceptible to human error or
+negligence.
+
+
+14.2.4.2 Input
+
+
+1028 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the TOE suitable for testing;
+
+
+c) the configuration management documentation.
+
+
+14.2.4.3 Action ALC_CMC.4.1E
+
+
+ALC_CMC.4.1C _**The TOE shall be labelled with its unique reference.**_
+
+
+ALC_CMC.4-1 The evaluator _**shall check**_ that the TOE provided for evaluation is labelled
+with its reference.
+
+
+1029 The evaluator should ensure that the TOE contains the unique reference
+which is stated in the ST. This could be achieved through labelled packaging
+or media, or by a label displayed by the operational TOE. This is to ensure
+that it would be possible for consumers to identify the TOE (e.g. at the point
+of purchase or use).
+
+
+1030 The TOE may provide a method by which it can be easily identified. For
+example, a software TOE may display its name and version number during
+the start up routine, or in response to a command line entry. A hardware or
+firmware TOE may be identified by a part number physically stamped on the
+TOE.
+
+
+1031 Alternatively, the unique reference provided for the TOE may be the
+combination of the unique reference of each component from which the TOE
+is comprised (e.g. in the case of a composed TOE).
+
+
+ALC_CMC.4-2 The evaluator _**shall check**_ that the TOE references used are consistent.
+
+
+1032 If the TOE is labelled more than once then the labels have to be consistent.
+For example, it should be possible to relate any labelled guidance
+documentation supplied as part of the TOE to the evaluated operational TOE.
+This ensures that consumers can be confident that they have purchased the
+evaluated version of the TOE, that they have installed this version, and that
+they have the correct version of the guidance to operate the TOE in
+accordance with its ST.
+
+
+1033 The evaluator also verifies that the TOE reference is consistent with the ST.
+
+
+1034 If this work unit is applied to a composed TOE, the following will apply. The
+composed TOE will not be labelled with its unique (composite) reference,
+but only the individual components will be labelled with their appropriate
+TOE reference. It would require further development for the composed TOE
+
+
+Page 222 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+to be labelled, i.e. during start-up and/or operation, with the composite
+reference. If the composed TOE is delivered as the constituent component
+TOEs, then the TOE items delivered will not contain the composite reference.
+However, the composed TOE ST will include the unique reference for the
+composed TOE and will identify the components comprising the composed
+TOE through which the consumers will be able to determine whether they
+have the appropriate items.
+
+
+ALC_CMC.4.2C _**The CM documentation shall describe the method used to uniquely identify**_
+_**the configuration items.**_
+
+
+ALC_CMC.4-3 The evaluator _**shall examine**_ the method of identifying configuration items
+to determine that it describes how configuration items are uniquely identified.
+
+
+1035 Procedures should describe how the status of each configuration item can be
+tracked throughout the life-cycle of the TOE. The procedures may be
+detailed in the CM plan or throughout the CM documentation. The
+information included should describe:
+
+
+a) the method how each configuration item is uniquely identified, such
+that it is possible to track versions of the same configuration item;
+
+
+b) the method how configuration items are assigned unique identifiers
+and how they are entered into the CM system;
+
+
+c) the method to be used to identify superseded versions of a
+configuration item.
+
+
+ALC_CMC.4.3C _**The CM system shall uniquely identify all configuration items.**_
+
+
+ALC_CMC.4-4 The evaluator _**shall examine**_ the configuration items to determine that they
+are identified in a way that is consistent with the CM documentation.
+
+
+1036 Assurance that the CM system uniquely identifies all configuration items is
+gained by examining the identifiers for the configuration items. For
+configuration items identified under ALC_CMS, the evaluator confirms that
+each configuration item possesses a unique identifier in a manner consistent
+with the unique identification method that is described in the CM
+documentation.
+
+
+ALC_CMC.4.4C _**The CM system shall provide automated measures such that only**_
+_**authorised changes are made to the configuration items.**_
+
+
+ALC_CMC.4-5 The evaluator _**shall examine**_ the CM access control measures described in
+the CM plan (cf. _**ALC_CMC.4.6C**_ ) to determine that they are automated and
+effective in preventing unauthorised access to the configuration items.
+
+
+1037 The evaluator may use a number of methods to determine that the CM access
+control measures are effective. For example, the evaluator may exercise the
+access control measures to ensure that the procedures could not be bypassed.
+The evaluator may use the outputs generated by the CM system procedures
+required by _**ALC_CMC.4.10C**_ . The evaluator may also witness a
+
+
+April 2017 Version 3.1 Page 223 of 430
+
+
+**Class ALC: Life-cycle support**
+
+
+demonstration of the CM system to ensure that the access control measures
+employed are operating effectively.
+
+
+ALC_CMC.4.5C _**The CM system shall support the production of the TOE by automated**_
+_**means.**_
+
+
+ALC_CMC.4-6 The evaluator _**shall check**_ the CM plan (cf. _**ALC_CMC.4.6C**_ ) for automated
+procedures for supporting the production of the TOE.
+
+
+1038 The term โproductionโ applies to those processes adopted by the developer to
+progress the TOE from the implementation representation to a state
+acceptable for delivery to the end customer.
+
+
+1039 The evaluator verifies the existence of automated production support
+procedures within the CM plan.
+
+
+1040 The following are examples for automated means supporting the production
+of the TOE:
+
+
+๏ญ a โmakeโ tool (as provided with many software development tools) in
+the case of a software TOE;
+
+
+๏ญ a tool ensuring automatically (for example by means of bar codes)
+that only parts are combined which indeed belong together in the case
+of a hardware TOE.
+
+
+ALC_CMC.4-7 The evaluator _**shall examine**_ the TOE production support procedures to
+determine that they are effective in ensuring that a TOE is generated that
+reflects its implementation representation.
+
+
+1041 The production support procedures should describe which tools have to be
+used to produce the final TOE from the implementation representation in a
+clearly defined way. The conventions, directives, or other necessary
+constructs are described under ALC_TAT.
+
+
+1042 The evaluator determines that by following the production support
+procedures the correct configuration items would be used to generate the
+TOE. For example, in a software TOE this may include checking that the
+automated production procedures ensure that all source files and related
+libraries are included in the compiled object code. Moreover, the procedures
+should ensure that compiler options and comparable other options are
+defined uniquely. For a hardware TOE, this work unit may include checking
+that the automatic production procedures ensure that the belonging parts are
+built together and no parts are missing.
+
+
+1043 The customer can then be confident that the version of the TOE delivered for
+installation is derived from the implementation representation in an
+unambiguous way and implements the SFRs as described in the ST.
+
+
+1044 The evaluator should bear in mind that the CM system need not necessarily
+possess the capability to produce the TOE, but should provide support for the
+process that will help reduce the probability of human error.
+
+
+Page 224 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+ALC_CMC.4.6C _**The CM documentation shall include a CM plan.**_
+
+
+ALC_CMC.4-8 The evaluator _**shall check**_ that the CM documentation provided includes a
+CM plan.
+
+
+1045 The CM plan does not need to be contained within a single document, but it
+is recommended that there is a separate document that describes where the
+various parts of the CM plan can be found. If the CM plan is provided by a
+set of documents, the list in the following work unit gives guidance
+regarding the required content.
+
+
+ALC_CMC.4.7C _**The CM plan shall describe how the CM system is used for the**_
+_**development of the TOE.**_
+
+
+ALC_CMC.4-9 The evaluator _**shall examine**_ the CM plan to determine that it describes how
+the CM system is used for the development of the TOE.
+
+
+1046 The descriptions contained in a CM plan include, if applicable:
+
+
+a) all activities performed in the TOE development that are subject to
+configuration management procedures (e.g. creation, modification or
+deletion of a configuration item, data-backup, archiving);
+
+
+b) which means (e.g. CM tools, forms) have to be made available;
+
+
+c) the usage of the CM tools: the necessary details for a user of the CM
+system to be able to operate the CM tools correctly in order to
+maintain the integrity of the TOE;
+
+
+d) the production support procedures;
+
+
+e) which other objects (development components, tools, assessment
+environments, etc) are taken under CM control;
+
+
+f) the roles and responsibilities of individuals required to perform
+operations on individual configuration items (different roles may be
+identified for different types of configuration items (e.g. design
+documentation or source code));
+
+
+g) how CM instances (e.g. change control boards, interface control
+working groups) are introduced and staffed;
+
+
+h) the description of the change management;
+
+
+i) the procedures that are used to ensure that only authorised individuals
+can make changes to configuration items;
+
+
+j) the procedures that are used to ensure that concurrency problems do
+not occur as a result of simultaneous changes to configuration items;
+
+
+k) the evidence that is generated as a result of application of the
+procedures. For example, for a change to a configuration item, the
+
+
+April 2017 Version 3.1 Page 225 of 430
+
+
+**Class ALC: Life-cycle support**
+
+
+CM system might record a description of the change, accountability
+for the change, identification of all configuration items affected,
+status (e.g. pending or completed), and date and time of the change.
+This might be recorded in an audit trail of changes made or change
+control records;
+
+
+l) the approach to version control and unique referencing of TOE
+versions (e.g. covering the release of patches in operating systems,
+and the subsequent detection of their application).
+
+
+ALC_CMC.4.8C _**The CM plan shall describe the procedures used to accept modified or**_
+_**newly created configuration items as part of the TOE.**_
+
+
+ALC_CMC.4-10 The evaluator _**shall examine**_ the CM plan to determine that it describes the
+procedures used to accept modified or newly created configuration items as
+parts of the TOE.
+
+
+1047 The descriptions of the acceptance procedures in the CM plan should include
+the developer roles or individuals responsible for the acceptance and the
+criteria to be used for acceptance. They should take into account all
+acceptance situations that may occur, in particular:
+
+
+a) accepting an item into the CM system for the first time, in particular
+inclusion of software, firmware and hardware components from other
+manufacturers into the TOE (โintegrationโ);
+
+
+b) moving configuration items to the next life-cycle phase at each stage
+of the construction of the TOE (e.g. module, subsystem, system);
+
+
+c) subsequent to transports between different development sites.
+
+
+1048 If this work unit is applied to a dependent component that is going to be
+integrated in a composed TOE, the CM plan should consider the control of
+base components obtained by the dependent TOE developer.
+
+
+1049 When obtaining the components the evaluators are to verify the following:
+
+
+a) Transfer of each base component from the base component developer
+to the integrator (dependent TOE developer) was performed in
+accordance with the base component TOE's secure delivery
+procedures, as reported in the base component TOE certification
+report.
+
+
+b) The component received has the same identifiers as those stated in
+the ST and Certification Report for the component TOE.
+
+
+c) All additional material required by a developer for composition
+(integration) is provided. This is to include the necessary extract of
+the component TOE's functional specification.
+
+
+ALC_CMC.4.9C _**The evidence shall demonstrate that all configuration items are being**_
+_**maintained under the CM system.**_
+
+
+Page 226 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+ALC_CMC.4-11 The evaluator _**shall check**_ that the configuration items identified in the
+configuration list are being maintained by the CM system.
+
+
+1050 The CM system employed by the developer should maintain the integrity of
+the TOE. The evaluator should check that for each type of configuration item
+(e.g. design documents or source code modules) contained in the
+configuration list there are examples of the evidence generated by the
+procedures described in the CM plan. In this case, the approach to sampling
+will depend upon the level of granularity used in the CM system to control
+CM items. Where, for example, 10,000 source code modules are identified in
+the configuration list, a different sampling strategy needs to be applied
+compared to the case in which there are only 5, or even 1. The emphasis of
+this activity should be on ensuring that the CM system is being operated
+correctly, rather than on the detection of any minor error.
+
+
+1051 For guidance on sampling see A.2, Sampling.
+
+
+ALC_CMC.4.10C _**The evidence shall demonstrate that the CM system is being operated in**_
+_**accordance with the CM plan.**_
+
+
+ALC_CMC.4-12 The evaluator _**shall check**_ the CM documentation to ascertain that it includes
+the CM system records identified by the CM plan.
+
+
+1052 The output produced by the CM system should provide the evidence that the
+evaluator needs to be confident that the CM plan is being applied, and also
+that all configuration items are being maintained by the CM system as
+required by _**ALC_CMC.4.9C**_ . Example output could include change control
+forms, or configuration item access approval forms.
+
+
+ALC_CMC.4-13 The evaluator _**shall examine**_ the evidence to determine that the CM system
+is being operated in accordance with the CM plan.
+
+
+1053 The evaluator should select and examine a sample of evidence covering each
+type of CM-relevant operation that has been performed on a configuration
+item (e.g. creation, modification, deletion, reversion to an earlier version) to
+confirm that all operations of the CM system have been carried out in line
+with documented procedures. The evaluator confirms that the evidence
+includes all the information identified for that operation in the CM plan.
+Examination of the evidence may require access to a CM tool that is used.
+The evaluator may choose to sample the evidence.
+
+
+1054 For guidance on sampling see A.2, Sampling.
+
+
+1055 Further confidence in the correct operation of the CM system and the
+effective maintenance of configuration items may be established by means of
+interviews with selected development staff. In conducting such interviews,
+the evaluator aims to gain a deeper understanding of how the CM system is
+used in practise as well as to confirm that the CM procedures are being
+applied as described in the CM documentation. Note that such interviews
+should complement rather than replace the examination of documentary
+evidence, and may not be necessary if the documentary evidence alone
+
+
+April 2017 Version 3.1 Page 227 of 430
+
+
+**Class ALC: Life-cycle support**
+
+
+satisfies the requirement. However, given the wide scope of the CM plan it is
+possible that some aspects (e.g. roles and responsibilities) may not be clear
+from the CM plan and records alone. This is one case where clarification
+may be necessary through interviews.
+
+
+1056 It is expected that the evaluator will visit the development site in support of
+this activity.
+
+
+1057 For guidance on site visits see A.4, Site Visits.
+
+
+**14.2.5** **Evaluation of sub-activity (ALC_CMC.5)**
+
+
+14.2.5.1 Objectives
+
+
+1058 The objectives of this sub-activity are to determine whether the developer
+has clearly identified the TOE and its associated configuration items, and
+whether the ability to modify these items is properly controlled by automated
+tools, thus making the CM system less susceptible to human error or
+negligence.
+
+
+14.2.5.2 Input
+
+
+1059 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the TOE suitable for testing;
+
+
+c) the configuration management documentation.
+
+
+14.2.5.3 Action ALC_CMC.5.1E
+
+
+ALC_CMC.5.1C _**The TOE shall be labelled with its unique reference.**_
+
+
+ALC_CMC.5-1 The evaluator _**shall check**_ that the TOE provided for evaluation is labelled
+with its reference.
+
+
+1060 The evaluator should ensure that the TOE contains the unique reference
+which is stated in the ST. This could be achieved through labelled packaging
+or media, or by a label displayed by the operational TOE. This is to ensure
+that it would be possible for consumers to identify the TOE (e.g. at the point
+of purchase or use).
+
+
+1061 The TOE may provide a method by which it can be easily identified. For
+example, a software TOE may display its name and version number during
+the start up routine, or in response to a command line entry. A hardware or
+firmware TOE may be identified by a part number physically stamped on the
+TOE.
+
+
+1062 Alternatively, the unique reference provided for the TOE may be the
+combination of the unique reference of each component from which the TOE
+is comprised (e.g. in the case of a composed TOE).
+
+
+Page 228 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+ALC_CMC.5-2 The evaluator _**shall check**_ that the TOE references used are consistent.
+
+
+1063 If the TOE is labelled more than once then the labels have to be consistent.
+For example, it should be possible to relate any labelled guidance
+documentation supplied as part of the TOE to the evaluated operational TOE.
+This ensures that consumers can be confident that they have purchased the
+evaluated version of the TOE, that they have installed this version, and that
+they have the correct version of the guidance to operate the TOE in
+accordance with its ST.
+
+
+1064 The evaluator also verifies that the TOE reference is consistent with the ST.
+
+
+1065 If this work unit is applied to a composed TOE, the following will apply. The
+composed IT TOE will not be labelled with its unique (composite) reference,
+but only the individual components will be labelled with their appropriate
+TOE reference. It would require further development for the IT TOE to be
+labelled, i.e. during start-up and/or operation, with the composite reference.
+If the composed TOE is delivered as the constituent component TOEs, then
+the TOE items delivered will not contain the composite reference. However,
+the composed TOE ST will include the unique reference for the composed
+TOE and will identify the components comprising the composed TOE
+through which the consumers will be able to determine whether they have
+the appropriate items.
+
+
+ALC_CMC.5.2C _**The CM documentation shall describe the method used to uniquely identify**_
+_**the configuration items.**_
+
+
+ALC_CMC.5-3 The evaluator _**shall examine**_ the method of identifying configuration items
+to determine that it describes how configuration items are uniquely identified.
+
+
+1066 Procedures should describe how the status of each configuration item can be
+tracked throughout the life-cycle of the TOE. The procedures may be
+detailed in the CM plan or throughout the CM documentation. The
+information included should describe:
+
+
+a) the method how each configuration item is uniquely identified, such
+that it is possible to track versions of the same configuration item;
+
+
+b) the method how configuration items are assigned unique identifiers
+and how they are entered into the CM system;
+
+
+c) the method to be used to identify superseded versions of a
+configuration item.
+
+
+ALC_CMC.5.3C _**The CM documentation shall justify that the acceptance procedures**_
+_**provide for an adequate and appropriate review of changes to all**_
+_**configuration items.**_
+
+
+ALC_CMC.5-4 The evaluator _**shall examine**_ the CM documentation to determine that it
+justifies that the acceptance procedures provide for an adequate and
+appropriate review of changes to all configuration items.
+
+
+April 2017 Version 3.1 Page 229 of 430
+
+
+**Class ALC: Life-cycle support**
+
+
+1067 The CM documentation should make it sufficiently clear that by following
+the acceptance procedures only parts of adequate quality are incorporated
+into the TOE.
+
+
+ALC_CMC.5.4C _**The CM system shall uniquely identify all configuration items.**_
+
+
+ALC_CMC.5-5 The evaluator _**shall examine**_ the configuration items to determine that they
+are identified in a way that is consistent with the CM documentation.
+
+
+1068 Assurance that the CM system uniquely identifies all configuration items is
+gained by examining the identifiers for the configuration items. For both
+configuration items that comprise the TOE, and drafts of configuration items
+that are submitted by the developer as evaluation evidence, the evaluator
+confirms that each configuration item possesses a unique identifier in a
+manner consistent with the unique identification method that is described in
+the CM documentation.
+
+
+ALC_CMC.5.5C _**The CM system shall provide automated measures such that only**_
+_**authorised changes are made to the configuration items.**_
+
+
+ALC_CMC.5-6 The evaluator _**shall examine**_ the CM access control measures described in
+the CM plan (cf. _**ALC_CMC.5.12C**_ ) to determine that they are automated
+and effective in preventing unauthorised access to the configuration items.
+
+
+1069 The evaluator may use a number of methods to determine that the CM access
+control measures are effective. For example, the evaluator may exercise the
+access control measures to ensure that the procedures could not be bypassed.
+The evaluator may use the outputs generated by the CM system procedures
+required by _**ALC_CMC.5.16C**_ . The evaluator may also witness a
+demonstration of the CM system to ensure that the access control measures
+employed are operating effectively.
+
+
+ALC_CMC.5.6C _**The CM system shall support the production of the TOE by automated**_
+_**means.**_
+
+
+ALC_CMC.5-7 The evaluator _**shall check**_ the CM plan (cf. _**ALC_CMC.5.12C**_ ) for
+automated procedures for supporting the production of the TOE.
+
+
+1070 The term โproductionโ applies to those processes adopted by the developer to
+progress the TOE from the implementation representation to a state
+acceptable for delivery to the end customer.
+
+
+1071 The evaluator verifies the existence of automated production support
+procedures within the CM plan.
+
+
+1072 The following are examples for automated means supporting the production
+of the TOE:
+
+
+๏ญ a โmakeโ tool (as provided with many software development tools) in
+the case of a software TOE;
+
+
+Page 230 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+๏ญ a tool ensuring automatically (for example by means of bar codes)
+that only parts are combined which indeed belong together in the case
+of a hardware TOE.
+
+
+ALC_CMC.5-8 The evaluator _**shall examine**_ the TOE production support procedures to
+determine that they are effective in ensuring that a TOE is generated that
+reflects its implementation representation.
+
+
+1073 The production support procedures should describe which tools have to be
+used to produce the final TOE from the implementation representation in a
+clearly defined way. The conventions, directives, or other necessary
+constructs are described under ALC_TAT.
+
+
+1074 The evaluator determines that by following the production support
+procedures the correct configuration items would be used to generate the
+TOE. For example, in a software TOE this may include checking that the
+automated production procedures ensure that all source files and related
+libraries are included in the compiled object code. Moreover, the procedures
+should ensure that compiler options and comparable other options are
+defined uniquely. For a hardware TOE, this work unit may include checking
+that the automatic production procedures ensure that the belonging parts are
+built together and no parts are missing.
+
+
+1075 The customer can then be confident that the version of the TOE delivered for
+installation is derived from the implementation representation in an
+unambiguous way and implements the SFRs as described in the ST.
+
+
+1076 The evaluator should bear in mind that the CM system need not necessarily
+possess the capability to produce the TOE, but should provide support for the
+process that will help reduce the probability of human error.
+
+
+ALC_CMC.5.7C _**The CM system shall ensure that the person responsible for accepting a**_
+_**configuration item into CM is not the person who developed it.**_
+
+
+ALC_CMC.5-9 The evaluator _**shall examine**_ the CM system to determine that it ensures that
+the person responsible for accepting a configuration item is not the person
+who developed it.
+
+
+1077 The acceptance procedures describe who is responsible for accepting a
+configuration item. From these descriptions, the evaluator should be able to
+determine that the person who developed a configuration item is in no case
+responsible for its acceptance.
+
+
+ALC_CMC.5.8C _**The CM system shall identify the configuration items that comprise the**_
+_**TSF.**_
+
+
+ALC_CMC.5-10 The evaluator _**shall examine**_ the CM system to determine that it identifies
+the configuration items that comprise the TSF.
+
+
+1078 The CM documentation should describe how the CM system identifies the
+configuration items that comprise the TSF. The evaluator should select a
+
+
+April 2017 Version 3.1 Page 231 of 430
+
+
+**Class ALC: Life-cycle support**
+
+
+sample of configuration items covering each type of items, particularly
+containing TSF and non-TSF items, and check that they are correctly
+classified by the CM system.
+
+
+1079 For guidance on sampling see A.2, Sampling.
+
+
+ALC_CMC.5.9C _**The CM system shall support the audit of all changes to the TOE by**_
+_**automated means, including the originator, date, and time in the audit trail.**_
+
+
+ALC_CMC.5-11 The evaluator _**shall examine**_ the CM system to determine that it supports the
+audit of all changes to the TOE by automated means, including the originator,
+date, and time in the audit trail.
+
+
+1080 The evaluator should inspect a sample of audit trails and check, if they
+contain the minimum information.
+
+
+ALC_CMC.5.10C _**The CM system shall provide an automated means to identify all other**_
+_**configuration items that are affected by the change of a given**_
+_**configuration item.**_
+
+
+ALC_CMC.5-12 The evaluator _**shall examine**_ the CM system to determine that it provides an
+automated means to identify all other configuration items that are affected by
+the change of a given configuration item.
+
+
+1081 The CM documentation should describe how the CM system identifies all
+other configuration items that are affected by the change of a given
+configuration item. The evaluator should select a sample of configuration
+items, covering all types of items, and exercise the automated means to
+determine that it identifies all items that are affected by the change of the
+selected item.
+
+
+1082 For guidance on sampling see A.2, Sampling.
+
+
+ALC_CMC.5.11C _**The CM system shall be able to identify the version of the implementation**_
+_**representation from which the TOE is generated.**_
+
+
+ALC_CMC.5-13 The evaluator _**shall examine**_ the CM system to determine that it is able to
+identify the version of the implementation representation from which the
+TOE is generated.
+
+
+1083 The CM documentation should describe how the CM system identifies the
+version of the implementation representation from which the TOE is
+generated. The evaluator should select a sample of the parts used to produce
+the TOE and should apply the CM system to verify that it identifies the
+corresponding implementation representation in the correct version.
+
+
+1084 For guidance on sampling see A.2, Sampling.
+
+
+ALC_CMC.5.12C _**The CM documentation shall include a CM plan.**_
+
+
+ALC_CMC.5-14 The evaluator _**shall check**_ that the CM documentation provided includes a
+CM plan.
+
+
+Page 232 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+1085 The CM plan needs not to be a connected document, but it is recommended
+that there is a single document that describes where the various parts of the
+CM plan can be found. If the CM plan is no single document, the list in the
+following work unit gives hints regarding which context is expected.
+
+
+ALC_CMC.5.13C _**The CM plan shall describe how the CM system is used for the**_
+_**development of the TOE.**_
+
+
+ALC_CMC.5-15 The evaluator _**shall examine**_ the CM plan to determine that it describes how
+the CM system is used for the development of the TOE.
+
+
+1086 The descriptions contained in a CM plan include, if applicable:
+
+
+a) all activities performed in the TOE development that are subject to
+configuration management procedures (e.g. creation, modification or
+deletion of a configuration item, data-backup, archiving);
+
+
+b) which means (e.g. CM tools, forms) have to be made available;
+
+
+c) the usage of the CM tools: the necessary details for a user of the CM
+system to be able to operate the CM tools correctly in order to
+maintain the integrity of the TOE;
+
+
+d) the production support procedures;
+
+
+e) which other objects (development components, tools, assessment
+environments, etc) are taken under CM control;
+
+
+f) the roles and responsibilities of individuals required to perform
+operations on individual configuration items (different roles may be
+identified for different types of configuration items (e.g. design
+documentation or source code));
+
+
+g) how CM instances (e.g. change control boards, interface control
+working groups) are introduced and staffed;
+
+
+h) the description of the change management;
+
+
+i) the procedures that are used to ensure that only authorised individuals
+can make changes to configuration items;
+
+
+j) the procedures that are used to ensure that concurrency problems do
+not occur as a result of simultaneous changes to configuration items;
+
+
+k) the evidence that is generated as a result of application of the
+procedures. For example, for a change to a configuration item, the
+CM system might record a description of the change, accountability
+for the change, identification of all configuration items affected,
+status (e.g. pending or completed), and date and time of the change.
+This might be recorded in an audit trail of changes made or change
+control records;
+
+
+April 2017 Version 3.1 Page 233 of 430
+
+
+**Class ALC: Life-cycle support**
+
+
+l) the approach to version control and unique referencing of TOE
+versions (e.g. covering the release of patches in operating systems,
+and the subsequent detection of their application).
+
+
+ALC_CMC.5.14C _**The CM plan shall describe the procedures used to accept modified or**_
+_**newly created configuration items as part of the TOE.**_
+
+
+ALC_CMC.5-16 The evaluator _**shall examine**_ the CM plan to determine that it describes the
+procedures used to accept modified or newly created configuration items as
+parts of the TOE.
+
+
+1087 The descriptions of the acceptance procedures in the CM plan should include
+the developer roles or individuals responsible for the acceptance and the
+criteria to be used for acceptance. They should take into account all
+acceptance situations that may occur, in particular:
+
+
+a) accepting an item into the CM system for the first time, in particular
+inclusion of software, firmware and hardware components from other
+manufacturers into the TOE (โintegrationโ);
+
+
+b) moving configuration items to the next life-cycle phase at each stage
+of the construction of the TOE (e.g. module, subsystem, system);
+
+
+c) subsequent to transports between different development sites.
+
+
+ALC_CMC.5.15C _**The evidence shall demonstrate that all configuration items are being**_
+_**maintained under the CM system.**_
+
+
+ALC_CMC.5-17 The evaluator _**shall check**_ that the configuration items identified in the
+configuration list are being maintained by the CM system.
+
+
+1088 The CM system employed by the developer should maintain the integrity of
+the TOE. The evaluator should check that for each type of configuration item
+(e.g. design documents or source code modules) contained in the
+configuration list there are examples of the evidence generated by the
+procedures described in the CM plan. In this case, the approach to sampling
+will depend upon the level of granularity used in the CM system to control
+CM items. Where, for example, 10,000 source code modules are identified in
+the configuration list, a different sampling strategy needs to be applied
+compared to the case in which there are only 5, or even 1. The emphasis of
+this activity should be on ensuring that the CM system is being operated
+correctly, rather than on the detection of any minor error.
+
+
+1089 For guidance on sampling see A.2, Sampling.
+
+
+ALC_CMC.5.16C _**The evidence shall demonstrate that the CM system is being operated in**_
+_**accordance with the CM plan.**_
+
+
+ALC_CMC.5-18 The evaluator _**shall check**_ the CM documentation to ascertain that it includes
+the CM system records identified by the CM plan.
+
+
+Page 234 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+1090 The output produced by the CM system should provide the evidence that the
+evaluator needs to be confident that the CM plan is being applied, and also
+that all configuration items are being maintained by the CM system as
+required by _**ALC_CMC.5.15C**_ . Example output could include change control
+forms, or configuration item access approval forms.
+
+
+ALC_CMC.5-19 The evaluator _**shall examine**_ the evidence to determine that the CM system
+is being operated in accordance with the CM plan.
+
+
+1091 The evaluator should select and examine a sample of evidence covering each
+type of CM-relevant operation that has been performed on a configuration
+item (e.g. creation, modification, deletion, reversion to an earlier version) to
+confirm that all operations of the CM system have been carried out in line
+with documented procedures. The evaluator confirms that the evidence
+includes all the information identified for that operation in the CM plan.
+Examination of the evidence may require access to a CM tool that is used.
+The evaluator may choose to sample the evidence.
+
+
+1092 For guidance on sampling see A.2, Sampling.
+
+
+1093 Further confidence in the correct operation of the CM system and the
+effective maintenance of configuration items may be established by means of
+interviews with selected development staff. In conducting such interviews,
+the evaluator aims to gain a deeper understanding of how the CM system is
+used in practise as well as to confirm that the CM procedures are being
+applied as described in the CM documentation. Note that such interviews
+should complement rather than replace the examination of documentary
+evidence, and may not be necessary if the documentary evidence alone
+satisfies the requirement. However, given the wide scope of the CM plan it is
+possible that some aspects (e.g. roles and responsibilities) may not be clear
+from the CM plan and records alone. This is one case where clarification
+may be necessary through interviews.
+
+
+1094 It is expected that the evaluator will visit the development site in support of
+this activity.
+
+
+1095 For guidance on site visits see A.4, Site Visits.
+
+
+14.2.5.4 Action ALC_CMC.5.2E
+
+
+ALC_CMC.5-20 The evaluator _**shall examine**_ the production support procedures to determine
+that by following these procedures a TOE would be produced like that one
+provided by the developer for testing activities.
+
+
+1096 If the TOE is a small software TOE and production consists of compiling
+and linking, the evaluator might confirm the adequacy of the production
+support procedures by reapplying them himself.
+
+
+1097 If the production process of the TOE is more complicated (as for example in
+the case of a smart card), but has already started, the evaluator should inspect
+the application of the production support procedures during a visit of the
+
+
+April 2017 Version 3.1 Page 235 of 430
+
+
+**Class ALC: Life-cycle support**
+
+
+development site. He might compare a copy of the TOE produced in his
+presence with the samples used for his testing activities.
+
+
+1098 For guidance on site visits see A.4, Site Visits.
+
+
+1099 Otherwise the evaluator's determination should be based on the documentary
+evidence provided by the developer.
+
+
+1100 This work unit may be performed in conjunction with the evaluation
+activities under Implementation representation (ADV_IMP).
+
+
+Page 236 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+## **14.3 CM scope (ALC_CMS)**
+
+
+**14.3.1** **Evaluation of sub-activity (ALC_CMS.1)**
+
+
+14.3.1.1 Objectives
+
+
+1101 The objective of this sub-activity is to determine whether the developer
+performs configuration management on the TOE and the evaluation evidence.
+These configuration items are controlled in accordance with CM capabilities
+(ALC_CMC).
+
+
+14.3.1.2 Input
+
+
+1102 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the configuration list.
+
+
+14.3.1.3 Action ALC_CMS.1.1E
+
+
+ALC_CMS.1.1C _**The configuration list shall include the following: the TOE itself; and the**_
+_**evaluation evidence required by the SARs.**_
+
+
+ALC_CMS.1-1 The evaluator _**shall check**_ that the configuration list includes the following
+set of items:
+
+
+a) the TOE itself;
+
+
+b) the evaluation evidence required by the SARs in the ST.
+
+
+ALC_CMS.1.2C _**The configuration list shall uniquely identify the configuration items.**_
+
+
+ALC_CMS.1-2 The evaluator _**shall examine**_ the configuration list to determine that it
+uniquely identifies each configuration item.
+
+
+1103 The configuration list contains sufficient information to uniquely identify
+which version of each item has been used (typically a version number). Use
+of this list will enable the evaluator to check that the correct configuration
+items, and the correct version of each item, have been used during the
+evaluation.
+
+
+**14.3.2** **Evaluation of sub-activity (ALC_CMS.2)**
+
+
+14.3.2.1 Objectives
+
+
+1104 The objective of this sub-activity is to determine whether the configuration
+list includes the TOE, the parts that comprise the TOE, and the evaluation
+evidence. These configuration items are controlled in accordance with CM
+capabilities (ALC_CMC).
+
+
+April 2017 Version 3.1 Page 237 of 430
+
+
+**Class ALC: Life-cycle support**
+
+
+14.3.2.2 Input
+
+
+1105 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the configuration list.
+
+
+14.3.2.3 Action ALC_CMS.2.1E
+
+
+ALC_CMS.2.1C _**The configuration list shall include the following: the TOE itself; the**_
+_**evaluation evidence required by the SARs; and the parts that comprise the**_
+_**TOE.**_
+
+
+ALC_CMS.2-1 The evaluator _**shall check**_ that the configuration list includes the following
+set of items:
+
+
+a) the TOE itself;
+
+
+b) the parts that comprise the TOE;
+
+
+c) the evaluation evidence required by the SARs.
+
+
+ALC_CMS.2.2C _**The configuration list shall uniquely identify the configuration items.**_
+
+
+ALC_CMS.2-2 The evaluator _**shall examine**_ the configuration list to determine that it
+uniquely identifies each configuration item.
+
+
+1106 The configuration list contains sufficient information to uniquely identify
+which version of each item has been used (typically a version number). Use
+of this list will enable the evaluator to check that the correct configuration
+items, and the correct version of each item, have been used during the
+evaluation.
+
+
+ALC_CMS.2.3C _**For each TSF relevant configuration item, the configuration list shall**_
+_**indicate the developer of the item.**_
+
+
+ALC_CMS.2-3 The evaluator _**shall check**_ that the configuration list indicates the developer
+of each TSF relevant configuration item.
+
+
+1107 If only one developer is involved in the development of the TOE, this work
+unit is not applicable, and is therefore considered to be satisfied.
+
+
+**14.3.3** **Evaluation of sub-activity (ALC_CMS.3)**
+
+
+14.3.3.1 Objectives
+
+
+1108 The objective of this sub-activity is to determine whether the configuration
+list includes the TOE, the parts that comprise the TOE, the TOE
+implementation representation, and the evaluation evidence. These
+configuration items are controlled in accordance with CM capabilities
+(ALC_CMC).
+
+
+Page 238 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+14.3.3.2 Input
+
+
+1109 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the configuration list.
+
+
+14.3.3.3 Action ALC_CMS.3.1E
+
+
+ALC_CMS.3.1C _**The configuration list shall include the following: the TOE itself; the**_
+_**evaluation evidence required by the SARs; the parts that comprise the**_
+_**TOE; and the implementation representation.**_
+
+
+ALC_CMS.3-1 The evaluator _**shall check**_ that the configuration list includes the following
+set of items:
+
+
+a) the TOE itself;
+
+
+b) the parts that comprise the TOE;
+
+
+c) the TOE implementation representation;
+
+
+d) the evaluation evidence required by the SARs in the ST.
+
+
+ALC_CMS.3.2C _**The configuration list shall uniquely identify the configuration items.**_
+
+
+ALC_CMS.3-2 The evaluator _**shall examine**_ the configuration list to determine that it
+uniquely identifies each configuration item.
+
+
+1110 The configuration list contains sufficient information to uniquely identify
+which version of each item has been used (typically a version number). Use
+of this list will enable the evaluator to check that the correct configuration
+items, and the correct version of each item, have been used during the
+evaluation.
+
+
+ALC_CMS.3.3C _**For each TSF relevant configuration item, the configuration list shall**_
+_**indicate the developer of the item.**_
+
+
+ALC_CMS.3-3 The evaluator _**shall check**_ that the configuration list indicates the developer
+of each TSF relevant configuration item.
+
+
+1111 If only one developer is involved in the development of the TOE, this work
+unit is not applicable, and is therefore considered to be satisfied.
+
+
+**14.3.4** **Evaluation of sub-activity (ALC_CMS.4)**
+
+
+14.3.4.1 Objectives
+
+
+1112 The objective of this sub-activity is to determine whether the configuration
+list includes the TOE, the parts that comprise the TOE, the TOE
+implementation representation, security flaws, and the evaluation evidence.
+
+
+April 2017 Version 3.1 Page 239 of 430
+
+
+**Class ALC: Life-cycle support**
+
+
+These configuration items are controlled in accordance with CM capabilities
+(ALC_CMC).
+
+
+14.3.4.2 Input
+
+
+1113 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the configuration list.
+
+
+14.3.4.3 Action ALC_CMS.4.1E
+
+
+ALC_CMS.4.1C _**The configuration list shall include the following: the TOE itself; the**_
+_**evaluation evidence required by the SARs; the parts that comprise the**_
+_**TOE; the implementation representation; and security flaw reports and**_
+_**resolution status.**_
+
+
+ALC_CMS.4-1 The evaluator _**shall check**_ that the configuration list includes the following
+set of items:
+
+
+a) the TOE itself;
+
+
+b) the parts that comprise the TOE;
+
+
+c) the TOE implementation representation;
+
+
+d) the evaluation evidence required by the SARs in the ST;
+
+
+e) the documentation used to record details of reported security flaws
+associated with the implementation (e.g., problem status reports
+derived from a developer's problem database).
+
+
+ALC_CMS.4.2C _**The configuration list shall uniquely identify the configuration items.**_
+
+
+ALC_CMS.4-2 The evaluator _**shall examine**_ the configuration list to determine that it
+uniquely identifies each configuration item.
+
+
+1114 The configuration list contains sufficient information to uniquely identify
+which version of each item has been used (typically a version number). Use
+of this list will enable the evaluator to check that the correct configuration
+items, and the correct version of each item, have been used during the
+evaluation.
+
+
+ALC_CMS.4.3C _**For each TSF relevant configuration item, the configuration list shall**_
+_**indicate the developer of the item.**_
+
+
+ALC_CMS.4-3 The evaluator _**shall check**_ that the configuration list indicates the developer
+of each TSF relevant configuration item.
+
+
+1115 If only one developer is involved in the development of the TOE, this work
+unit is not applicable, and is therefore considered to be satisfied.
+
+
+Page 240 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+**14.3.5** **Evaluation of sub-activity (ALC_CMS.5)**
+
+
+14.3.5.1 Objectives
+
+
+1116 The objective of this sub-activity is to determine whether the configuration
+list includes the TOE, the parts that comprise the TOE, the TOE
+implementation representation, security flaws, development tools and related
+information, and the evaluation evidence. These configuration items are
+controlled in accordance with CM capabilities (ALC_CMC).
+
+
+14.3.5.2 Input
+
+
+1117 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the configuration list.
+
+
+14.3.5.3 Action ALC_CMS.5.1E
+
+
+ALC_CMS.5.1C _**The configuration list shall include the following: the TOE itself; the**_
+_**evaluation evidence required by the SARs; the parts that comprise the**_
+_**TOE; the implementation representation; security flaw reports and**_
+_**resolution status; and development tools and related information.**_
+
+
+ALC_CMS.5-1 The evaluator _**shall check**_ that the configuration list includes the following
+set of items:
+
+
+a) the TOE itself;
+
+
+b) the parts that comprise the TOE;
+
+
+c) the TOE implementation representation;
+
+
+d) the evaluation evidence required by the SARs in the ST;
+
+
+e) the documentation used to record details of reported security flaws
+associated with the implementation (e.g., problem status reports
+derived from a developer's problem database);
+
+
+f) all tools (incl. test software, if applicable) involved in the
+development and production of the TOE including the names,
+versions, configurations and roles of each development tool, and
+related documentation.
+
+
+1118 For a software TOE, โdevelopment toolsโ are usually programming
+languages and compiler and โrelated documentationโ comprises compiler
+and linker options. For a hardware TOE, โdevelopment toolsโ might be
+hardware design languages, simulation and synthesis tools, compilers, and
+โrelated documentationโ might comprise compiler options again.
+
+
+ALC_CMS.5.2C _**The configuration list shall uniquely identify the configuration items.**_
+
+
+April 2017 Version 3.1 Page 241 of 430
+
+
+**Class ALC: Life-cycle support**
+
+
+ALC_CMS.5-2 The evaluator _**shall examine**_ the configuration list to determine that it
+uniquely identifies each configuration item.
+
+
+1119 The configuration list contains sufficient information to uniquely identify
+which version of each item has been used (typically a version number). Use
+of this list will enable the evaluator to check that the correct configuration
+items, and the correct version of each item, have been used during the
+evaluation.
+
+
+ALC_CMS.5.3C _**For each TSF relevant configuration item, the configuration list shall**_
+_**indicate the developer of the item.**_
+
+
+ALC_CMS.5-3 The evaluator _**shall check**_ that the configuration list indicates the developer
+of each TSF relevant configuration item.
+
+
+1120 If only one developer is involved in the development of the TOE, this work
+unit is not applicable, and is therefore considered to be satisfied.
+
+
+Page 242 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+## **14.4 Delivery (ALC_DEL)**
+
+
+**14.4.1** **Evaluation of sub-activity (ALC_DEL.1)**
+
+
+14.4.1.1 Objectives
+
+
+1121 The objective of this sub-activity is to determine whether the delivery
+documentation describes all procedures used to maintain security of the TOE
+when distributing the TOE to the user.
+
+
+14.4.1.2 Input
+
+
+1122 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the delivery documentation.
+
+
+14.4.1.3 Action ALC_DEL.1.1E
+
+
+ALC_DEL.1.1C _**The delivery documentation shall describe all procedures that are**_
+_**necessary to maintain security when distributing versions of the TOE to**_
+_**the consumer.**_
+
+
+ALC_DEL.1-1 The evaluator _**shall examine**_ the delivery documentation to determine that it
+describes all procedures that are necessary to maintain security when
+distributing versions of the TOE or parts of it to the consumer.
+
+
+1123 The delivery documentation describes proper procedures to maintain security
+of the TOE during transfer of the TOE or its component parts and to
+determine the identification of the TOE.
+
+
+1124 The delivery documentation should cover the entire TOE, but may contain
+different procedures for different parts of the TOE. The evaluation should
+consider the totality of procedures.
+
+
+1125 The delivery procedures should be applicable across all phases of delivery
+from the production environment to the installation environment (e.g.
+packaging, storage and distribution). Standard commercial practise for
+packaging and delivery may be acceptable. This includes shrink wrapped
+packaging, a security tape or a sealed envelope. For the distribution, physical
+(e.g. public mail or a private distribution service) or electronic (e.g.
+electronic mail or downloading off the Internet) procedures may be used.
+
+
+1126 Cryptographic checksums or a software signature may be used by the
+developer to ensure that tampering or masquerading can be detected. Tamper
+proof seals additionally indicate if the confidentiality has been broken. For
+software TOEs, confidentiality might be assured by using encryption. If
+availability is of concern, a secure transportation might be required.
+
+
+1127 Interpretation of the term โnecessary to maintain securityโ will need to
+consider:
+
+
+April 2017 Version 3.1 Page 243 of 430
+
+
+**Class ALC: Life-cycle support**
+
+
+๏ญ The nature of the TOE (e.g. whether it is software or hardware).
+
+
+๏ญ The overall security level stated for the TOE by the chosen level of
+the Vulnerability Assessment. If the TOE is required to be resistant
+against attackers of a certain potential in its intended environment,
+this should also apply to the delivery of the TOE. The evaluator
+should determine that a balanced approach has been taken, such that
+delivery does not present a weak point in an otherwise secure
+development process.
+
+
+๏ญ The security objectives provided by the ST. The emphasis in the
+delivery documentation is likely to be on measures related to integrity,
+as integrity of the TOE is always important. However, confidentiality
+and availability of the delivery will be of concern in the delivery of
+some TOEs; procedures relating to these aspects of the secure
+delivery should also be discussed in the procedures.
+
+
+14.4.1.4 Implied evaluator action
+
+
+ALC_DEL.1.2D _**The developer shall use the delivery procedures.**_
+
+
+ALC_DEL.1-2 The evaluator _**shall examine**_ aspects of the delivery process to determine that
+the delivery procedures are used.
+
+
+1128 The approach taken by the evaluator to check the application of delivery
+procedures will depend on the nature of the TOE, and the delivery process
+itself. In addition to examination of the procedures themselves, the evaluator
+seeks some assurance that they are applied in practise. Some possible
+approaches are:
+
+
+a) a visit to the distribution site(s) where practical application of the
+procedures may be observed;
+
+
+b) examination of the TOE at some stage during delivery, or after the
+user has received it (e.g. checking for tamper proof seals);
+
+
+c) observing that the process is applied in practise when the evaluator
+obtains the TOE through regular channels;
+
+
+d) questioning end users as to how the TOE was delivered.
+
+
+1129 For guidance on site visits see A.4, Site Visits.
+
+
+1130 It may be the case of a newly developed TOE that the delivery procedures
+have yet to be exercised. In these cases, the evaluator has to be satisfied that
+appropriate procedures and facilities are in place for future deliveries and
+that all personnel involved are aware of their responsibilities. The evaluator
+may request a โdry runโ of a delivery if this is practical. If the developer has
+produced other similar products, then an examination of procedures in their
+use may be useful in providing assurance.
+
+
+Page 244 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+## **14.5 Development security (ALC_DVS)**
+
+
+**14.5.1** **Evaluation of sub-activity (ALC_DVS.1)**
+
+
+14.5.1.1 Objectives
+
+
+1131 The objective of this sub-activity is to determine whether the developer's
+security controls on the development environment are adequate to provide
+the confidentiality and integrity of the TOE design and implementation that
+is necessary to ensure that secure operation of the TOE is not compromised.
+
+
+14.5.1.2 Input
+
+
+1132 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the development security documentation.
+
+
+1133 In addition, the evaluator may need to examine other deliverables to
+determine that the security controls are well-defined and followed.
+Specifically, the evaluator may need to examine the developer's
+configuration management documentation (the input for the Evaluation of
+sub-activity (ALC_CMC.4) โProduction support and acceptance proceduresโ
+and the Evaluation of sub-activity (ALC_CMS.4) โProblem tracking CM
+coverageโ). Evidence that the procedures are being applied is also required.
+
+
+14.5.1.3 Action ALC_DVS.1.1E
+
+
+ALC_DVS.1.1C _**The development security documentation shall describe all the physical,**_
+_**procedural, personnel, and other security measures that are necessary to**_
+_**protect the confidentiality and integrity of the TOE design and**_
+_**implementation in its development environment.**_
+
+
+ALC_DVS.1-1 The evaluator _**shall examine**_ the development security documentation to
+determine that it details all security measures used in the development
+environment that are necessary to protect the confidentiality and integrity of
+the TOE design and implementation.
+
+
+1134 The evaluator determines what is necessary by first referring to the ST for
+any information that may assist in the determination of necessary protection.
+
+
+1135 If no explicit information is available from the ST the evaluator will need to
+make a determination of the necessary measures. In cases where the
+developer's measures are considered less than what is necessary, a clear
+justification should be provided for the assessment, based on a potential
+exploitable vulnerability.
+
+
+1136 The following types of security measures are considered by the evaluator
+when examining the documentation:
+
+
+April 2017 Version 3.1 Page 245 of 430
+
+
+**Class ALC: Life-cycle support**
+
+
+a) physical, for example physical access controls used to prevent
+unauthorised access to the TOE development environment (during
+normal working hours and at other times);
+
+
+b) procedural, for example covering:
+
+
+๏ญ granting of access to the development environment or to
+specific parts of the environment such as development
+machines
+
+
+๏ญ revocation of access rights when a person leaves the
+development team
+
+
+๏ญ transfer of protected material within and out of the
+development environment and between different development
+sites in accordance with defined acceptance procedures
+
+
+๏ญ admitting and escorting visitors to the development
+environment
+
+
+๏ญ roles and responsibilities in ensuring the continued
+application of security measures, and the detection of security
+breaches.
+
+
+c) personnel, for example any controls or checks made to establish the
+trustworthiness of new development staff;
+
+
+d) other security measures, for example the logical protections on any
+development machines.
+
+
+1137 The development security documentation should identify the locations at
+which development occurs, and describe the aspects of development
+performed, along with the security measures applied at each location and for
+transports between different locations. For example, development could
+occur at multiple facilities within a single building, multiple buildings at the
+same site, or at multiple sites. Transports of parts of the TOE or the
+unfinished TOE between different development sites are to be covered by
+Development security (ALC_DVS), whereas the transport of the finished
+TOE to the consumer is dealt with in Delivery (ALC_DEL).
+
+
+1138 Development includes the production of the TOE.
+
+
+ALC_DVS.1-2 The evaluator _**shall examine**_ the development confidentiality and integrity
+policies in order to determine the sufficiency of the security measures
+employed.
+
+
+1139 The evaluator should examine whether the following is included in the
+policies:
+
+
+Page 246 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+a) what information relating to the TOE development needs to be kept
+confidential, and which members of the development staff are
+allowed to access such material;
+
+
+b) what material must be protected from unauthorised modification in
+order to preserve the integrity of the TOE, and which members of the
+development staff are allowed to modify such material.
+
+
+1140 The evaluator should determine that these policies are described in the
+development security documentation, that the security measures employed
+are consistent with the policies, and that they are complete.
+
+
+1141 It should be noted that configuration management procedures will help
+protect the integrity of the TOE and the evaluator should avoid overlap with
+the work-units conducted for the CM capabilities (ALC_CMC). For example,
+the CM documentation may describe the security procedures necessary for
+controlling the roles or individuals who should have access to the
+development environment and who may modify the TOE.
+
+
+1142 Whereas the CM capabilities (ALC_CMC) requirements are fixed, those for
+the Development security (ALC_DVS), mandating only necessary measures,
+are dependent on the nature of the TOE, and on information that may be
+provided in the ST. The evaluators would then determine that such a policy
+had been applied under this sub-activity.
+
+
+14.5.1.4 Action ALC_DVS.1.2E
+
+
+ALC_DVS.1-3 The evaluator _**shall examine**_ the development security documentation and
+associated evidence to determine that the security measures are being applied.
+
+
+1143 This work unit requires the evaluator to determine that the security measures
+described in the development security documentation are being followed,
+such that the integrity of the TOE and the confidentiality of associated
+documentation is being adequately protected. For example, this could be
+determined by examination of the documentary evidence provided.
+Documentary evidence should be supplemented by visiting the development
+environment. A visit to the development environment will allow the
+evaluator to:
+
+
+a) observe the application of security measures (e.g. physical measures);
+
+
+b) examine documentary evidence of application of procedures;
+
+
+c) interview development staff to check awareness of the development
+security policies and procedures, and their responsibilities.
+
+
+1144 A development site visit is a useful means of gaining confidence in the
+measures being used. Any decision not to make such a visit should be
+determined in consultation with the evaluation authority.
+
+
+1145 For guidance on site visits see A.4, Site Visits.
+
+
+April 2017 Version 3.1 Page 247 of 430
+
+
+**Class ALC: Life-cycle support**
+
+
+**14.5.2** **Evaluation of sub-activity (ALC_DVS.2)**
+
+
+14.5.2.1 Objectives
+
+
+1146 The objective of this sub-activity is to determine whether the developer's
+security controls on the development environment are adequate to provide
+the confidentiality and integrity of the TOE design and implementation that
+is necessary to ensure that secure operation of the TOE is not compromised.
+Additionally, sufficiency of the measures as applied is intended be justified.
+
+
+14.5.2.2 Input
+
+
+1147 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the development security documentation.
+
+
+1148 In addition, the evaluator may need to examine other deliverables to
+determine that the security controls are well-defined and followed.
+Specifically, the evaluator may need to examine the developer's
+configuration management documentation (the input for the Evaluation of
+sub-activity (ALC_CMC.4) โProduction support and acceptance proceduresโ
+and the Evaluation of sub-activity (ALC_CMS.4) โProblem tracking CM
+coverageโ). Evidence that the procedures are being applied is also required.
+
+
+14.5.2.3 Action ALC_DVS.2.1E
+
+
+ALC_DVS.2.1C _**The development security documentation shall describe all the physical,**_
+_**procedural, personnel, and other security measures that are necessary to**_
+_**protect the confidentiality and integrity of the TOE design and**_
+_**implementation in its development environment.**_
+
+
+ALC_DVS.2-1 The evaluator _**shall examine**_ the development security documentation to
+determine that it details all security measures used in the development
+environment that are necessary to protect the confidentiality and integrity of
+the TOE design and implementation.
+
+
+1149 The evaluator determines what is necessary by first referring to the ST for
+any information that may assist in the determination of necessary protection.
+
+
+1150 If no explicit information is available from the ST the evaluator will need to
+make a determination of the necessary measures. In cases where the
+developer's measures are considered less than what is necessary, a clear
+justification should be provided for the assessment, based on a potential
+exploitable vulnerability.
+
+
+1151 The following types of security measures are considered by the evaluator
+when examining the documentation:
+
+
+Page 248 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+a) physical, for example physical access controls used to prevent
+unauthorised access to the TOE development environment (during
+normal working hours and at other times);
+
+
+b) procedural, for example covering:
+
+
+๏ญ granting of access to the development environment or to
+specific parts of the environment such as development
+machines
+
+
+๏ญ revocation of access rights when a person leaves the
+development team
+
+
+๏ญ transfer of protected material out of the development
+environment and between different development sites in
+accordance with defined acceptance procedures
+
+
+๏ญ admitting and escorting visitors to the development
+environment
+
+
+๏ญ roles and responsibilities in ensuring the continued
+application of security measures, and the detection of security
+breaches.
+
+
+c) personnel, for example any controls or checks made to establish the
+trustworthiness of new development staff;
+
+
+d) other security measures, for example the logical protections on any
+development machines.
+
+
+1152 The development security documentation should identify the locations at
+which development occurs, and describe the aspects of development
+performed, along with the security measures applied at each location and for
+transports between different locations. For example, development could
+occur at multiple facilities within a single building, multiple buildings at the
+same site, or at multiple sites. Transports of parts of the TOE or the
+unfinished TOE between different development sites are to be covered by the
+Development security (ALC_DVS), whereas the transport of the finished
+TOE to the consumer is dealt with in the Delivery (ALC_DEL).
+
+
+1153 Development includes the production of the TOE.
+
+
+ALC_DVS.2.2C _**The development security documentation shall justify that the security**_
+_**measures provide the necessary level of protection to maintain the**_
+_**confidentiality and integrity of the TOE.**_
+
+
+ALC_DVS.2-2 The evaluator _**shall examine**_ the development security documentation to
+determine that an appropriate justification is given why the security measures
+provide the necessary level of protection to maintain the confidentiality and
+integrity of the TOE.
+
+
+April 2017 Version 3.1 Page 249 of 430
+
+
+**Class ALC: Life-cycle support**
+
+
+1154 Since attacks on the TOE or its related information are assumed in different
+design and production stages, measures and procedures need to have an
+appropriate level necessary to prevent those attacks or to make them more
+difficult.
+
+
+1155 Since this level depends on the overall attack potential claimed for the TOE
+(cf. the Vulnerability analysis (AVA_VAN) component chosen), the
+development security documentation should justify the necessary level of
+protection to maintain the confidentiality and integrity of the TOE. This level
+has to be achieved by the security measures applied.
+
+
+1156 The concept of protection measures should be consistent, and the
+justification should include an analysis of how the measures are mutually
+supportive. All aspects of development and production on all the different
+sites with all roles involved up to delivery of the TOE should be analysed.
+
+
+1157 Justification may include an analysis of potential vulnerabilities taking the
+applied security measures into account.
+
+
+1158 There may be a convincing argument showing that e.g.
+
+
+๏ญ The technical measures and mechanisms of the developer's
+infrastructure are sufficient for keeping the appropriate security level
+(e.g. cryptographic mechanisms as well as physical protection
+mechanisms, properties of the CM system (cf. ALC_CMC.4-5));
+
+
+๏ญ The system containing the implementation representation of the TOE
+(including concerning guidance documents) provides effective
+protection against logical attacks e.g. by โTrojanโ code or viruses. It
+might be adequate, if the implementation representation is kept on an
+isolated system where only the software necessary to maintain it is
+installed and where no additional software is installed afterwards.
+
+
+๏ญ Data brought into this system need to be carefully considered to
+prevent the installation of hidden functionality onto the system. The
+effectiveness of these measures need to be tested, e.g. by
+independently trying to get access to the machine, install some
+additional executable (program, macro etc.) or get some information
+out of the machine using logical attacks.
+
+
+๏ญ The appropriate organisational (procedural and personal) measures
+are unconditionally enforced.
+
+
+ALC_DVS.2-3 The evaluator _**shall examine**_ the development confidentiality and integrity
+policies in order to determine the sufficiency of the security measures
+employed.
+
+
+1159 The evaluator should examine whether the following is included in the
+policies:
+
+
+Page 250 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+a) what information relating to the TOE development needs to be kept
+confidential, and which members of the development staff are
+allowed to access such material;
+
+
+b) what material must be protected from unauthorised modification in
+order to preserve the integrity of the TOE, and which members of the
+development staff are allowed to modify such material.
+
+
+1160 The evaluator should determine that these policies are described in the
+development security documentation, that the security measures employed
+are consistent with the policies, and that they are complete.
+
+
+1161 It should be noted that configuration management procedures will help
+protect the integrity of the TOE and the evaluator should avoid overlap with
+the work-units conducted for the CM capabilities (ALC_CMC). For example,
+the CM documentation may describe the security procedures necessary for
+controlling the roles or individuals who should have access to the
+development environment and who may modify the TOE.
+
+
+1162 Whereas the CM capabilities (ALC_CMC) requirements are fixed, those for
+the Development security (ALC_DVS), mandating only necessary measures,
+are dependent on the nature of the TOE, and on information that may be
+provided in the ST. For example, the ST may identify a security objective for
+the development environment that requires the TOE to be developed by staff
+that has security clearance. The evaluators would then determine that such a
+policy had been applied under this sub-activity.
+
+
+14.5.2.4 Action ALC_DVS.2.2E
+
+
+ALC_DVS.2-4 The evaluator _**shall examine**_ the development security documentation and
+associated evidence to determine that the security measures are being applied.
+
+
+1163 This work unit requires the evaluator to determine that the security measures
+described in the development security documentation are being followed,
+such that the integrity of the TOE and the confidentiality of associated
+documentation is being adequately protected. For example, this could be
+determined by examination of the documentary evidence provided.
+Documentary evidence should be supplemented by visiting the development
+environment. A visit to the development environment will allow the
+evaluator to:
+
+
+a) observe the application of security measures (e.g. physical measures);
+
+
+b) examine documentary evidence of application of procedures;
+
+
+c) interview development staff to check awareness of the development
+security policies and procedures, and their responsibilities.
+
+
+1164 A development site visit is a useful means of gaining confidence in the
+measures being used. Any decision not to make such a visit should be
+determined in consultation with the evaluation authority.
+
+
+April 2017 Version 3.1 Page 251 of 430
+
+
+**Class ALC: Life-cycle support**
+
+
+1165 For guidance on site visits see A.4, Site Visits.
+
+
+Page 252 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+## **14.6 Flaw remediation (ALC_FLR)**
+
+
+**14.6.1** **Evaluation of sub-activity (ALC_FLR.1)**
+
+
+14.6.1.1 Objectives
+
+
+1166 The objective of this sub-activity is to determine whether the developer has
+established flaw remediation procedures that describe the tracking of security
+flaws, the identification of corrective actions, and the distribution of
+corrective action information to TOE users.
+
+
+14.6.1.2 Input
+
+
+1167 The evaluation evidence for this sub-activity is:
+
+
+a) the flaw remediation procedures documentation.
+
+
+14.6.1.3 Action ALC_FLR.1.1E
+
+
+ALC_FLR.1.1C _**The flaw remediation procedures documentation shall describe the**_
+_**procedures used to track all reported security flaws in each release of the**_
+_**TOE.**_
+
+
+ALC_FLR.1-1 The evaluator _**shall examine**_ the flaw remediation procedures documentation
+to determine that it describes the procedures used to track all reported
+security flaws in each release of the TOE.
+
+
+1168 The procedures describe the actions that are taken by the developer from the
+time each suspected security flaw is reported to the time that it is resolved.
+This includes the flaw's entire time frame, from initial detection through
+ascertaining that the flaw is a security flaw, to resolution of the security flaw.
+
+
+1169 If a flaw is discovered not to be security-relevant, there is no need (for the
+purposes of the Flaw remediation (ALC_FLR) requirements) for the flaw
+remediation procedures to track it further; only that there be an explanation
+of why the flaw is not security-relevant.
+
+
+1170 While these requirements do not mandate that there be a publicised means
+for TOE users to report security flaws, they do mandate that all security
+flaws that are reported be tracked. That is, a reported security flaw cannot be
+ignored simply because it comes from outside the developer's organisation.
+
+
+ALC_FLR.1.2C _**The flaw remediation procedures shall require that a description of the**_
+_**nature and effect of each security flaw be provided, as well as the status of**_
+_**finding a correction to that flaw.**_
+
+
+ALC_FLR.1-2 The evaluator _**shall examine**_ the flaw remediation procedures to determine
+that the application of these procedures would produce a description of each
+security flaw in terms of its nature and effects.
+
+
+1171 The procedures identify the actions that are taken by the developer to
+describe the nature and effects of each security flaw in sufficient detail to be
+
+
+April 2017 Version 3.1 Page 253 of 430
+
+
+**Class ALC: Life-cycle support**
+
+
+able to reproduce it. The description of the nature of a security flaw
+addresses whether it is an error in the documentation, a flaw in the design of
+the TSF, a flaw in the implementation of the TSF, etc. The description of the
+security flaw's effects identifies the portions of the TSF that are affected and
+how those portions are affected. For example, a security flaw in the
+implementation might be found that affects the identification and
+authentication enforced by the TSF by permitting authentication with the
+password โBACK DOORโ.
+
+
+ALC_FLR.1-3 The evaluator _**shall examine**_ the flaw remediation procedures to determine
+that the application of these procedures would identify the status of finding a
+correction to each security flaw.
+
+
+1172 The flaw remediation procedures identify the different stages of security
+flaws. This differentiation includes at least: suspected security flaws that
+have been reported, suspected security flaws that have been confirmed to be
+security flaws, and security flaws whose solutions have been implemented. It
+is permissible that additional stages (e.g. flaws that have been reported but
+not yet investigated, flaws that are under investigation, security flaws for
+which a solution has been found but not yet implemented) be included.
+
+
+ALC_FLR.1.3C _**The flaw remediation procedures shall require that corrective actions be**_
+_**identified for each of the security flaws.**_
+
+
+ALC_FLR.1-4 The evaluator _**shall check**_ the flaw remediation procedures to determine that
+the application of these procedures would identify the corrective action for
+each security flaw.
+
+
+1173 _Corrective action_ may consist of a repair to the hardware, firmware, or
+software portions of the TOE, a modification of TOE guidance, or both.
+Corrective action that constitutes modifications to TOE guidance (e.g. details
+of procedural measures to be taken to obviate the security flaw) includes
+both those measures serving as only an interim solution (until the repair is
+issued) as well as those serving as a permanent solution (where it is
+determined that the procedural measure is the best solution).
+
+
+1174 If the source of the security flaw is a documentation error, the corrective
+action consists of an update of the affected TOE guidance. If the corrective
+action is a procedural measure, this measure will include an update made to
+the affected TOE guidance to reflect these corrective procedures.
+
+
+ALC_FLR.1.4C _**The flaw remediation procedures documentation shall describe the**_
+_**methods used to provide flaw information, corrections and guidance on**_
+_**corrective actions to TOE users.**_
+
+
+ALC_FLR.1-5 The evaluator _**shall examine**_ the flaw remediation procedures documentation
+to determine that it describes a means of providing the TOE users with the
+necessary information on each security flaw.
+
+
+1175 The _necessary information_ about each security flaw consists of its
+description (not necessarily at the same level of detail as that provided as part
+
+
+Page 254 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+of work unit ALC_FLR.1-2), the prescribed corrective action, and any
+associated guidance on implementing the correction.
+
+
+1176 TOE users may be provided with such information, correction, and
+documentation updates in any of several ways, such as their posting to a
+website, their being sent to TOE users, or arrangements made for the
+developer to install the correction. In cases where the means of providing this
+information requires action to be initiated by the TOE user, the evaluator
+examines any TOE guidance to ensure that it contains instructions for
+retrieving the information.
+
+
+1177 The only metric for assessing the adequacy of the method used for providing
+the information, corrections and guidance is that there be a reasonable
+expectation that TOE users can obtain or receive it. For example, consider
+the method of dissemination where the requisite data is posted to a website
+for one month, and the TOE users know that this will happen and when this
+will happen. This may not be especially reasonable or effective (as, say, a
+permanent posting to the website), yet it is feasible that the TOE user could
+obtain the necessary information. On the other hand, if the information were
+posted to the website for only one hour, yet TOE users had no way of
+knowing this or when it would be posted, it is infeasible that they would ever
+get the necessary information.
+
+
+**14.6.2** **Evaluation of sub-activity (ALC_FLR.2)**
+
+
+14.6.2.1 Objectives
+
+
+1178 The objective of this sub-activity is to determine whether the developer has
+established flaw remediation procedures that describe the tracking of security
+flaws, the identification of corrective actions, and the distribution of
+corrective action information to TOE users. Additionally, this sub-activity
+determines whether the developer's procedures provide for the corrections of
+security flaws, for the receipt of flaw reports from TOE users, and for
+assurance that the corrections introduce no new security flaws.
+
+
+1179 In order for the developer to be able to act appropriately upon security flaw
+reports from TOE users, TOE users need to understand how to submit
+security flaw reports to the developer, and developers need to know how to
+receive these reports. Flaw remediation guidance addressed to the TOE user
+ensures that TOE users are aware of how to communicate with the
+developer; flaw remediation procedures describe the developer's role is such
+communication
+
+
+14.6.2.2 Input
+
+
+1180 The evaluation evidence for this sub-activity is:
+
+
+a) the flaw remediation procedures documentation;
+
+
+b) flaw remediation guidance documentation.
+
+
+April 2017 Version 3.1 Page 255 of 430
+
+
+**Class ALC: Life-cycle support**
+
+
+14.6.2.3 Action ALC_FLR.2.1E
+
+
+ALC_FLR.2.1C _**The flaw remediation procedures documentation shall describe the**_
+_**procedures used to track all reported security flaws in each release of the**_
+_**TOE.**_
+
+
+ALC_FLR.2-1 The evaluator _**shall examine**_ the flaw remediation procedures documentation
+to determine that it describes the procedures used to track all reported
+security flaws in each release of the TOE.
+
+
+1181 The procedures describe the actions that are taken by the developer from the
+time each suspected security flaw is reported to the time that it is resolved.
+This includes the flaw's entire time frame, from initial detection through
+ascertaining that the flaw is a security flaw, to resolution of the security flaw.
+
+
+1182 If a flaw is discovered not to be security-relevant, there is no need (for the
+purposes of the Flaw remediation (ALC_FLR) requirements) for the flaw
+remediation procedures to track it further; only that there be an explanation
+of why the flaw is not security-relevant.
+
+
+ALC_FLR.2.2C _**The flaw remediation procedures shall require that a description of the**_
+_**nature and effect of each security flaw be provided, as well as the status of**_
+_**finding a correction to that flaw.**_
+
+
+ALC_FLR.2-2 The evaluator _**shall examine**_ the flaw remediation procedures to determine
+that the application of these procedures would produce a description of each
+security flaw in terms of its nature and effects.
+
+
+1183 The procedures identify the actions that are taken by the developer to
+describe the nature and effects of each security flaw in sufficient detail to be
+able to reproduce it. The description of the nature of a security flaw
+addresses whether it is an error in the documentation, a flaw in the design of
+the TSF, a flaw in the implementation of the TSF, etc. The description of the
+security flaw's effects identifies the portions of the TSF that are affected and
+how those portions are affected. For example, a security flaw in the
+implementation might be found that affects the identification and
+authentication enforced by the TSF by permitting authentication with the
+password โBACKDOORโ.
+
+
+ALC_FLR.2-3 The evaluator _**shall examine**_ the flaw remediation procedures to determine
+that the application of these procedures would identify the status of finding a
+correction to each security flaw.
+
+
+1184 The flaw remediation procedures identify the different stages of security
+flaws. This differentiation includes at least: suspected security flaws that
+have been reported, suspected security flaws that have been confirmed to be
+security flaws, and security flaws whose solutions have been implemented. It
+is permissible that additional stages (e.g. flaws that have been reported but
+not yet investigated, flaws that are under investigation, security flaws for
+which a solution has been found but not yet implemented) be included.
+
+
+Page 256 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+ALC_FLR.2.3C _**The flaw remediation procedures shall require that corrective actions be**_
+_**identified for each of the security flaws.**_
+
+
+ALC_FLR.2-4 The evaluator _**shall check**_ the flaw remediation procedures to determine that
+the application of these procedures would identify the corrective action for
+each security flaw.
+
+
+1185 _Corrective action_ may consist of a repair to the hardware, firmware, or
+software portions of the TOE, a modification of TOE guidance, or both.
+Corrective action that constitutes modifications to TOE guidance (e.g. details
+of procedural measures to be taken to obviate the security flaw) includes
+both those measures serving as only an interim solution (until the repair is
+issued) as well as those serving as a permanent solution (where it is
+determined that the procedural measure is the best solution).
+
+
+1186 If the source of the security flaw is a documentation error, the corrective
+action consists of an update of the affected TOE guidance. If the corrective
+action is a procedural measure, this measure will include an update made to
+the affected TOE guidance to reflect these corrective procedures.
+
+
+ALC_FLR.2.4C _**The flaw remediation procedures documentation shall describe the**_
+_**methods used to provide flaw information, corrections and guidance on**_
+_**corrective actions to TOE users.**_
+
+
+ALC_FLR.2-5 The evaluator _**shall examine**_ the flaw remediation procedures documentation
+to determine that it describes a means of providing the TOE users with the
+necessary information on each security flaw.
+
+
+1187 _The necessary information_ about each security flaw consists of its
+description (not necessarily at the same level of detail as that provided as part
+of work unit ALC_FLR.2-2), the prescribed corrective action, and any
+associated guidance on implementing the correction.
+
+
+1188 TOE users may be provided with such information, correction, and
+documentation updates in any of several ways, such as their posting to a
+website, their being sent to TOE users, or arrangements made for the
+developer to install the correction. In cases where the means of providing this
+information requires action to be initiated by the TOE user, the evaluator
+examines any TOE guidance to ensure that it contains instructions for
+retrieving the information.
+
+
+1189 The only metric for assessing the adequacy of the method used for providing
+the information, corrections and guidance is that there be a reasonable
+expectation that TOE users can obtain or receive it. For example, consider
+the method of dissemination where the requisite data is posted to a website
+for one month, and the TOE users know that this will happen and when this
+will happen. This may not be especially reasonable or effective (as, say, a
+permanent posting to the website), yet it is feasible that the TOE user could
+obtain the necessary information. On the other hand, if the information were
+posted to the website for only one hour, yet TOE users had no way of
+
+
+April 2017 Version 3.1 Page 257 of 430
+
+
+**Class ALC: Life-cycle support**
+
+
+knowing this or when it would be posted, it is infeasible that they would ever
+get the necessary information.
+
+
+ALC_FLR.2.5C _**The flaw remediation procedures shall describe a means by which the**_
+_**developer receives from TOE users reports and enquiries of suspected**_
+_**security flaws in the TOE.**_
+
+
+ALC_FLR.2-6 The evaluator _**shall examine**_ the flaw remediation procedures to determine
+that they describe procedures for the developer to accept reports of security
+flaws or requests for corrections to such flaws.
+
+
+1190 The procedures ensure that TOE users have a means by which they can
+communicate with the TOE developer. By having a means of contact with
+the developer, the user can report security flaws, enquire about the status of
+security flaws, or request corrections to flaws. This means of contact may be
+part of a more general contact facility for reporting non-security related
+problems.
+
+
+1191 The use of these procedures is not restricted to TOE users; however, only the
+TOE users are actively supplied with the details of these procedures. Others
+who might have access to or familiarity with the TOE can use the same
+procedures to submit reports to the developer, who is then expected to
+process them. Any means of submitting reports to the developer, other than
+those identified by the developer, are beyond the scope of this work unit;
+reports generated by other means need not be addressed.
+
+
+ALC_FLR.2.6C _**The procedures for processing reported security flaws shall ensure that any**_
+_**reported flaws are remediated and the remediation procedures issued to**_
+_**TOE users.**_
+
+
+ALC_FLR.2-7 The evaluator _**shall examine**_ the flaw remediation procedures to determine
+that the application of these procedures would help to ensure every reported
+flaw is corrected.
+
+
+1192 The flaw remediation procedures cover not only those security flaws
+discovered and reported by developer personnel, but also those reported by
+TOE users. The procedures are sufficiently detailed so that they describe
+how it is ensured that each reported security flaw is corrected. The
+procedures contain reasonable steps that show progress leading to the
+eventual, inevitable resolution.
+
+
+1193 The procedures describe the process that is taken from the point at which the
+suspected security flaw is determined to be a security flaw to the point at
+which it is resolved.
+
+
+ALC_FLR.2-8 The evaluator _**shall examine**_ the flaw remediation procedures to determine
+that the application of these procedures would help to ensure that the TOE
+users are issued remediation procedures for each security flaw.
+
+
+1194 The procedures describe the process that is taken from the point at which a
+security flaw is resolved to the point at which the remediation procedures are
+
+
+Page 258 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+provided. The procedures for delivering corrective actions should be
+consistent with the security objectives; they need not necessarily be identical
+to the procedures used for delivering the TOE, as documented to meet
+ALC_DEL, if included in the assurance requirements. For example, if the
+hardware portion of a TOE were originally delivered by bonded courier,
+updates to hardware resulting from flaw remediation would likewise be
+expected to be distributed by bonded courier. Updates unrelated to flaw
+remediation would follow the procedures set forth in the documentation
+meeting the Delivery (ALC_DEL) requirements.
+
+
+ALC_FLR.2.7C _**The procedures for processing reported security flaws shall provide**_
+_**safeguards that any corrections to these security flaws do not introduce**_
+_**any new flaws.**_
+
+
+ALC_FLR.2-9 The evaluator _**shall examine**_ the flaw remediation procedures to determine
+that the application of these procedures would result in safeguards that the
+potential correction contains no adverse effects.
+
+
+1195 Through analysis, testing, or a combination of the two, the developer may
+reduce the likelihood that adverse effects will be introduced when a security
+flaw is corrected. The evaluator assesses whether the procedures provide
+detail in how the necessary mix of analysis and testing actions is to be
+determined for a given correction.
+
+
+1196 The evaluator also determines that, for instances where the source of the
+security flaw is a documentation problem, the procedures include the means
+of safeguarding against the introduction of contradictions with other
+documentation.
+
+
+ALC_FLR.2.8C _**The flaw remediation guidance shall describe a means by which TOE**_
+_**users report to the developer any suspected security flaws in the TOE.**_
+
+
+ALC_FLR.2-10 The evaluator _**shall examine**_ the flaw remediation guidance to determine that
+the application of these procedures would result in a means for the TOE user
+to provide reports of suspected security flaws or requests for corrections to
+such flaws.
+
+
+1197 The guidance ensures that TOE users have a means by which they can
+communicate with the TOE developer. By having a means of contact with
+the developer, the user can report security flaws, enquire about the status of
+security flaws, or request corrections to flaws.
+
+
+**14.6.3** **Evaluation of sub-activity (ALC_FLR.3)**
+
+
+14.6.3.1 Objectives
+
+
+1198 The objective of this sub-activity is to determine whether the developer has
+established flaw remediation procedures that describe the tracking of security
+flaws, the identification of corrective actions, and the distribution of
+corrective action information to TOE users. Additionally, this sub-activity
+determines whether the developer's procedures provide for the corrections of
+
+
+April 2017 Version 3.1 Page 259 of 430
+
+
+**Class ALC: Life-cycle support**
+
+
+security flaws, for the receipt of flaw reports from TOE users, for assurance
+that the corrections introduce no new security flaws, for the establishment of
+a point of contact for each TOE user, and for the timely issue of corrective
+actions to TOE users.
+
+
+1199 In order for the developer to be able to act appropriately upon security flaw
+reports from TOE users, TOE users need to understand how to submit
+security flaw reports to the developer, and developers need to know how to
+receive these reports. Flaw remediation guidance addressed to the TOE user
+ensures that TOE users are aware of how to communicate with the
+developer; flaw remediation procedures describe the developer's role is such
+communication.
+
+
+14.6.3.2 Input
+
+
+1200 The evaluation evidence for this sub-activity is:
+
+
+a) the flaw remediation procedures documentation;
+
+
+b) flaw remediation guidance documentation.
+
+
+14.6.3.3 Action ALC_FLR.3.1E
+
+
+ALC_FLR.3.1C _**The flaw remediation procedures documentation shall describe the**_
+_**procedures used to track all reported security flaws in each release of the**_
+_**TOE.**_
+
+
+ALC_FLR.3-1 The evaluator _**shall examine**_ the flaw remediation procedures documentation
+to determine that it describes the procedures used to track all reported
+security flaws in each release of the TOE.
+
+
+1201 The procedures describe the actions that are taken by the developer from the
+time each suspected security flaw is reported to the time that it is resolved.
+This includes the flaw's entire time frame, from initial detection through
+ascertaining that the flaw is a security flaw, to resolution of the security flaw.
+
+
+1202 If a flaw is discovered not to be security-relevant, there is no need (for the
+purposes of the Flaw remediation (ALC_FLR) requirements) for the flaw
+remediation procedures to track it further; only that there be an explanation
+of why the flaw is not security-relevant.
+
+
+ALC_FLR.3.2C _**The flaw remediation procedures shall require that a description of the**_
+_**nature and effect of each security flaw be provided, as well as the status of**_
+_**finding a correction to that flaw.**_
+
+
+ALC_FLR.3-2 The evaluator _**shall examine**_ the flaw remediation procedures to determine
+that the application of these procedures would produce a description of each
+security flaw in terms of its nature and effects.
+
+
+1203 The procedures identify the actions that are taken by the developer to
+describe the nature and effects of each security flaw in sufficient detail to be
+able to reproduce it. The description of the nature of a security flaw
+
+
+Page 260 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+addresses whether it is an error in the documentation, a flaw in the design of
+the TSF, a flaw in the implementation of the TSF, etc. The description of the
+security flaw's effects identifies the portions of the TSF that are affected and
+how those portions are affected. For example, a security flaw in the
+implementation might be found that affects the identification and
+authentication enforced by the TSF by permitting authentication with the
+password โBACKDOORโ.
+
+
+ALC_FLR.3-3 The evaluator _**shall examine**_ the flaw remediation procedures to determine
+that the application of these procedures would identify the status of finding a
+correction to each security flaw.
+
+
+1204 The flaw remediation procedures identify the different stages of security
+flaws. This differentiation includes at least: suspected security flaws that
+have been reported, suspected security flaws that have been confirmed to be
+security flaws, and security flaws whose solutions have been implemented. It
+is permissible that additional stages (e.g. flaws that have been reported but
+not yet investigated, flaws that are under investigation, security flaws for
+which a solution has been found but not yet implemented) be included.
+
+
+ALC_FLR.3.3C _**The flaw remediation procedures shall require that corrective actions be**_
+_**identified for each of the security flaws.**_
+
+
+ALC_FLR.3-4 The evaluator _**shall check**_ the flaw remediation procedures to determine that
+the application of these procedures would identify the corrective action for
+each security flaw.
+
+
+1205 _Corrective action_ may consist of a repair to the hardware, firmware, or
+software portions of the TOE, a modification of TOE guidance, or both.
+Corrective action that constitutes modifications to TOE guidance (e.g. details
+of procedural measures to be taken to obviate the security flaw) includes
+both those measures serving as only an interim solution (until the repair is
+issued) as well as those serving as a permanent solution (where it is
+determined that the procedural measure is the best solution).
+
+
+1206 If the source of the security flaw is a documentation error, the corrective
+action consists of an update of the affected TOE guidance. If the corrective
+action is a procedural measure, this measure will include an update made to
+the affected TOE guidance to reflect these corrective procedures.
+
+
+ALC_FLR.3.4C _**The flaw remediation procedures documentation shall describe the**_
+_**methods used to provide flaw information, corrections and guidance on**_
+_**corrective actions to TOE users.**_
+
+
+ALC_FLR.3-5 The evaluator _**shall examine**_ the flaw remediation procedures documentation
+to determine that it describes a means of providing the TOE users with the
+necessary information on each security flaw.
+
+
+1207 _The necessary information_ about each security flaw consists of its
+description (not necessarily at the same level of detail as that provided as part
+
+
+April 2017 Version 3.1 Page 261 of 430
+
+
+**Class ALC: Life-cycle support**
+
+
+of work unit ALC_FLR.3-2), the prescribed corrective action, and any
+associated guidance on implementing the correction.
+
+
+1208 TOE users may be provided with such information, correction, and
+documentation updates in any of several ways, such as their posting to a
+website, their being sent to TOE users, or arrangements made for the
+developer to install the correction. In cases where the means of providing this
+information requires action to be initiated by the TOE user, the evaluator
+examines any TOE guidance to ensure that it contains instructions for
+retrieving the information.
+
+
+1209 The only metric for assessing the adequacy of the method used for providing
+the information, corrections and guidance is that there be a reasonable
+expectation that TOE users can obtain or receive it. For example, consider
+the method of dissemination where the requisite data is posted to a website
+for one month, and the TOE users know that this will happen and when this
+will happen. This may not be especially reasonable or effective (as, say, a
+permanent posting to the website), yet it is feasible that the TOE user could
+obtain the necessary information. On the other hand, if the information were
+posted to the website for only one hour, yet TOE users had no way of
+knowing this or when it would be posted, it is infeasible that they would ever
+get the necessary information.
+
+
+1210 For TOE users who register with the developer (see work unit ALC_FLR.312), the passive availability of this information is not sufficient. Developers
+must actively send the information (or a notification of its availability) to
+registered TOE users.
+
+
+ALC_FLR.3.5C _**The flaw remediation procedures shall describe a means by which the**_
+_**developer receives from TOE users reports and enquiries of suspected**_
+_**security flaws in the TOE.**_
+
+
+ALC_FLR.3-6 The evaluator _**shall examine**_ the flaw remediation procedures to determine
+that the application of these procedures would result in a means for the
+developer to receive from TOE user reports of suspected security flaws or
+requests for corrections to such flaws.
+
+
+1211 The procedures ensure that TOE users have a means by which they can
+communicate with the TOE developer. By having a means of contact with
+the developer, the user can report security flaws, enquire about the status of
+security flaws, or request corrections to flaws. This means of contact may be
+part of a more general contact facility for reporting non-security related
+problems.
+
+
+1212 The use of these procedures is not restricted to TOE users; however, only the
+TOE users are actively supplied with the details of these procedures. Others
+who might have access to or familiarity with the TOE can use the same
+procedures to submit reports to the developer, who is then expected to
+process them. Any means of submitting reports to the developer, other than
+those identified by the developer, are beyond the scope of this work unit;
+reports generated by other means need not be addressed.
+
+
+Page 262 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+ALC_FLR.3.6C _**The flaw remediation procedures shall include a procedure requiring**_
+_**timely response and the automatic distribution of security flaw reports and**_
+_**the associated corrections to registered users who might be affected by the**_
+_**security flaw.**_
+
+
+ALC_FLR.3-7 The evaluator _**shall examine**_ the flaw remediation procedures to determine
+that the application of these procedures would result in a timely means of
+providing the registered TOE users who might be affected with reports about,
+and associated corrections to, each security flaw.
+
+
+1213 The issue of timeliness applies to the issuance of both security flaw reports
+and the associated corrections. However, these need not be issued at the
+same time. It is recognised that flaw reports should be generated and issued
+as soon as an interim solution is found, even if that solution is as drastic as
+turn off the TOE. Likewise, when a more permanent (and less drastic)
+solution is found, it should be issued without undue delay.
+
+
+1214 It is unnecessary to restrict the recipients of the reports and associated
+corrections to only those TOE users who might be affected by the security
+flaw; it is permissible that all TOE users be given such reports and
+corrections for all security flaws, provided such is done in a timely manner.
+
+
+ALC_FLR.3-8 The evaluator _**shall examine**_ the flaw remediation procedures to determine
+that the application of these procedures would result in automatic distribution
+of the reports and associated corrections to the registered TOE users who
+might be affected.
+
+
+1215 _Automatic distribution_ does not mean that human interaction with the
+distribution method is not permitted. In fact, the distribution method could
+consist entirely of manual procedures, perhaps through a closely monitored
+procedure with prescribed escalation upon the lack of issue of reports or
+corrections.
+
+
+1216 It is unnecessary to restrict the recipients of the reports and associated
+corrections to only those TOE users who might be affected by the security
+flaw; it is permissible that all TOE users be given such reports and
+corrections for all security flaws, provided such is done automatically.
+
+
+ALC_FLR.3.7C _**The procedures for processing reported security flaws shall ensure that any**_
+_**reported flaws are remediated and the remediation procedures issued to**_
+_**TOE users.**_
+
+
+ALC_FLR.3-9 The evaluator _**shall examine**_ the flaw remediation procedures to determine
+that the application of these procedures would help to ensure that every
+reported flaw is corrected.
+
+
+1217 The flaw remediation procedures cover not only those security flaws
+discovered and reported by developer personnel, but also those reported by
+TOE users. The procedures are sufficiently detailed so that they describe
+how it is ensured that each reported security flaw is remediated. The
+
+
+April 2017 Version 3.1 Page 263 of 430
+
+
+**Class ALC: Life-cycle support**
+
+
+procedures contain reasonable steps that show progress leading to the
+eventual, inevitable resolution.
+
+
+1218 The procedures describe the process that is taken from the point at which the
+suspected security flaw is determined to be a security flaw to the point at
+which it is resolved.
+
+
+ALC_FLR.3-10 The evaluator _**shall examine**_ the flaw remediation procedures to determine
+that the application of these procedures would help to ensure that the TOE
+users are issued remediation procedures for each security flaw.
+
+
+1219 The procedures describe the process that is taken from the point at which a
+security flaw is resolved to the point at which the remediation procedures are
+provided. The procedures for delivering remediation procedures should be
+consistent with the security objectives; they need not necessarily be identical
+to the procedures used for delivering the TOE, as documented to meet
+Delivery (ALC_DEL), if included in the assurance requirements. For
+example, if the hardware portion of a TOE were originally delivered by
+bonded courier, updates to hardware resulting from flaw remediation would
+likewise be expected to be distributed by bonded courier. Updates unrelated
+to flaw remediation would follow the procedures set forth in the
+documentation meeting the Delivery (ALC_DEL) requirements.
+
+
+ALC_FLR.3.8C _**The procedures for processing reported security flaws shall provide**_
+_**safeguards that any corrections to these security flaws do not introduce**_
+_**any new flaws.**_
+
+
+ALC_FLR.3-11 The evaluator _**shall examine**_ the flaw remediation procedures to determine
+that the application of these procedures would result in safeguards that the
+potential correction contains no adverse effects.
+
+
+1220 Through analysis, testing, or a combination of the two, the developer may
+reduce the likelihood that adverse effects will be introduced when a security
+flaw is corrected. The evaluator assesses whether the procedures provide
+detail in how the necessary mix of analysis and testing actions is to be
+determined for a given correction.
+
+
+1221 The evaluator also determines that, for instances where the source of the
+security flaw is a documentation problem, the procedures include the means
+of safeguarding against the introduction of contradictions with other
+documentation.
+
+
+ALC_FLR.3.9C _**The flaw remediation guidance shall describe a means by which TOE**_
+_**users report to the developer any suspected security flaws in the TOE.**_
+
+
+ALC_FLR.3-12 The evaluator _**shall examine**_ the flaw remediation guidance to determine that
+the application of these procedures would result in a means for the TOE user
+to provide reports of suspected security flaws or requests for corrections to
+such flaws.
+
+
+Page 264 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+1222 The guidance ensures that TOE users have a means by which they can
+communicate with the TOE developer. By having a means of contact with
+the developer, the user can report security flaws, enquire about the status of
+security flaws, or request corrections to flaws.
+
+
+ALC_FLR.3.10C _**The flaw remediation guidance shall describe a means by which TOE**_
+_**users may register with the developer, to be eligible to receive security flaw**_
+_**reports and corrections.**_
+
+
+ALC_FLR.3-13 The evaluator _**shall examine**_ the flaw remediation guidance to determine that
+it describes a means of enabling the TOE users to register with the developer.
+
+
+1223 _Enabling the TOE users to register with the developer_ simply means having
+a way for each TOE user to provide the developer with a point of contact;
+this point of contact is to be used to provide the TOE user with information
+related to security flaws that might affect that TOE user, along with any
+corrections to the security flaw. Registering the TOE user may be
+accomplished as part of the standard procedures that TOE users undergo to
+identify themselves to the developer, for the purposes of registering a
+software licence, or for obtaining update and other useful information.
+
+
+1224 There need not be one registered TOE user per installation of the TOE; it
+would be sufficient if there were one registered TOE user for an organisation.
+For example, a corporate TOE user might have a centralised acquisition
+office for all of its sites. In this case, the acquisition office would be a
+sufficient point of contact for all of that TOE user's sites, so that all of the
+TOE user's installations of the TOE have a registered point of contact.
+
+
+1225 In either case, it must be possible to associate each TOE that is delivered
+with an organisation in order to ensure that there is a registered user for each
+TOE. For organisations that have many different addresses, this assures that
+there will be no user who is erroneously presumed to be covered by a
+registered TOE user.
+
+
+1226 It should be noted that TOE users need not register; they must only be
+provided with a means of doing so. However, users who choose to register
+must be directly sent the information (or a notification of its availability).
+
+
+ALC_FLR.3.11C _**The flaw remediation guidance shall identify the specific points of contact**_
+_**for all reports and enquiries about security issues involving the TOE.**_
+
+
+ALC_FLR.3-14 The evaluator _**shall examine**_ the flaw remediation guidance to determine that
+it identifies specific points of contact for user reports and enquiries about
+security issues involving the TOE.
+
+
+1227 The guidance includes a means whereby registered TOE users can interact
+with the developer to report discovered security flaws in the TOE or to make
+enquiries regarding discovered security flaws in the TOE.
+
+
+April 2017 Version 3.1 Page 265 of 430
+
+
+**Class ALC: Life-cycle support**
+
+## **14.7 Life-cycle definition (ALC_LCD)**
+
+
+**14.7.1** **Evaluation of sub-activity (ALC_LCD.1)**
+
+
+14.7.1.1 Objectives
+
+
+1228 The objective of this sub-activity is to determine whether the developer has
+used a documented model of the TOE life-cycle.
+
+
+14.7.1.2 Input
+
+
+1229 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the life-cycle definition documentation.
+
+
+14.7.1.3 Action ALC_LCD.1.1E
+
+
+ALC_LCD.1.1C _**The life-cycle definition documentation shall describe the model used to**_
+_**develop and maintain the TOE.**_
+
+
+ALC_LCD.1-1 The evaluator _**shall examine**_ the documented description of the life-cycle
+model used to determine that it covers the development and maintenance
+process.
+
+
+1230 The description of the life-cycle model should include:
+
+
+a) information on the life-cycle phases of the TOE and the boundaries
+between the subsequent phases;
+
+
+b) information on the procedures, tools and techniques used by the
+developer (e.g. for design, coding, testing, bug-fixing);
+
+
+c) overall management structure governing the application of the
+procedures (e.g. an identification and description of the individual
+responsibilities for each of the procedures required by the
+development and maintenance process covered by the life-cycle
+model);
+
+
+d) information on which parts of the TOE are delivered by
+subcontractors, if subcontractors are involved.
+
+
+1231 Evaluation of sub-activity (ALC_LCD.1) does not require the model used to
+conform to any standard life-cycle model.
+
+
+ALC_LCD.1.2C _**The life-cycle model shall provide for the necessary control over the**_
+_**development and maintenance of the TOE.**_
+
+
+ALC_LCD.1-2 The evaluator _**shall examine**_ the life-cycle model to determine that use of the
+procedures, tools and techniques described by the life-cycle model will make
+
+
+Page 266 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+the necessary positive contribution to the development and maintenance of
+the TOE.
+
+
+1232 The information provided in the life-cycle model gives the evaluator
+assurance that the development and maintenance procedures adopted would
+minimise the likelihood of security flaws. For example, if the life-cycle
+model described the review process, but did not make provision for
+recording changes to components, then the evaluator may be less confident
+that errors will not be introduced into the TOE. The evaluator may gain
+further assurance by comparing the description of the model against an
+understanding of the development process gleaned from performing other
+evaluator actions relating to the TOE development (e.g. those covered under
+the CM capabilities (ALC_CMC)). Identified deficiencies in the life-cycle
+model will be of concern if they might reasonably be expected to give rise to
+the introduction of flaws into the TOE, either accidentally or deliberately.
+
+
+1233 The CC does not mandate any particular development approach, and each
+should be judged on merit. For example, spiral, rapid-prototyping and
+waterfall approaches to design can all be used to produce a quality TOE if
+applied in a controlled environment.
+
+
+**14.7.2** **Evaluation of sub-activity (ALC_LCD.2)**
+
+
+14.7.2.1 Objectives
+
+
+1234 The objective of this sub-activity is to determine whether the developer has
+used a documented and measurable model of the TOE life-cycle.
+
+
+14.7.2.2 Input
+
+
+1235 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the life-cycle definition documentation;
+
+
+c) information about the standard used;
+
+
+d) the life-cycle output documentation.
+
+
+14.7.2.3 Action ALC_LCD.2.1E
+
+
+ALC_LCD.2.1C _**The life-cycle definition documentation shall describe the model used to**_
+_**develop and maintain the TOE, including the details of its arithmetic**_
+_**parameters and/or metrics used to measure the quality of the TOE and/or**_
+_**its development.**_
+
+
+ALC_LCD.2-1 The evaluator _**shall examine**_ the documented description of the life-cycle
+model used to determine that it covers the development and maintenance
+process, including the details of its arithmetic parameters and/or metrics used
+to measure the TOE development.
+
+
+April 2017 Version 3.1 Page 267 of 430
+
+
+**Class ALC: Life-cycle support**
+
+
+1236 The description of the life-cycle model includes:
+
+
+a) information on the life-cycle phases of the TOE and the boundaries
+between the subsequent phases;
+
+
+b) information on the procedures, tools and techniques used by the
+developer (e.g. for design, coding, testing, bug-fixing);
+
+
+c) overall management structure governing the application of the
+procedures (e.g. an identification and description of the individual
+responsibilities for each of the procedures required by the
+development and maintenance process covered by the life-cycle
+model);
+
+
+d) information on which parts of the TOE are delivered by
+subcontractors, if subcontractors are involved;
+
+
+e) information on the parameters/metrics that are used to measure the
+TOE development. Metrics standards typically include guides for
+measuring and producing reliable products and cover the aspects
+reliability, quality, performance, complexity and cost. For the
+evaluation all those metrics are of relevance, which are used to
+increase quality by decreasing the probability of faults and thereby in
+turn increase assurance in the security of the TOE.
+
+
+ALC_LCD.2.2C _**The life-cycle model shall provide for the necessary control over the**_
+_**development and maintenance of the TOE.**_
+
+
+ALC_LCD.2-2 The evaluator _**shall examine**_ the life-cycle model to determine that use of the
+procedures, tools and techniques described by the life-cycle model will make
+the necessary positive contribution to the development and maintenance of
+the TOE.
+
+
+1237 The information provided in the life-cycle model gives the evaluator
+assurance that the development and maintenance procedures adopted would
+minimise the likelihood of security flaws. For example, if the life-cycle
+model described the review process, but did not make provision for
+recording changes to components, then the evaluator may be less confident
+that errors will not be introduced into the TOE. The evaluator may gain
+further assurance by comparing the description of the model against an
+understanding of the development process gleaned from performing other
+evaluator actions relating to the TOE development (e.g. those covered under
+the CM capabilities (ALC_CMC)). Identified deficiencies in the life-cycle
+model will be of concern if they might reasonably be expected to give rise to
+the introduction of flaws into the TOE, either accidentally or deliberately.
+
+
+1238 The CC does not mandate any particular development approach, and each
+should be judged on merit. For example, spiral, rapid-prototyping and
+waterfall approaches to design can all be used to produce a quality TOE if
+applied in a controlled environment.
+
+
+Page 268 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+1239 For the metrics/measurements used in the life-cycle model, evidence has to
+be provided that shows how those metrics/measurements usefully contribute
+to the minimisation of the likelihood of flaws. This can be viewed as the
+overall goal for measurement in an ALC context. As a consequence the
+metrics/measurements have to be selected based on their capability to
+achieve that overall goal or contribute to that. In the first place a
+metric/measure is suitable with respect to ALC if a correlation between the
+metric/measure and the number of flaws can be stated with a certain degree
+of reliability. But also a metric/measure useful for management purposes as
+for planning and monitoring the TOE development are helpful since badly
+managed projects are endangered to produce bad quality and to introduce
+flaws.
+
+
+1240 It may be possible to use metrics for quality improvement, for which this use
+is not obvious. For example a metric to estimate the expected cost of a
+product development may help quality, if the developer can show that this is
+used to provide an adequate budget for development projects and that this
+helps to avoid quality problems arising from resource shortages.
+
+
+1241 It is not required that every single step in the life cycle of the TOE is
+measurable. However the evaluator should see from the description of the
+measures and procedures that the metrics are appropriate to control the
+overall quality of the TOE and to minimise possible security flaws by this.
+
+
+ALC_LCD.2.3C _**The life-cycle output documentation shall provide the results of the**_
+_**measurements of the TOE development using the measurable life-cycle**_
+_**model.**_
+
+
+ALC_LCD.2-3 The evaluator _**shall examine**_ the life-cycle output documentation to
+determine that it provides the results of the measurements of the TOE
+development using the measurable life-cycle model.
+
+
+1242 The results of the measurements and the life-cycle progress of the TOE
+should be in accordance with the life-cycle model.
+
+
+1243 The output documentation not only includes numeric values of the metrics
+but also documents actions taken as a result of the measurements and in
+accordance with the model. For example there may be a requirement that a
+certain design phase needs to be repeated, if some error rates measured
+during testing are outside of a defined threshold. In this case the
+documentation should show that such action was taken, if indeed the
+thresholds were not met.
+
+
+1244 If the evaluation is conducted in parallel with the development of the TOE it
+may be possible that quality measurements have not been used in the past. In
+this case the evaluator should use the documentation of the planned
+procedures in order to gain confidence that corrective actions are defined if
+results of quality measurements deviate from some threshold.
+
+
+April 2017 Version 3.1 Page 269 of 430
+
+
+**Class ALC: Life-cycle support**
+
+## **14.8 Tools and techniques (ALC_TAT)**
+
+
+**14.8.1** **Evaluation of sub-activity (ALC_TAT.1)**
+
+
+14.8.1.1 Objectives
+
+
+1245 The objective of this sub-activity is to determine whether the developer has
+used well-defined development tools (e.g. programming languages or
+computer-aided design (CAD) systems) that yield consistent and predictable
+results.
+
+
+14.8.1.2 Input
+
+
+1246 The evaluation evidence for this sub-activity is:
+
+
+a) the development tool documentation;
+
+
+b) the subset of the implementation representation.
+
+
+14.8.1.3 Application notes
+
+
+1247 This work may be performed in parallel with the evaluation activities under
+Implementation representation (ADV_IMP), specifically with regard to
+determining the use of features in the tools that will affect the object code
+(e.g. compilation options).
+
+
+14.8.1.4 Action ALC_TAT.1.1E
+
+
+ALC_TAT.1.1C _**Each development tool used for implementation shall be well-defined.**_
+
+
+ALC_TAT.1-1 The evaluator _**shall examine**_ the development tool documentation provided
+to determine that each development tools is well-defined.
+
+
+1248 For example, a well-defined language, compiler or CAD system may be
+considered to be one that conforms to a recognised standard, such as the ISO
+standards. A well-defined language is one that has a clear and complete
+description of its syntax, and a detailed description of the semantics of each
+construct.
+
+
+ALC_TAT.1.2C _**The documentation of each development tool shall unambiguously define**_
+_**the meaning of all statements as well as all conventions and directives used**_
+_**in the implementation.**_
+
+
+ALC_TAT.1-2 The evaluator _**shall examine**_ the documentation of each development tool to
+determine that it unambiguously defines the meaning of all statements as
+well as all conventions and directives used in the implementation.
+
+
+1249 The development tool documentation (e.g. programming language
+specifications and user manuals) should cover all statements used in the
+implementation representation of the TOE, and for each such statement
+should provide a clear and unambiguous definition of the purpose and effect
+of that statement. This work may be performed in parallel with the
+
+
+Page 270 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+evaluator's examination of the implementation representation performed
+during the ADV_IMP sub-activity. The key test the evaluator should apply is
+whether or not the documentation is sufficiently clear for the evaluator to be
+able to understand the implementation representation. The documentation
+should not assume (for example) that the reader is an expert in the
+programming language used.
+
+
+1250 Reference to the use of a documented standard is an acceptable approach to
+meet this requirement, provided that the standard is available to the evaluator.
+Any differences from the standard should be documented.
+
+
+1251 The critical test is whether the evaluator can understand the TOE source code
+when performing source code analysis covered in the ADV_IMP sub-activity.
+However, the following checklist can additionally be used in searching for
+problem areas:
+
+
+a) In the language definition, phrases such as โthe effect of this
+construct is undefinedโ and terms such as โimplementation
+dependentโ or โerroneousโ may indicate ill-defined areas.
+
+
+b) Aliasing (allowing the same piece of memory to be referenced in
+different ways) is a common source of ambiguity problems.
+
+
+c) Exception handling (e.g. what happens after memory exhaustion or
+stack overflow) is often poorly defined.
+
+
+1252 Most languages in common use, however well designed, will have some
+problematic constructs. If the implementation language is mostly well
+defined, but some problematic constructs exist, then an inconclusive verdict
+should be assigned, pending examination of the source code.
+
+
+1253 The evaluator should verify, during the examination of source code, that any
+use of the problematic constructs does not introduce vulnerabilities. The
+evaluator should also ensure that constructs precluded by the documented
+standard are not used.
+
+
+1254 The development tool documentation should define all conventions and
+directives used in the implementation.
+
+
+ALC_TAT.1.3C _**The documentation of each development tool shall unambiguously define**_
+_**the meaning of all implementation-dependent options.**_
+
+
+ALC_TAT.1-3 The evaluator _**shall examine**_ the development tool documentation to
+determine that it unambiguously defines the meaning of all implementationdependent options.
+
+
+1255 The documentation of software development tools should include definitions
+of implementation-dependent options that may affect the meaning of the
+executable code, and those that are different from the standard language as
+documented. Where source code is provided to the evaluator, information
+should also be provided on compilation and linking options used.
+
+
+April 2017 Version 3.1 Page 271 of 430
+
+
+**Class ALC: Life-cycle support**
+
+
+1256 The documentation for hardware design and development tools should
+describe the use of all options that affect the output from the tools (e.g.
+detailed hardware specifications, or actual hardware).
+
+
+**14.8.2** **Evaluation of sub-activity (ALC_TAT.2)**
+
+
+14.8.2.1 Objectives
+
+
+1257 The objective of this sub-activity is to determine whether the developer has
+used well-defined development tools (e.g. programming languages or
+computer-aided design (CAD) systems) that yield consistent and predictable
+results, and whether implementation standards have been applied.
+
+
+14.8.2.2 Input
+
+
+1258 The evaluation evidence for this sub-activity is:
+
+
+a) the development tool documentation;
+
+
+b) the implementation standards description;
+
+
+c) the provided implementation representation of the TSF.
+
+
+14.8.2.3 Application notes
+
+
+1259 This work may be performed in parallel with the evaluation activities under
+ADV_IMP, specifically with regard to determining the use of features in the
+tools that will affect the object code (e.g. compilation options).
+
+
+14.8.2.4 Action ALC_TAT.2.1E
+
+
+ALC_TAT.2.1C _**Each development tool used for implementation shall be well-defined.**_
+
+
+ALC_TAT.2-1 The evaluator _**shall examine**_ the development tool documentation provided
+to determine that each development tool is well-defined.
+
+
+1260 For example, a well-defined language, compiler or CAD system may be
+considered to be one that conforms to a recognised standard, such as the ISO
+standards. A well-defined language is one that has a clear and complete
+description of its syntax, and a detailed description of the semantics of each
+construct.
+
+
+ALC_TAT.2.2C _**The documentation of each development tool shall unambiguously define**_
+_**the meaning of all statements as well as all conventions and directives used**_
+_**in the implementation.**_
+
+
+ALC_TAT.2-2 The evaluator _**shall examine**_ the documentation of each development tool to
+determine that it unambiguously defines the meaning of all statements as
+well as all conventions and directives used in the implementation.
+
+
+1261 The development tool documentation (e.g. programming language
+specifications and user manuals) should cover all statements used in the
+
+
+Page 272 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+implementation representation of the TOE, and for each such statement
+should provide a clear and unambiguous definition of the purpose and effect
+of that statement. This work may be performed in parallel with the
+evaluator's examination of the implementation representation performed
+during the ADV_IMP sub-activity. The key test the evaluator should apply is
+whether or not the documentation is sufficiently clear for the evaluator to be
+able to understand the implementation representation. The documentation
+should not assume (for example) that the reader is an expert in the
+programming language used.
+
+
+1262 Reference to the use of a documented standard is an acceptable approach to
+meet this requirement, provided that the standard is available to the evaluator.
+Any differences from the standard should be documented.
+
+
+1263 The critical test is whether the evaluator can understand the TOE source code
+when performing source code analysis covered in the ADV_IMP sub-activity.
+However, the following checklist can additionally be used in searching for
+problem areas:
+
+
+a) In the language definition, phrases such as โthe effect of this
+construct is undefinedโ and terms such as โimplementation
+dependentโ or โerroneousโ may indicate ill-defined areas.
+
+
+b) Aliasing (allowing the same piece of memory to be referenced in
+different ways) is a common source of ambiguity problems.
+
+
+c) Exception handling (e.g. what happens after memory exhaustion or
+stack overflow) is often poorly defined.
+
+
+1264 Most languages in common use, however well designed, will have some
+problematic constructs. If the implementation language is mostly well
+defined, but some problematic constructs exist, then an inconclusive verdict
+should be assigned, pending examination of the source code.
+
+
+1265 The evaluator should verify, during the examination of source code, that any
+use of the problematic constructs does not introduce vulnerabilities. The
+evaluator should also ensure that constructs precluded by the documented
+standard are not used.
+
+
+1266 The development tool documentation should define all conventions and
+directives used in the implementation.
+
+
+ALC_TAT.2.3C _**The documentation of each development tool shall unambiguously define**_
+_**the meaning of all implementation-dependent options.**_
+
+
+ALC_TAT.2-3 The evaluator _**shall examine**_ the development tool documentation to
+determine that it unambiguously defines the meaning of all implementationdependent options.
+
+
+1267 The documentation of software development tools should include definitions
+of implementation-dependent options that may affect the meaning of the
+
+
+April 2017 Version 3.1 Page 273 of 430
+
+
+**Class ALC: Life-cycle support**
+
+
+executable code, and those that are different from the standard language as
+documented. Where source code is provided to the evaluator, information
+should also be provided on compilation and linking options used.
+
+
+1268 The documentation for hardware design and development tools should
+describe the use of all options that affect the output from the tools (e.g.
+detailed hardware specifications, or actual hardware).
+
+
+14.8.2.5 Action ALC_TAT.2.2E
+
+
+ALC_TAT.2-4 The evaluator _**shall examine**_ aspects of the implementation process to
+determine that documented implementation standards have been applied.
+
+
+1269 This work unit requires the evaluator to analyse the provided implementation
+representation of the TOE to determine whether the documented
+implementation standards have been applied.
+
+
+1270 The evaluator should verify that constructs excluded by the documented
+standard are not used.
+
+
+1271 Additionally, the evaluator should verify the developer's procedures which
+ensure the application of the defined standards within the design and
+implementation process of the TOE. Therefore, documentary evidence
+should be supplemented by visiting the development environment. A visit to
+the development environment will allow the evaluator to:
+
+
+a) observe the application of defined standards;
+
+
+b) examine documentary evidence of application of procedures
+describing the use of defined standards;
+
+
+c) interview development staff to check awareness of the application of
+defined standards and procedures.
+
+
+1272 A development site visit is a useful means of gaining confidence in the
+procedures being used. Any decision not to make such a visit should be
+determined in consultation with the evaluation authority.
+
+
+1273 The evaluator compares the provided implementation representation with the
+description of the applied implementation standards and verifies their use.
+
+
+1274 At this level it is not required that the complete provided implementation
+representation of the TSF is based on implementation standards, but only
+those parts that are developed by the TOE developer himself. The evaluator
+may consult the configuration list required by the CM scope (ALC_CMS) to
+get the information which parts are developed by the TOE developer, and
+which by third party developers.
+
+
+1275 If the referenced implementation standards are not applied for at least parts
+of the provided implementation representation, the evaluator action related to
+this work unit is assigned a fail verdict.
+
+
+Page 274 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+1276 Note that parts of the TOE which are not TSF relevant do not need to be
+examined.
+
+
+1277 This work unit may be performed in conjunction with the evaluation
+activities under ADV_IMP.
+
+
+**14.8.3** **Evaluation of sub-activity (ALC_TAT.3)**
+
+
+14.8.3.1 Objectives
+
+
+1278 The objective of this sub-activity is to determine whether the developer and
+his subcontractors have used well-defined development tools (e.g.
+programming languages or computer-aided design (CAD) systems) that yield
+consistent and predictable results, and whether implementation standards
+have been applied.
+
+
+14.8.3.2 Input
+
+
+1279 The evaluation evidence for this sub-activity is:
+
+
+a) the development tool documentation;
+
+
+b) the implementation standards description;
+
+
+c) the provided implementation representation of the TSF.
+
+
+14.8.3.3 Application notes
+
+
+1280 This work may be performed in parallel with the evaluation activities under
+ADV_IMP, specifically with regard to determining the use of features in the
+tools that will affect the object code (e.g. compilation options).
+
+
+14.8.3.4 Action ALC_TAT.3.1E
+
+
+ALC_TAT.3.1C _**Each development tool used for implementation shall be well-defined.**_
+
+
+ALC_TAT.3-1 The evaluator _**shall examine**_ the development tool documentation provided
+to determine that each development tool is well-defined.
+
+
+1281 For example, a well-defined language, compiler or CAD system may be
+considered to be one that conforms to a recognised standard, such as the ISO
+standards. A well-defined language is one that has a clear and complete
+description of its syntax, and a detailed description of the semantics of each
+construct.
+
+
+1282 At this level, the documentation of development tools used by third party
+contributors to the TOE has to be included in the evaluator's examination.
+
+
+ALC_TAT.3.2C _**The documentation of each development tool shall unambiguously define**_
+_**the meaning of all statements as well as all conventions and directives used**_
+_**in the implementation.**_
+
+
+April 2017 Version 3.1 Page 275 of 430
+
+
+**Class ALC: Life-cycle support**
+
+
+ALC_TAT.3-2 The evaluator _**shall examine**_ the documentation of each development tool to
+determine that it unambiguously defines the meaning of all statements as
+well as all conventions and directives used in the implementation.
+
+
+1283 The development tool documentation (e.g. programming language
+specifications and user manuals) should cover all statements used in the
+implementation representation of the TOE, and for each such statement
+should provide a clear and unambiguous definition of the purpose and effect
+of that statement. This work may be performed in parallel with the
+evaluator's examination of the implementation representation performed
+during the ADV_IMP sub-activity. The key test the evaluator should apply is
+whether or not the documentation is sufficiently clear for the evaluator to be
+able to understand the implementation representation. The documentation
+should not assume (for example) that the reader is an expert in the
+programming language used.
+
+
+1284 Reference to the use of a documented standard is an acceptable approach to
+meet this requirement, provided that the standard is available to the evaluator.
+Any differences from the standard should be documented.
+
+
+1285 The critical test is whether the evaluator can understand the TOE source code
+when performing source code analysis covered in the ADV_IMP sub-activity.
+However, the following checklist can additionally be used in searching for
+problem areas:
+
+
+a) In the language definition, phrases such as โthe effect of this
+construct is undefinedโ and terms such as โimplementation
+dependentโ or โerroneousโ may indicate ill-defined areas.
+
+
+b) Aliasing (allowing the same piece of memory to be referenced in
+different ways) is a common source of ambiguity problems.
+
+
+c) Exception handling (e.g. what happens after memory exhaustion or
+stack overflow) is often poorly defined.
+
+
+1286 Most languages in common use, however well designed, will have some
+problematic constructs. If the implementation language is mostly well
+defined, but some problematic constructs exist, then an inconclusive verdict
+should be assigned, pending examination of the source code.
+
+
+1287 The evaluator should verify, during the examination of source code, that any
+use of the problematic constructs does not introduce vulnerabilities. The
+evaluator should also ensure that constructs precluded by the documented
+standard are not used.
+
+
+1288 The development tool documentation should define all conventions and
+directives used in the implementation.
+
+
+1289 At this level, the documentation of development tools used by third party
+contributors to the TOE has to be included in the evaluator's examination.
+
+
+Page 276 of 430 Version 3.1 April 2017
+
+
+**Class ALC: Life-cycle support**
+
+
+ALC_TAT.3.3C _**The documentation of each development tool shall unambiguously define**_
+_**the meaning of all implementation-dependent options.**_
+
+
+ALC_TAT.3-3 The evaluator _**shall examine**_ the development tool documentation to
+determine that it unambiguously defines the meaning of all implementationdependent options.
+
+
+1290 The documentation of software development tools should include definitions
+of implementation-dependent options that may affect the meaning of the
+executable code, and those that are different from the standard language as
+documented. Where source code is provided to the evaluator, information
+should also be provided on compilation and linking options used.
+
+
+1291 The documentation for hardware design and development tools should
+describe the use of all options that affect the output from the tools (e.g.
+detailed hardware specifications, or actual hardware).
+
+
+1292 At this level, the documentation of development tools used by third party
+contributors to the TOE has to be included in the evaluator's examination.
+
+
+14.8.3.5 Action ALC_TAT.3.2E
+
+
+ALC_TAT.3-4 The evaluator _**shall examine**_ aspects of the implementation process to
+determine that documented implementation standards have been applied.
+
+
+1293 This work unit requires the evaluator to analyse the provided implementation
+representation of the TOE to determine whether the documented
+implementation standards have been applied.
+
+
+1294 The evaluator should verify that constructs excluded by the documented
+standard are not used.
+
+
+1295 Additionally, the evaluator should verify the developer's procedures which
+ensure the application of the defined standards within the design and
+implementation process of the TOE. Therefore, documentary evidence
+should be supplemented by visiting the development environment. A visit to
+the development environment will allow the evaluator to:
+
+
+a) observe the application of defined standards;
+
+
+b) examine documentary evidence of application of procedures
+describing the use of defined standards;
+
+
+c) interview development staff to check awareness of the application of
+defined standards and procedures.
+
+
+1296 A development site visit is a useful means of gaining confidence in the
+procedures being used. Any decision not to make such a visit should be
+determined in consultation with the evaluation authority.
+
+
+1297 The evaluator compares the provided implementation representation with the
+description of the applied implementation standards and verifies their use.
+
+
+April 2017 Version 3.1 Page 277 of 430
+
+
+**Class ALC: Life-cycle support**
+
+
+1298 At this level it is required that the complete provided implementation
+representation of the TSF is based on implementation standards, including
+third party contributions. This may require the evaluator to visit the sites of
+contributors. The evaluator may consult the configuration list required by the
+CM scope (ALC_CMS) to see who has developed which part of the TOE.
+
+
+1299 Note that parts of the TOE which are not TSF relevant do not need to be
+examined.
+
+
+1300 This work unit may be performed in conjunction with the evaluation
+activities under ADV_IMP.
+
+
+Page 278 of 430 Version 3.1 April 2017
+
+
+**Class ATE: Tests**
+
+# **15 Class ATE: Tests**
+
+## **15.1 Introduction**
+
+
+1301 The goal of this activity is to determine whether the TOE behaves as
+described in the ST and as specified in the evaluation evidence (described in
+the ADV class). This determination is achieved through some combination of
+the developer's own functional testing of the TSF (Functional tests
+(ATE_FUN)) and independent testing the TSF by the evaluator (Independent
+testing (ATE_IND)). At the lowest level of assurance, there is no
+requirement for developer involvement, so the only testing is conducted by
+the evaluator, using the limited available information about the TOE.
+Additional assurance is gained as the developer becomes increasingly
+involved both in testing and in providing additional information about the
+TOE, and as the evaluator increases the independent testing activities.
+
+## **15.2 Application notes**
+
+
+1302 Testing of the TSF is conducted by the evaluator and, in most cases, by the
+developer. The evaluator's testing efforts consist not only of creating and
+running original tests, but also of assessing the adequacy of the developer's
+tests and re-running a subset of them.
+
+
+1303 The evaluator analyses the developer's tests to determine the extent to which
+they are sufficient to demonstrate that TSFI (see Functional specification
+(ADV_FSP)) perform as specified, and to understand the developer's
+approach to testing. Similarly, the evaluator analyses the developer's tests to
+determine the extent to which they are sufficient to demonstrate the internal
+behaviour and properties of the TSF.
+
+
+1304 The evaluator also executes a subset of the developer's tests as documented
+to gain confidence in the developer's test results: the evaluator will use the
+results of this analysis as an input to independently testing a subset of the
+TSF. With respect to this subset, the evaluator takes a testing approach that is
+different from that of the developer, particularly if the developer's tests have
+shortcomings.
+
+
+1305 To determine the adequacy of developer's test documentation or to create
+new tests, the evaluator needs to understand the desired expected behaviour
+of the TSF, both internally and as seen at the TSFI, in the context of the
+SFRs it is to satisfy. The evaluator may choose to divide the TSF and TSFI
+into subsets according to functional areas of the ST (audit subsystem, auditrelated TSFI, authentication module, authentication-related TSFI, etc.) if
+they were not already divided in the ST, and focus on one subset of the TSF
+and TSFI at a time, examining the ST requirement and the relevant parts of
+the development and guidance documentation to gain an understanding of
+the way the TOE is expected to behave. This reliance upon the development
+documentation underscores the need for the dependencies on ADV by
+Coverage (ATE_COV) and Depth (ATE_DPT).
+
+
+April 2017 Version 3.1 Page 279 of 430
+
+
+**Class ATE: Tests**
+
+
+1306 The CC has separated coverage and depth from functional tests to increase
+the flexibility when applying the components of the families. However, the
+requirements of the families are intended to be applied together to confirm
+that the TSF operates according to its specification. This tight coupling of
+families has led to some duplication of evaluator work units across subactivities. These application notes are used to minimise duplication of text
+between sub-activities.
+
+
+**15.2.1** **Understanding the expected behaviour of the TOE**
+
+
+1307 Before the adequacy of test documentation can be accurately evaluated, or
+before new tests can be created, the evaluator has to understand the desired
+expected behaviour of a security function in the context of the requirements
+it is to satisfy.
+
+
+1308 As mentioned earlier, the evaluator may choose to subset the TSF and TSFI
+according to SFRs (audit, authentication, etc.) in the ST and focus on one
+subset at a time. The evaluator examines each ST requirement and the
+relevant parts of the functional specification and guidance documentation to
+gain an understanding of the way the related TSFI is expected to behave.
+Similarly, the evaluator examines the relevant parts of the TOE design and
+security architecture documentation to gain an understanding of the way the
+related modules or subsystems of the TSF are expected to behave.
+
+
+1309 With an understanding of the expected behaviour, the evaluator examines the
+test plan to gain an understanding of the testing approach. In most cases, the
+testing approach will entail a TSFI being stimulated and its responses
+observed. Externally-visible functionality can be tested directly; however, in
+cases where functionality is not visible external to the TOE (for example,
+testing the residual information protection functionality), other means will
+need to be employed.
+
+
+**15.2.2** **Testing vs. alternate approaches to verify the expected**
+**behaviour of functionality**
+
+
+1310 In cases where it is impractical or inadequate to test specific functionality
+(where it provides no externally-visible TSFI), the test plan should identify
+the alternate approach to verify expected behaviour. It is the evaluator's
+responsibility to determine the suitability of the alternate approach. However,
+the following should be considered when assessing the suitability of alternate
+approaches:
+
+
+a) an analysis of the implementation representation to determine that the
+required behaviour should be exhibited by the TOE is an acceptable
+alternate approach. This could mean a code inspection for a software
+TOE or perhaps a chip mask inspection for a hardware TOE.
+
+
+b) it is acceptable to use evidence of developer integration or module
+testing, even if the claimed assurance requirements do not include
+availability of lower level descriptions of the TOE modules (e.g.
+Evaluation of sub-activity (ADV_TDS.3)) or implementation
+
+
+Page 280 of 430 Version 3.1 April 2017
+
+
+**Class ATE: Tests**
+
+
+(Implementation representation (ADV_IMP)). If evidence of
+developer integration or module testing is used in verifying the
+expected behaviour of a security functionality, care should be given
+to confirm that the testing evidence reflects the current
+implementation of the TOE. If the subsystems or modules have been
+changed since testing occurred, evidence that the changes were
+tracked and addressed by analysis or further testing will usually be
+required.
+
+
+1311 It should be emphasised that supplementing the testing effort with alternate
+approaches should only be undertaken when both the developer and
+evaluator determine that there exists no other practical means to test the
+expected behaviour.
+
+
+**15.2.3** **Verifying the adequacy of tests**
+
+
+1312 Test pre-requisites are necessary to establish the required initial conditions
+for the test. They may be expressed in terms of parameters that must be set or
+in terms of test ordering in cases where the completion of one test establishes
+the necessary pre-requisites for another test. The evaluator must determine
+that the pre-requisites are complete and appropriate in that they will not bias
+the observed test results towards the expected test results.
+
+
+1313 The test steps and expected results specify the actions and parameters to be
+applied to the TSFI as well as how the expected results should be verified
+and what they are. The evaluator must determine that the test steps and
+expected results are consistent with the descriptions of the TSFI in the
+functional specification. This means that each characteristic of the TSFI
+behaviour explicitly described in the functional specification should have
+tests and expected results to verify that behaviour.
+
+
+1314 The overall aim of this testing activity is to determine that each subsystem,
+module, and TSFI has been sufficiently tested against the behavioural claims
+in the functional specification, TOE design, and architecture description. At
+the higher assurance levels, testing also includes bounds testing and negative
+testing. The test procedures will provide insight as to how the TSFIs,
+modules, and subsystems have been exercised by the developer during
+testing. The evaluator uses this information when developing additional tests
+to independently test the TSF.
+
+
+April 2017 Version 3.1 Page 281 of 430
+
+
+**Class ATE: Tests**
+
+## **15.3 Coverage (ATE_COV)**
+
+
+**15.3.1** **Evaluation of sub-activity (ATE_COV.1)**
+
+
+15.3.1.1 Objectives
+
+
+1315 The objective of this sub-activity is to determine whether the developer has
+tested the TSFIs, and that the developer's test coverage evidence shows
+correspondence between the tests identified in the test documentation and the
+TSFIs described in the functional specification.
+
+
+15.3.1.2 Input
+
+
+1316 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the functional specification;
+
+
+c) the test documentation;
+
+
+d) the test coverage evidence.
+
+
+15.3.1.3 Application notes
+
+
+1317 The coverage analysis provided by the developer is required to show the
+correspondence between the tests provided as evaluation evidence and the
+functional specification. However, the coverage analysis need not
+demonstrate that all TSFI have been tested, or that all externally-visible
+interfaces to the TOE have been tested. Such shortcomings are considered by
+the evaluator during the independent testing (Evaluation of sub-activity
+(ATE_IND.2)) sub-activity.
+
+
+15.3.1.4 Action ATE_COV.1.1E
+
+
+ATE_COV.1.1C _**The evidence of the test coverage shall show the correspondence between**_
+_**the tests in the test documentation and the TSFIs in the functional**_
+_**specification.**_
+
+
+ATE_COV.1-1 The evaluator _**shall examine**_ the test coverage evidence to determine that the
+correspondence between the tests identified in the test documentation and the
+TSFIs described in the functional specification is accurate.
+
+
+1318 Correspondence may take the form of a table or matrix. The coverage
+evidence required for this component will reveal the extent of coverage,
+rather than to show complete coverage. In cases where coverage is shown to
+be poor the evaluator should increase the level of independent testing to
+compensate.
+
+
+Page 282 of 430 Version 3.1 April 2017
+
+
+**Class ATE: Tests**
+
+
+**15.3.2** **Evaluation of sub-activity (ATE_COV.2)**
+
+
+15.3.2.1 Objectives
+
+
+1319 The objective of this sub-activity is to determine whether the developer has
+tested all of the TSFIs, and that the developer's test coverage evidence shows
+correspondence between the tests identified in the test documentation and the
+TSFIs described in the functional specification.
+
+
+15.3.2.2 Input
+
+
+a) the ST;
+
+
+b) the functional specification;
+
+
+c) the test documentation;
+
+
+d) the test coverage analysis.
+
+
+15.3.2.3 Action ATE_COV.2.1E
+
+
+ATE_COV.2.1C _**The analysis of the test coverage shall demonstrate the correspondence**_
+_**between the tests in the test documentation and the TSFIs in the functional**_
+_**specification.**_
+
+
+ATE_COV.2-1 The evaluator _**shall examine**_ the test coverage analysis to determine that the
+correspondence between the tests in the test documentation and the interfaces
+in the functional specification is accurate.
+
+
+1320 A simple cross-table may be sufficient to show test correspondence. The
+identification of the tests and the interfaces presented in the test coverage
+analysis has to be unambiguous.
+
+
+1321 The evaluator is reminded that this does not imply that all tests in the test
+documentation must map to interfaces in the functional specification.
+
+
+ATE_COV.2-2 The evaluator _**shall examine**_ the test plan to determine that the testing
+approach for each interface demonstrates the expected behaviour of that
+interface.
+
+
+1322 Guidance on this work unit can be found in:
+
+
+a) 15.2.1, Understanding the expected behaviour of the TOE
+
+
+b) 15.2.2, Testing vs. alternate approaches to verify the expected
+behaviour of functionality
+
+
+ATE_COV.2-3 The evaluator _**shall examine**_ the test procedures to determine that the test
+prerequisites, test steps and expected result(s) adequately test each interface.
+
+
+1323 Guidance on this work units, as it pertains to the functional specification, can
+be found in:
+
+
+April 2017 Version 3.1 Page 283 of 430
+
+
+**Class ATE: Tests**
+
+
+a) 15.2.3, Verifying the adequacy of tests
+
+
+ATE_COV.2.2C _**The analysis of the test coverage shall demonstrate that all TSFIs in the**_
+_**functional specification have been tested.**_
+
+
+ATE_COV.2-4 The evaluator _**shall examine**_ the test coverage analysis to determine that the
+correspondence between the interfaces in the functional specification and the
+tests in the test documentation is complete.
+
+
+1324 All TSFIs that are described in the functional specification have to be present
+in the test coverage analysis and mapped to tests in order for completeness to
+be claimed, although exhaustive specification testing of interfaces is not
+required. Incomplete coverage would be evident if an interface was identified
+in the functional specification and no test was mapped to it.
+
+
+1325 The evaluator is reminded that this does not imply that all tests in the test
+documentation must map to interfaces in the functional specification.
+
+
+**15.3.3** **Evaluation of sub-activity (ATE_COV.3)**
+
+
+1326 There is no general guidance; the scheme should be consulted for guidance
+on this sub-activity.
+
+
+Page 284 of 430 Version 3.1 April 2017
+
+
+**Class ATE: Tests**
+
+## **15.4 Depth (ATE_DPT)**
+
+
+**15.4.1** **Evaluation of sub-activity (ATE_DPT.1)**
+
+
+15.4.1.1 Objectives
+
+
+1327 The objective of this sub-activity is to determine whether the developer has
+tested the TSF subsystems against the TOE design and the security
+architecture description.
+
+
+15.4.1.2 Input
+
+
+a) the ST;
+
+
+b) the functional specification;
+
+
+c) the TOE design;
+
+
+d) the security architecture description;
+
+
+e) the test documentation;
+
+
+f) the depth of testing analysis.
+
+
+15.4.1.3 Action ATE_DPT.1.1E
+
+
+ATE_DPT.1.1C _**The analysis of the depth of testing shall demonstrate the correspondence**_
+_**between the tests in the test documentation and the TSF subsystems in the**_
+_**TOE design.**_
+
+
+ATE_DPT.1-1 The evaluator _**shall examine**_ the depth of testing analysis to determine that
+the descriptions of the behaviour of TSF subsystems and of their interactions
+is included within the test documentation.
+
+
+1328 This work unit verifies the content of the correspondence between the tests
+and the descriptions in the TOE design. In cases where the description of the
+TSF's architectural soundness (in Security Architecture (ADV_ARC)) cites
+specific mechanisms, this work unit also verifies the correspondence
+between the tests and the descriptions of the behaviour of such mechanisms.
+
+
+1329 A simple cross-table may be sufficient to show test correspondence. The
+identification of the tests and the behaviour/interaction presented in the
+depth-of coverage analysis has to be unambiguous.
+
+
+1330 When Evaluation of sub-activity (ATE_DPT.1) is combined with a
+component of TOE design (ADV_TDS), which includes descriptions at the
+module level (e.g. Evaluation of sub-activity (ADV_TDS.3)), the level of
+detail needed to map the test cases to the behaviour of the subsystems may
+require information from the module description to be used. This is because
+Evaluation of sub-activity (ADV_TDS.3) allows the description of details to
+be shifted from the subsystem level to the module level, or even to omit the
+subsystems altogether.
+
+
+April 2017 Version 3.1 Page 285 of 430
+
+
+**Class ATE: Tests**
+
+
+1331 In any case, the required level of detail in the provided reference to the tested
+behaviour can be defined as โthe level of detail required for the description
+of subsystem behaviour as defined by Evaluation of sub-activity
+(ADV_TDS.2) (in particular work unit ADV_TDS.2-4)โ. It states that a
+detailed description of the behaviour typically discusses how the
+functionality is provided, in terms of what key data and data structures re
+present; what control relationships exist within a subsytem and how these
+elements work together to provide the SFR-enforcing behaviour.
+
+
+1332 The evaluator is reminded that not all tests in the test documentation must
+map to a subsystem behaviour or interaction description.
+
+
+ATE_DPT.1-2 The evaluator _**shall examine**_ the test plan, test prerequisites, test steps and
+expected result(s) to determine that the testing approach for the behaviour
+description demonstrates the behaviour of that subsystem as described in the
+TOE design.
+
+
+1333 Guidance on this work unit can be found in:
+
+
+a) 15.2.1, Understanding the expected behaviour of the TOE
+
+
+b) 15.2.2, Testing vs. alternate approaches to verify the expected
+behaviour of functionality
+
+
+1334 When Evaluation of sub-activity (ATE_DPT.1) is combined with a
+component of TOE design (ADV_TDS), which includes descriptions at the
+module level (e.g. Evaluation of sub-activity (ADV_TDS.3)), the level of
+detail needed to map the test cases to the behaviour of the subsystems may
+require information from the module description to be used. This is because
+Evaluation of sub-activity (ADV_TDS.3) allows the description of details to
+be shifted from the subsystem level to the module level, or even to omit the
+subsystems altogether.
+
+
+1335 In any case, the required level of detail in the provided reference to the tested
+behaviour can be defined as โthe level of detail required for the description
+of subsystem behaviour as defined by Evaluation of sub-activity
+(ADV_TDS.2) (in particular work unit ADV_TDS.2-4)โ. It states that a
+detailed description of the behaviour typically discusses how the
+functionality is provided, in terms of what key data and data structures re
+present; what control relationships exist within a subsytem and how these
+elements work together to provide the SFR-enforcing behaviour.
+
+
+1336 If TSF subsystem interfaces are described, the behaviour of those subsystems
+may be tested directly from those interfaces. Otherwise, the behaviour of
+those subsystems is tested from the TSFI interfaces. Or a combination of the
+two may be employed. Whatever strategy is used the evaluator will consider
+its appropriateness for adequately testing the behaviour that is described in
+the TOE design.
+
+
+ATE_DPT.1-3 The evaluator _**shall examine**_ the test plan, test prerequisites, test steps and
+expected result(s) to determine that the testing approach for the behaviour
+
+
+Page 286 of 430 Version 3.1 April 2017
+
+
+**Class ATE: Tests**
+
+
+description demonstrates the interactions among subsystems as described in
+the TOE design.
+
+
+1337 While the previous work unit addresses behaviour of subsystems, this work
+unit addresses the interactions among subsystems.
+
+
+1338 Guidance on this work unit can be found in:
+
+
+a) 15.2.1, Understanding the expected behaviour of the TOE
+
+
+b) 15.2.2, Testing vs. alternate approaches to verify the expected
+behaviour of functionality
+
+
+1339 If TSF subsystem interfaces are described, the interactions with other
+subsystems may be tested directly from those interfaces. Otherwise, the
+interactions among subsystems must be inferred from the TSFI interfaces.
+Whatever strategy is used the evaluator will consider its appropriateness for
+adequately testing the interactions among subsystems that are described in
+the TOE design.
+
+
+ATE_DPT.1.2C _**The analysis of the depth of testing shall demonstrate that all TSF**_
+_**subsystems in the TOE design have been tested.**_
+
+
+ATE_DPT.1-4 The evaluator _**shall examine**_ the test procedures to determine that all
+descriptions of TSF subsystem behaviour and interaction are tested.
+
+
+1340 This work unit verifies the completeness of work unit ATE_DPT.1-1. All
+descriptions of TSF subsystem behaviour and of interactions among TSF
+subsystems that are provided in the TOE design have to be tested.
+Incomplete depth of testing would be evident if a description of TSF
+subsystem behaviour or of interactions among TSF subsystems was
+identified in the TOE design and no tests could be attributed to it.
+
+
+1341 When Evaluation of sub-activity (ATE_DPT.1) is combined with a
+component of TOE design (ADV_TDS), which includes descriptions at the
+module level (e.g. Evaluation of sub-activity (ADV_TDS.3)), the level of
+detail needed to map the test cases to the behaviour of the subsystems may
+require information from the module description to be used. This is because
+Evaluation of sub-activity (ADV_TDS.3) allows the description of details to
+be shifted from the subsystem level to the module level, or even to omit the
+subsystems altogether.
+
+
+1342 In any case, the required level of detail in the provided reference to the tested
+behaviour can be defined as โthe level of detail required for the description
+of subsystem behaviour as defined by Evaluation of sub-activity
+(ADV_TDS.2) (in particular work unit ADV_TDS.2-4)โ. It states that a
+detailed description of the behaviour typically discusses how the
+functionality is provided, in terms of what key data and data structures re
+present; what control relationships exist within a subsytem and how these
+elements work together to provide the SFR-enforcing behaviour.
+
+
+April 2017 Version 3.1 Page 287 of 430
+
+
+**Class ATE: Tests**
+
+
+1343 The evaluator is reminded that this does not imply that all tests in the test
+documentation must map to the subsystem behaviour or interaction
+description in the TOE design.
+
+
+**15.4.2** **Evaluation of sub-activity (ATE_DPT.2)**
+
+
+15.4.2.1 Objectives
+
+
+1344 The objective of this sub-activity is to determine whether the developer has
+tested all the TSF subsystems and SFR-enforcing modules against the TOE
+design and the security architecture description.
+
+
+15.4.2.2 Input
+
+
+a) the ST;
+
+
+b) the functional specification;
+
+
+c) the TOE design;
+
+
+d) the security architecture description;
+
+
+e) the test documentation;
+
+
+f) the depth of testing analysis.
+
+
+15.4.2.3 Action ATE_DPT.2.1E
+
+
+ATE_DPT.2.1C _**The analysis of the depth of testing shall demonstrate the correspondence**_
+_**between the tests in the test documentation and the TSF subsystems and**_
+_**SFR-enforcing modules in the TOE design.**_
+
+
+ATE_DPT.2-1 The evaluator _**shall examine**_ the depth of testing analysis to determine that
+descriptions of the behaviour of TSF subsystems and of their interactions are
+included within the test documentation.
+
+
+1345 This work unit verifies the content of the correspondence between the tests
+and the descriptions in the TOE design. In cases where the description of the
+TSF's architectural soundness (in Security Architecture (ADV_ARC)) cites
+specific mechanisms, this work unit also verifies the correspondence
+between the tests and the descriptions of the behaviour of such mechanisms.
+
+
+1346 A simple cross-table may be sufficient to show test correspondence. The
+identification of the tests and the behaviour/interaction presented in the
+depth-of coverage analysis has to be unambiguous.
+
+
+1347 The evaluator is reminded that not all tests in the test documentation must
+map to a subsystem behaviour or interaction description.
+
+
+ATE_DPT.2-2 The evaluator _**shall examine**_ the test plan, test prerequisites, test steps and
+expected result(s) to determine that the testing approach for the behaviour
+
+
+Page 288 of 430 Version 3.1 April 2017
+
+
+**Class ATE: Tests**
+
+
+description demonstrates the behaviour of that subsystem as described in the
+TOE design.
+
+
+1348 Guidance on this work unit can be found in:
+
+
+a) 15.2.1, Understanding the expected behaviour of the TOE
+
+
+b) 15.2.2, Testing vs. alternate approaches to verify the expected
+behaviour of functionality
+
+
+1349 If TSF subsystem interfaces are described, the behaviour of those subsystems
+may be tested directly from those interfaces. Otherwise, the behaviour of
+those subsystems is tested from the TSFI interfaces. Or a combination of the
+two may be employed. Whatever strategy is used the evaluator will consider
+its appropriateness for adequately testing the behaviour that is described in
+the TOE design.
+
+
+ATE_DPT.2-3 The evaluator _**shall examine**_ the test plan, test prerequisites, test steps and
+expected result(s) to determine that the testing approach for the behaviour
+description demonstrates the interactions among subsystems as described in
+the TOE design.
+
+
+1350 While the previous work unit addresses behaviour of subsystems, this work
+unit addresses the interactions among subsystems.
+
+
+1351 Guidance on this work unit can be found in:
+
+
+a) 15.2.1, Understanding the expected behaviour of the TOE
+
+
+b) 15.2.2, Testing vs. alternate approaches to verify the expected
+behaviour of functionality
+
+
+1352 If TSF subsystem interfaces are described, the interactions with other
+subsystems may be tested directly from those interfaces. Otherwise, the
+interactions among subsystems must be inferred from the TSFI interfaces.
+Whatever strategy is used the evaluator will consider its appropriateness for
+adequately testing the interactions among subsystems that are described in
+the TOE design.
+
+
+ATE_DPT.2-4 The evaluator _**shall examine**_ the depth of testing analysis to determine that
+the interfaces of SFR-enforcing modules are included within the test
+documentation.
+
+
+1353 This work unit verifies the content of the correspondence between the tests
+and the descriptions in the TOE design. In cases where the description of the
+TSF's architectural soundness (in Security Architecture (ADV_ARC)) cites
+specific mechanisms at the modular level, this work unit also verifies the
+correspondence between the tests and the descriptions of the behaviour of
+such mechanisms.
+
+
+April 2017 Version 3.1 Page 289 of 430
+
+
+**Class ATE: Tests**
+
+
+1354 A simple cross-table may be sufficient to show test correspondence. The
+identification of the tests and the SFR-enforcing modules presented in the
+depth-of coverage analysis has to be unambiguous.
+
+
+1355 The evaluator is reminded that not all tests in the test documentation must
+map to the interfaces of SFR-enforcing modules.
+
+
+ATE_DPT.2-5 The evaluator _**shall examine**_ the test plan, test prerequisites, test steps and
+expected result(s) to determine that the testing approach for each SFRenforcing module interface demonstrates the expected behaviour of that
+interface.
+
+
+1356 While work unit ATE_DPT.2-2 addresses expected behaviour of subsystems,
+this work unit addresses expected behaviour of the SFR-enforcing module
+interfaces that are covered by ATE_DPT.2-4.
+
+
+1357 Guidance on this work unit can be found in:
+
+
+a) 15.2.1, Understanding the expected behaviour of the TOE
+
+
+b) 15.2.2, Testing vs. alternate approaches to verify the expected
+behaviour of functionality
+
+
+1358 Testing of an interface may be performed directly at that interface, or at the
+external interfaces, or a combination of both. Whatever strategy is used the
+evaluator will consider its appropriateness for adequately testing the
+interfaces. Specifically the evaluator determines whether testing at the
+internal interfaces is necessary or whether these internal interfaces can be
+adequately tested (albeit implicitly) by exercising the external interfaces.
+This determination is left to the evaluator, as is its justification.
+
+
+ATE_DPT.2.2C _**The analysis of the depth of testing shall demonstrate that all TSF**_
+_**subsystems in the TOE design have been tested.**_
+
+
+ATE_DPT.2-6 The evaluator _**shall examine**_ the test procedures to determine that all
+descriptions of TSF subsystem behaviour and interaction are tested.
+
+
+1359 This work unit verifies the completeness of work unit ATE_DPT.2-1. All
+descriptions of TSF subsystem behaviour and of interactions among TSF
+subsystems that are provided in the TOE design have to be tested.
+Incomplete depth of testing would be evident if a description of TSF
+subsystem behaviour or of interactions among TSF subsystems was
+identified in the TOE design and no tests could be attributed to it.
+
+
+1360 The evaluator is reminded that this does not imply that all tests in the test
+documentation must map to the subsystem behaviour or interaction
+description in the TOE design.
+
+
+ATE_DPT.2.3C _**The analysis of the depth of testing shall demonstrate that the SFR-**_
+_**enforcing modules in the TOE design have been tested.**_
+
+
+Page 290 of 430 Version 3.1 April 2017
+
+
+**Class ATE: Tests**
+
+
+ATE_DPT.2-7 The evaluator _**shall examine**_ the test procedures to determine that all
+interfaces of SFR-enforcing modules are tested.
+
+
+1361 This work unit verifies the completeness of work unit ATE_DPT.2-4. All
+interfaces of SFR-enforcing modules that are provided in the TOE design
+have to be tested. Incomplete depth of testing would be evident if any
+interface of any SFR-enforcing modules was identified in the TOE design
+and no tests could be attributed to it.
+
+
+1362 The evaluator is reminded that this does not imply that all tests in the test
+documentation must map to an interface of an SFR-enforcing module in the
+TOE design.
+
+
+**15.4.3** **Evaluation of sub-activity (ATE_DPT.3)**
+
+
+15.4.3.1 Objectives
+
+
+1363 The objective of this sub-activity is to determine whether the developer has
+tested the all the TSF subsystems and modules against the TOE design and
+the security architecture description.
+
+
+15.4.3.2 Input
+
+
+a) the ST;
+
+
+b) the functional specification;
+
+
+c) the TOE design;
+
+
+d) the security architecture description;
+
+
+e) the test documentation;
+
+
+f) the depth of testing analysis.
+
+
+15.4.3.3 Action ATE_DPT.3.1E
+
+
+ATE_DPT.3.1C _**The analysis of the depth of testing shall demonstrate the correspondence**_
+_**between the tests in the test documentation and the TSF subsystems and**_
+_**modules in the TOE design.**_
+
+
+ATE_DPT.3-1 The evaluator _**shall examine**_ the depth of testing analysis to determine that
+descriptions of the behaviour of TSF subsystems and of their interactions are
+included within the test documentation.
+
+
+1364 This work unit verifies the content of the correspondence between the tests
+and the descriptions in the TOE design. A simple cross-table may be
+sufficient to show test correspondence. The identification of the tests and the
+behaviour/interaction presented in the depth-of coverage analysis has to be
+unambiguous.
+
+
+April 2017 Version 3.1 Page 291 of 430
+
+
+**Class ATE: Tests**
+
+
+1365 The evaluator is reminded that not all tests in the test documentation must
+map to a subsystem behaviour or interaction description.
+
+
+ATE_DPT.3-2 The evaluator _**shall examine**_ the test plan, test prerequisites, test steps and
+expected result(s) to determine that the testing approach for the behaviour
+description demonstrates the behaviour of that subsystem as described in the
+TOE design.
+
+
+1366 Guidance on this work unit can be found in:
+
+
+a) 15.2.1, Understanding the expected behaviour of the TOE
+
+
+b) 15.2.2, Testing vs. alternate approaches to verify the expected
+behaviour of functionality
+
+
+1367 If TSF subsystem interfaces are provided, the behaviour of those subsystems
+may be performed directly from those interfaces. Otherwise, the behaviour of
+those subsystems is tested from the TSFI interfaces. Or a combination of the
+two may be employed. Whatever strategy is used the evaluator will consider
+its appropriateness for adequately testing the behaviour that is described in
+the TOE design.
+
+
+ATE_DPT.3-3 The evaluator _**shall examine**_ the test plan, test prerequisites, test steps and
+expected result(s) to determine that the testing approach for the behaviour
+description demonstrates the interactions among subsystems as described in
+the TOE design.
+
+
+1368 Guidance on this work unit can be found in:
+
+
+a) 15.2.1, Understanding the expected behaviour of the TOE
+
+
+b) 15.2.2, Testing vs. alternate approaches to verify the expected
+behaviour of functionality
+
+
+1369 While the previous work unit addresses behaviour of subsystems, this work
+unit addresses the interactions among subsystems.
+
+
+1370 If TSF subsystem interfaces are provided, the interactions with other
+subsystems may be performed directly from those interfaces. Otherwise, the
+interactions among subsystems must be inferred from the TSFI interfaces.
+Whatever strategy is used the evaluator will consider its appropriateness for
+adequately testing the interactions among subsystems that are described in
+the TOE design.
+
+
+ATE_DPT.3-4 The evaluator _**shall examine**_ the depth of testing analysis to determine that
+the interfaces of TSF modules are included within the test documentation.
+
+
+1371 This work unit verifies the content of the correspondence between the tests
+and the descriptions in the TOE design. A simple cross-table may be
+sufficient to show test correspondence. The identification of the tests and the
+behaviour/interaction presented in the depth-of coverage analysis has to be
+unambiguous.
+
+
+Page 292 of 430 Version 3.1 April 2017
+
+
+**Class ATE: Tests**
+
+
+1372 The evaluator is reminded that not all tests in the test documentation must
+map to a subsystem behaviour or interaction description.
+
+
+ATE_DPT.3-5 The evaluator _**shall examine**_ the test plan, test prerequisites, test steps and
+expected result(s) to determine that the testing approach for each TSF
+module interface demonstrates the expected behaviour of that interface.
+
+
+1373 Guidance on this work unit can be found in:
+
+
+a) 15.2.1, Understanding the expected behaviour of the TOE
+
+
+b) 15.2.2, Testing vs. alternate approaches to verify the expected
+behaviour of functionality
+
+
+1374 Testing of an interface may be performed directly at that interface, or at the
+external interfaces, or a combination of both. Whatever strategy is used the
+evaluator will consider its appropriateness for adequately testing the
+interfaces. Specifically the evaluator determines whether testing at the
+internal interfaces is necessary or whether these internal interfaces can be
+adequately tested (albeit implicitly) by exercising the external interfaces.
+This determination is left to the evaluator, as is its justification.
+
+
+ATE_DPT.3.2C _**The analysis of the depth of testing shall demonstrate that all TSF**_
+_**subsystems in the TOE design have been tested.**_
+
+
+ATE_DPT.3-6 The evaluator _**shall examine**_ the test procedures to determine that all
+descriptions of TSF subsystem behaviour and interaction are tested.
+
+
+1375 This work unit verifies the completeness of work unit ATE_DPT.3-1. All
+descriptions of TSF subsystem behaviour and of interactions among TSF
+subsystems that are provided in the TOE design have to be tested.
+Incomplete depth of testing would be evident if a description of TSF
+subsystem behaviour or of interactions among TSF subsystems was
+identified in the TOE design and no tests could be attributed to it.
+
+
+1376 The evaluator is reminded that this does not imply that all tests in the test
+documentation must map to the subsystem behaviour or interaction
+description in the TOE design.
+
+
+ATE_DPT.3.3C _**The analysis of the depth of testing shall demonstrate that all TSF modules**_
+_**in the TOE design have been tested.**_
+
+
+ATE_DPT.3-7 The evaluator _**shall examine**_ the test procedures to determine that all
+interfaces of all TSF modules are tested.
+
+
+1377 This work unit verifies the completeness of work unit ATE_DPT.3-4. All
+interfaces of TSF modules that are provided in the TOE design have to be
+tested. Incomplete depth of testing would be evident if any interface of any
+TSF module was identified in the TOE design and no tests could be
+attributed to it.
+
+
+April 2017 Version 3.1 Page 293 of 430
+
+
+**Class ATE: Tests**
+
+
+1378 The evaluator is reminded that this does not imply that all tests in the test
+documentation must map to an interface of a TSF module in the TOE design.
+
+
+**15.4.4** **Evaluation of sub-activity (ATE_DPT.4)**
+
+
+1379 There is no general guidance; the scheme should be consulted for guidance
+on this sub-activity.
+
+
+Page 294 of 430 Version 3.1 April 2017
+
+
+**Class ATE: Tests**
+
+## **15.5 Functional tests (ATE_FUN)**
+
+
+**15.5.1** **Evaluation of sub-activity (ATE_FUN.1)**
+
+
+15.5.1.1 Objectives
+
+
+1380 The objective of this sub-activity is to determine whether the developer
+correctly performed and documented the tests in the test documentation.
+
+
+15.5.1.2 Input
+
+
+1381 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the functional specification;
+
+
+c) the test documentation.
+
+
+15.5.1.3 Application notes
+
+
+1382 The extent to which the test documentation is required to cover the TSF is
+dependent upon the coverage assurance component.
+
+
+1383 For the developer tests provided, the evaluator determines whether the tests
+are repeatable, and the extent to which the developer's tests can be used for
+the evaluator's independent testing effort. Any TSFI for which the
+developer's test results indicate that it might not perform as specified should
+be tested independently by the evaluator to determine whether or not it does.
+
+
+15.5.1.4 Action ATE_FUN.1.1E
+
+
+ATE_FUN.1.1C _**The test documentation shall consist of test plans, expected test results and**_
+_**actual test results.**_
+
+
+ATE_FUN.1-1 The evaluator _**shall check**_ that the test documentation includes test plans,
+expected test results and actual test results.
+
+
+1384 The evaluator checks that test plans, expected tests results and actual test
+results are included in the test documentation.
+
+
+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-2 The evaluator _**shall examine**_ the test plan to determine that it describes the
+scenarios for performing each test.
+
+
+1385 The evaluator determines that the test plan provides information about the
+test configuration being used: both on the configuration of the TOE and on
+any test equipment being used. This information should be detailed enough
+to ensure that the test configuration is reproducible.
+
+
+April 2017 Version 3.1 Page 295 of 430
+
+
+**Class ATE: Tests**
+
+
+1386 The evaluator also determines that the test plan provides information about
+how to execute the test: any necessary automated set-up procedures (and
+whether they require privilege to run), inputs to be applied, how these inputs
+are applied, how output is obtained, any automated clean-up procedures (and
+whether they require privilege to run), etc. This information should be
+detailed enough to ensure that the test is reproducible.
+
+
+1387 The evaluator may wish to employ a sampling strategy when performing this
+work unit.
+
+
+ATE_FUN.1-3 The evaluator _**shall examine**_ the test plan to determine that the TOE test
+configuration is consistent with the ST.
+
+
+1388 The TOE referred to in the developer's test plan should have the same unique
+reference as established by the CM capabilities (ALC_CMC) sub-activities
+and identified in the ST introduction.
+
+
+1389 It is possible for the ST to specify more than one configuration for evaluation.
+The evaluator verifies that all test configurations identified in the developer
+test documentation are consistent with the ST. For example, the ST might
+define configuration options that must be set, which could have an impact
+upon what constitutes the TOE by including or excluding additional portions.
+The evaluator verifies that all such variations of the TOE are considered.
+
+
+1390 The evaluator should consider the security objectives for the operational
+environment described in the ST that may apply to the test environment.
+There may be some objectives for the operational environment that do not
+apply to the test environment. For example, an objective about user
+clearances may not apply; however, an objective about a single point of
+connection to a network would apply.
+
+
+1391 The evaluator may wish to employ a sampling strategy when performing this
+work unit.
+
+
+1392 If this work unit is applied to a component TOE that might be
+used/integrated in a composed TOE (see Class ACO: Composition), the
+following will apply. In the instances that the component TOE under
+evaluation depends on other components in the operational environment to
+support their operation, the developer may wish to consider using the other
+component(s) that will be used in the composed TOE to fulfil the
+requirements of the operational environment as one of the test configurations.
+This will reduce the amount an additional testing that will be required for the
+composed TOE evaluation.
+
+
+ATE_FUN.1-4 The evaluator _**shall examine**_ the test plans to determine that sufficient
+instructions are provided for any ordering dependencies.
+
+
+1393 Some steps may have to be performed to establish initial conditions. For
+example, user accounts need to be added before they can be deleted. An
+example of ordering dependencies on the results of other tests is the need to
+perform actions in a test that will result in the generation of audit records,
+
+
+Page 296 of 430 Version 3.1 April 2017
+
+
+**Class ATE: Tests**
+
+
+before performing a test to consider the searching and sorting of those audit
+records. Another example of an ordering dependency would be where one
+test case generates a file of data to be used as input for another test case.
+
+
+1394 The evaluator may wish to employ a sampling strategy when performing this
+work unit.
+
+
+ATE_FUN.1.3C _**The expected test results shall show the anticipated outputs from a**_
+_**successful execution of the tests.**_
+
+
+ATE_FUN.1-5 The evaluator _**shall examine**_ the test documentation to determine that all
+expected tests results are included.
+
+
+1395 The expected test results are needed to determine whether or not a test has
+been successfully performed. Expected test results are sufficient if they are
+unambiguous and consistent with expected behaviour given the testing
+approach.
+
+
+1396 The evaluator may wish to employ a sampling strategy when performing this
+work unit.
+
+
+ATE_FUN.1.4C _**The actual test results shall be consistent with the expected test results.**_
+
+
+ATE_FUN.1-6 The evaluator _**shall check**_ that the actual test results in the test
+documentation are consistent with the expected test results in the test
+documentation.
+
+
+1397 A comparison of the actual and expected test results provided by the
+developer will reveal any inconsistencies between the results. It may be that
+a direct comparison of actual results cannot be made until some data
+reduction or synthesis has been first performed. In such cases, the
+developer's test documentation should describe the process to reduce or
+synthesise the actual data.
+
+
+1398 For example, the developer may need to test the contents of a message buffer
+after a network connection has occurred to determine the contents of the
+buffer. The message buffer will contain a binary number. This binary number
+would have to be converted to another form of data representation in order to
+make the test more meaningful. The conversion of this binary representation
+of data into a higher-level representation will have to be described by the
+developer in enough detail to allow an evaluator to perform the conversion
+process (i.e. synchronous or asynchronous transmission, number of stop bits,
+parity, etc.).
+
+
+1399 It should be noted that the description of the process used to reduce or
+synthesise the actual data is used by the evaluator not to actually perform the
+necessary modification but to assess whether this process is correct. It is up
+to the developer to transform the expected test results into a format that
+allows an easy comparison with the actual test results.
+
+
+April 2017 Version 3.1 Page 297 of 430
+
+
+**Class ATE: Tests**
+
+
+1400 The evaluator may wish to employ a sampling strategy when performing this
+work unit.
+
+
+ATE_FUN.1-7 The evaluator _**shall report**_ the developer testing effort, outlining the testing
+approach, configuration, depth and results.
+
+
+1401 The developer testing information recorded in the ETR allows the evaluator
+to convey the overall testing approach and effort expended on the testing of
+the TOE by the developer. The intent of providing this information is to give
+a meaningful overview of the developer testing effort. It is not intended that
+the information regarding developer testing in the ETR be an exact
+reproduction of specific test steps or results of individual tests. The intention
+is to provide enough detail to allow other evaluators and evaluation
+authorities to gain some insight about the developer's testing approach,
+amount of testing performed, TOE test configurations, and the overall results
+of the developer testing.
+
+
+1402 Information that would typically be found in the ETR section regarding the
+developer testing effort is:
+
+
+a) TOE test configurations. The particular configurations of the TOE
+that were tested, including whether any privileged code was required
+to set up the test or clean up afterwards;
+
+
+b) testing approach. An account of the overall developer testing strategy
+employed;
+
+
+c) testing results. A description of the overall developer testing results.
+
+
+1403 This list is by no means exhaustive and is only intended to provide some
+context as to the type of information that should be present in the ETR
+concerning the developer testing effort.
+
+
+**15.5.2** **Evaluation of sub-activity (ATE_FUN.2)**
+
+
+1404 There is no general guidance; the scheme should be consulted for guidance
+on this sub-activity.
+
+
+Page 298 of 430 Version 3.1 April 2017
+
+
+**Class ATE: Tests**
+
+## **15.6 Independent testing (ATE_IND)**
+
+
+**15.6.1** **Evaluation of sub-activity (ATE_IND.1)**
+
+
+15.6.1.1 Objectives
+
+
+1405 The goal of this activity is to determine, by independently testing a subset of
+the TSFI, whether the TOE behaves as specified in the functional
+specification and guidance documentation.
+
+
+15.6.1.2 Input
+
+
+1406 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the functional specification;
+
+
+c) the operational user guidance;
+
+
+d) the preparative user guidance;
+
+
+e) the TOE suitable for testing.
+
+
+15.6.1.3 Action ATE_IND.1.1E
+
+
+ATE_IND.1.1C _**The TOE shall be suitable for testing.**_
+
+
+ATE_IND.1-1 The evaluator _**shall examine**_ the TOE to determine that the test configuration
+is consistent with the configuration under evaluation as specified in the ST.
+
+
+1407 The TOE provided by the developer should have the same unique reference
+as established by the CM capabilities (ALC_CMC) sub-activities and
+identified in the ST introduction.
+
+
+1408 It is possible for the ST to specify more than one configuration for evaluation.
+The TOE may comprise a number of distinct hardware and software entities
+that need to be tested in accordance with the ST. The evaluator verifies that
+all test configurations are consistent with the ST.
+
+
+1409 The evaluator should consider the security objectives for the operational
+environment described in the ST that may apply to the test environment and
+ensure they are met in the testing environment. There may be some
+objectives for the operational environment that do not apply to the test
+environment. For example, an objective about user clearances may not apply;
+however, an objective about a single point of connection to a network would
+apply.
+
+
+1410 If any test resources are used (e.g. meters, analysers) it will be the evaluator's
+responsibility to ensure that these resources are calibrated correctly.
+
+
+April 2017 Version 3.1 Page 299 of 430
+
+
+**Class ATE: Tests**
+
+
+ATE_IND.1-2 The evaluator _**shall examine**_ the TOE to determine that it has been installed
+properly and is in a known state.
+
+
+1411 It is possible for the evaluator to determine the state of the TOE in a number
+of ways. For example, previous successful completion of the Evaluation of
+sub-activity (AGD_PRE.1) sub-activity will satisfy this work unit if the
+evaluator still has confidence that the TOE being used for testing was
+installed properly and is in a known state. If this is not the case, then the
+evaluator should follow the developer's procedures to install and start up the
+TOE, using the supplied guidance only.
+
+
+1412 If the evaluator has to perform the installation procedures because the TOE is
+in an unknown state, this work unit when successfully completed could
+satisfy work unit AGD_PRE.1-3.
+
+
+15.6.1.4 Action ATE_IND.1.2E
+
+
+ATE_IND.1-3 The evaluator _**shall devise**_ a test subset.
+
+
+1413 The evaluator selects a test subset and testing strategy that is appropriate for
+the TOE. One extreme testing strategy would be to have the test subset
+contain as many interfaces as possible tested with little rigour. Another
+testing strategy would be to have the test subset contain a few interfaces
+based on their perceived relevance and rigorously test these interfaces.
+
+
+1414 Typically the testing approach taken by the evaluator should fall somewhere
+between these two extremes. The evaluator should exercise most of the
+interfaces using at least one test, but testing need not demonstrate exhaustive
+specification testing.
+
+
+1415 The evaluator, when selecting the subset of the interfaces to be tested, should
+consider the following factors:
+
+
+a) The number of interfaces from which to draw upon for the test subset.
+Where the TSF includes only a small number of relatively simple
+interfaces, it may be practical to rigorously test all of the interfaces.
+In other cases this may not be cost-effective, and sampling is required.
+
+
+b) Maintaining a balance of evaluation activities. The evaluator effort
+expended on the test activity should be commensurate with that
+expended on any other evaluation activity.
+
+
+1416 The evaluator selects the interfaces to compose the subset. This selection will
+depend on a number of factors, and consideration of these factors may also
+influence the choice of test subset size:
+
+
+a) Significance of interfaces. Those interfaces more significant than
+others should be included in the test subset. One major factor of
+โsignificanceโ is the security-relevance (SFR-enforcing interfaces
+would be more significant than SFR-supporting interfaces, which are
+more significant than SFR-non-interfering interfaces; see CC Part 3
+
+
+Page 300 of 430 Version 3.1 April 2017
+
+
+**Class ATE: Tests**
+
+
+Section Functional specification (ADV_FSP)). The other major factor
+of โsignificanceโ is the number of SFRs mapping to this interface (as
+determined when identifying the correspondence between levels of
+abstraction in ADV).
+
+
+b) Complexity of the interface. Complex interfaces may require
+complex tests that impose onerous requirements on the developer or
+evaluator, which may not be conducive to cost-effective evaluations.
+Conversely, they are a likely area to find errors and are good
+candidates for the subset. The evaluator will need to strike a balance
+between these considerations.
+
+
+c) Implicit testing. Testing some interfaces may often implicitly test
+other interfaces, and their inclusion in the subset may maximise the
+number of interfaces tested (albeit implicitly). Certain interfaces will
+typically be used to provide a variety of security functionality, and
+will tend to be the target of an effective testing approach.
+
+
+d) Types of interfaces (e.g. programmatic, command-line, protocol).
+The evaluator should consider including tests for all different types of
+interfaces that the TOE supports.
+
+
+e) Interfaces that give rise to features that are innovative or unusual.
+Where the TOE contains innovative or unusual features, which may
+feature strongly in marketing literature and guidance documents, the
+corresponding interfaces should be strong candidates for testing.
+
+
+1417 This guidance articulates factors to consider during the selection process of
+an appropriate test subset, but these are by no means exhaustive.
+
+
+ATE_IND.1-4 The evaluator _**shall produce**_ test documentation for the test subset that is
+sufficiently detailed to enable the tests to be reproducible.
+
+
+1418 With an understanding of the expected behaviour of the TSF, from the ST
+and the functional specification, the evaluator has to determine the most
+feasible way to test the interface. Specifically the evaluator considers:
+
+
+a) the approach that will be used, for instance, whether an external
+interface will be tested, or an internal interface using a test harness, or
+will an alternate test approach be employed (e.g. in exceptional
+circumstances, a code inspection, if the implementation
+representation is available);
+
+
+b) the interface(s) that will be used to test and observe responses;
+
+
+c) the initial conditions that will need to exist for the test (i.e. any
+particular objects or subjects that will need to exist and security
+attributes they will need to have);
+
+
+April 2017 Version 3.1 Page 301 of 430
+
+
+**Class ATE: Tests**
+
+
+d) special test equipment that will be required to either stimulate an
+interface (e.g. packet generators) or make observations of an interface
+(e.g. network analysers).
+
+
+1419 The evaluator may find it practical to test each interface using a series of test
+cases, where each test case will test a very specific aspect of expected
+behaviour.
+
+
+1420 The evaluator's test documentation should specify the derivation of each test,
+tracing it back to the relevant interface(s).
+
+
+ATE_IND.1-5 The evaluator _**shall conduct**_ testing.
+
+
+1421 The evaluator uses the test documentation developed as a basis for executing
+tests on the TOE. The test documentation is used as a basis for testing but
+this does not preclude the evaluator from performing additional ad hoc tests.
+The evaluator may devise new tests based on behaviour of the TOE
+discovered during testing. These new tests are recorded in the test
+documentation.
+
+
+ATE_IND.1-6 The evaluator _**shall record**_ the following information about the tests that
+compose the test subset:
+
+
+a) identification of the interface behaviour to be tested;
+
+
+b) instructions to connect and setup all required test equipment as
+required to conduct the test;
+
+
+c) instructions to establish all prerequisite test conditions;
+
+
+d) instructions to stimulate the interface;
+
+
+e) instructions for observing the behaviour of the interface;
+
+
+f) descriptions of all expected results and the necessary analysis to be
+performed on the observed behaviour for comparison against
+expected results;
+
+
+g) instructions to conclude the test and establish the necessary post-test
+state for the TOE;
+
+
+h) actual test results.
+
+
+1422 The level of detail should be such that another evaluator could repeat the
+tests and obtain an equivalent result. While some specific details of the test
+results may be different (e.g. time and date fields in an audit record) the
+overall result should be identical.
+
+
+1423 There may be instances when it is unnecessary to provide all the information
+presented in this work unit (e.g. the actual test results of a test may not
+require any analysis before a comparison between the expected results can be
+
+
+Page 302 of 430 Version 3.1 April 2017
+
+
+**Class ATE: Tests**
+
+
+made). The determination to omit this information is left to the evaluator, as
+is the justification.
+
+
+ATE_IND.1-7 The evaluator _**shall check**_ that all actual test results are consistent with the
+expected test results.
+
+
+1424 Any differences in the actual and expected test results may indicate that the
+TOE does not perform as specified or that the evaluator test documentation
+may be incorrect. Unexpected actual results may require corrective
+maintenance to the TOE or test documentation and perhaps require rerunning of impacted tests and modifying the test sample size and
+composition. This determination is left to the evaluator, as is its justification.
+
+
+ATE_IND.1-8 The evaluator _**shall report**_ in the ETR the evaluator testing effort, outlining
+the testing approach, configuration, depth and results.
+
+
+1425 The evaluator testing information reported in the ETR allows the evaluator to
+convey the overall testing approach and effort expended on the testing
+activity during the evaluation. The intent of providing this information is to
+give a meaningful overview of the testing effort. It is not intended that the
+information regarding testing in the ETR be an exact reproduction of specific
+test instructions or results of individual tests. The intention is to provide
+enough detail to allow other evaluators and evaluation authorities to gain
+some insight about the testing approach chosen, amount of testing performed,
+TOE test configurations, and the overall results of the testing activity.
+
+
+1426 Information that would typically be found in the ETR section regarding the
+evaluator testing effort is:
+
+
+a) TOE test configurations. The particular configurations of the TOE
+that were tested;
+
+
+b) subset size chosen. The amount of interfaces that were tested during
+the evaluation and a justification for the size;
+
+
+c) selection criteria for the interfaces that compose the subset. Brief
+statements about the factors considered when selecting interfaces for
+inclusion in the subset;
+
+
+d) interfaces tested. A brief listing of the interfaces that merited
+inclusion in the subset;
+
+
+e) verdict for the activity. The overall judgement on the results of
+testing during the evaluation.
+
+
+1427 This list is by no means exhaustive and is only intended to provide some
+context as to the type of information that should be present in the ETR
+concerning the testing the evaluator performed during the evaluation.
+
+
+April 2017 Version 3.1 Page 303 of 430
+
+
+**Class ATE: Tests**
+
+
+**15.6.2** **Evaluation of sub-activity (ATE_IND.2)**
+
+
+15.6.2.1 Objectives
+
+
+1428 The goal of this activity is to determine, by independently testing a subset of
+the TSF, whether the TOE behaves as specified in the design documentation,
+and to gain confidence in the developer's test results by performing a sample
+of the developer's tests.
+
+
+15.6.2.2 Input
+
+
+1429 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the functional specification;
+
+
+c) the TOE design description;
+
+
+d) the operational user guidance;
+
+
+e) the preparative user guidance;
+
+
+f) the configuration management documentation;
+
+
+g) the test documentation;
+
+
+h) the TOE suitable for testing.
+
+
+15.6.2.3 Action ATE_IND.2.1E
+
+
+ATE_IND.2.1C _**The TOE shall be suitable for testing.**_
+
+
+ATE_IND.2-1 The evaluator _**shall examine**_ the TOE to determine that the test configuration
+is consistent with the configuration under evaluation as specified in the ST.
+
+
+1430 The TOE provided by the developer and identified in the test plan should
+have the same unique reference as established by the CM capabilities
+(ALC_CMC) sub-activities and identified in the ST introduction.
+
+
+1431 It is possible for the ST to specify more than one configuration for evaluation.
+The TOE may comprise a number of distinct hardware and software entities
+that need to be tested in accordance with the ST. The evaluator verifies that
+all test configurations are consistent with the ST.
+
+
+1432 The evaluator should consider the security objectives for the operational
+environment described in the ST that may apply to the test environment and
+ensure they are met in the testing environment. There may be some
+objectives for the operational environment that do not apply to the test
+environment. For example, an objective about user clearances may not apply;
+however, an objective about a single point of connection to a network would
+apply.
+
+
+Page 304 of 430 Version 3.1 April 2017
+
+
+**Class ATE: Tests**
+
+
+1433 If any test resources are used (e.g. meters, analysers) it will be the evaluator's
+responsibility to ensure that these resources are calibrated correctly.
+
+
+ATE_IND.2-2 The evaluator _**shall examine**_ the TOE to determine that it has been installed
+properly and is in a known state.
+
+
+1434 It is possible for the evaluator to determine the state of the TOE in a number
+of ways. For example, previous successful completion of the Evaluation of
+sub-activity (AGD_PRE.1) sub-activity will satisfy this work unit if the
+evaluator still has confidence that the TOE being used for testing was
+installed properly and is in a known state. If this is not the case, then the
+evaluator should follow the developer's procedures to install and start up the
+TOE, using the supplied guidance only.
+
+
+1435 If the evaluator has to perform the installation procedures because the TOE is
+in an unknown state, this work unit when successfully completed could
+satisfy work unit AGD_PRE.1-3.
+
+
+ATE_IND.2.2C _**The developer shall provide an equivalent set of resources to those that**_
+_**were used in the developer's functional testing of the TSF.**_
+
+
+ATE_IND.2-3 The evaluator _**shall examine**_ the set of resources provided by the developer
+to determine that they are equivalent to the set of resources used by the
+developer to functionally test the TSF.
+
+
+1436 The set of resource used by the developer is documented in the developer test
+plan, as considered in the Functional tests (ATE_FUN) family. The resource
+set may include laboratory access and special test equipment, among others.
+Resources that are not identical to those used by the developer need to be
+equivalent in terms of any impact they may have on test results.
+
+
+15.6.2.4 Action ATE_IND.2.2E
+
+
+ATE_IND.2-4 The evaluator _**shall conduct**_ testing using a sample of tests found in the
+developer test plan and procedures.
+
+
+1437 The overall aim of this work unit is to perform a sufficient number of the
+developer tests to confirm the validity of the developer's test results. The
+evaluator has to decide on the size of the sample, and the developer tests that
+will compose the sample (see A.2).
+
+
+1438 All the developer tests can be traced back to specific interfaces. Therefore,
+the factors to consider in the selection of the tests to compose the sample are
+similar to those listed for subset selection in work-unit ATE_IND.2-6.
+Additionally, the evaluator may wish to employ a random sampling method
+to select developer tests to include in the sample.
+
+
+ATE_IND.2-5 The evaluator _**shall check**_ that all the actual test results are consistent with
+the expected test results.
+
+
+1439 Inconsistencies between the developer's expected test results and actual test
+results will compel the evaluator to resolve the discrepancies. Inconsistencies
+
+
+April 2017 Version 3.1 Page 305 of 430
+
+
+**Class ATE: Tests**
+
+
+encountered by the evaluator could be resolved by a valid explanation and
+resolution of the inconsistencies by the developer.
+
+
+1440 If a satisfactory explanation or resolution can not be reached, the evaluator's
+confidence in the developer's test results may be lessened and it may be
+necessary for the evaluator to increase the sample size to the extent that the
+subset identified in work unit ATE_IND.2-4 is adequately tested:
+deficiencies with the developer's tests need to result in either corrective
+action to the TOE by the developer (e.g., if the inconsistency is caused by
+incorrect behaviour) or to the developer's tests (e.g., if the inconsistency is
+caused by an incorrect test), or in the production of new tests by the
+evaluator.
+
+
+15.6.2.5 Action ATE_IND.2.3E
+
+
+ATE_IND.2-6 The evaluator _**shall devise**_ a test subset.
+
+
+1441 The evaluator selects a test subset and testing strategy that is appropriate for
+the TOE. One extreme testing strategy would be to have the test subset
+contain as many interfaces as possible tested with little rigour. Another
+testing strategy would be to have the test subset contain a few interfaces
+based on their perceived relevance and rigorously test these interfaces.
+
+
+1442 Typically the testing approach taken by the evaluator should fall somewhere
+between these two extremes. The evaluator should exercise most of the
+interfaces using at least one test, but testing need not demonstrate exhaustive
+specification testing.
+
+
+1443 The evaluator, when selecting the subset of the interfaces to be tested, should
+consider the following factors:
+
+
+a) The developer test evidence. The developer test evidence consists of:
+the test documentation, the available test coverage analysis, and the
+available depth of testing analysis. The developer test evidence will
+provide insight as to how the TSF has been exercised by the
+developer during testing. The evaluator applies this information when
+developing new tests to independently test the TOE. Specifically the
+evaluator should consider:
+
+
+1) augmentation of developer testing for interfaces. The
+evaluator may wish to perform more of the same type of tests
+by varying parameters to more rigorously test the interface.
+
+
+2) supplementation of developer testing strategy for interfaces.
+The evaluator may wish to vary the testing approach of a
+specific interface by testing it using another test strategy.
+
+
+b) The number of interfaces from which to draw upon for the test subset.
+Where the TSF includes only a small number of relatively simple
+interfaces, it may be practical to rigorously test all of them. In other
+cases this may not be cost-effective, and sampling is required.
+
+
+Page 306 of 430 Version 3.1 April 2017
+
+
+**Class ATE: Tests**
+
+
+c) Maintaining a balance of evaluation activities. The evaluator effort
+expended on the test activity should be commensurate with that
+expended on any other evaluation activity.
+
+
+1444 The evaluator selects the interfaces to compose the subset. This selection will
+depend on a number of factors, and consideration of these factors may also
+influence the choice of test subset size:
+
+
+a) Rigour of developer testing of the interfaces. Those interfaces that the
+evaluator determines require additional testing should be included in
+the test subset.
+
+
+b) Developer test results. If the results of developer tests cause the
+evaluator to doubt that an interface is not properly implemented, then
+the evaluator should include such interfaces in the test subset.
+
+
+c) Significance of interfaces. Those interfaces more significant than
+others should be included in the test subset. One major factor of
+โsignificanceโ is the security-relevance (SFR-enforcing interfaces
+would be more significant than SFR-supporting interfaces, which are
+more significant than SFR-non-interfering interfaces; see CC Part 3
+Section ADV_FSP). The other major factor of โsignificanceโ is the
+number of SFRs mapping to this interface (as determined when
+identifying the correspondence between levels of abstraction in
+ADV).
+
+
+d) Complexity of interfaces. Interfaces that require complex
+implementation may require complex tests that impose onerous
+requirements on the developer or evaluator, which may not be
+conducive to cost-effective evaluations. Conversely, they are a likely
+area to find errors and are good candidates for the subset. The
+evaluator will need to strike a balance between these considerations.
+
+
+e) Implicit testing. Testing some interfaces may often implicitly test
+other interfaces, and their inclusion in the subset may maximise the
+number of interfaces tested (albeit implicitly). Certain interfaces will
+typically be used to provide a variety of security functionality, and
+will tend to be the target of an effective testing approach.
+
+
+f) Types of interfaces (e.g. programmatic, command-line, protocol).
+The evaluator should consider including tests for all different types of
+interfaces that the TOE supports.
+
+
+g) Interfaces that give rise to features that are innovative or unusual.
+Where the TOE contains innovative or unusual features, which may
+feature strongly in marketing literature and guidance documents, the
+corresponding interfaces should be strong candidates for testing.
+
+
+1445 This guidance articulates factors to consider during the selection process of
+an appropriate test subset, but these are by no means exhaustive.
+
+
+April 2017 Version 3.1 Page 307 of 430
+
+
+**Class ATE: Tests**
+
+
+ATE_IND.2-7 The evaluator _**shall produce**_ test documentation for the test subset that is
+sufficiently detailed to enable the tests to be reproducible.
+
+
+1446 With an understanding of the expected behaviour of the TSF, from the ST,
+the functional specification, and the TOE design description, the evaluator
+has to determine the most feasible way to test the interface. Specifically the
+evaluator considers:
+
+
+a) the approach that will be used, for instance, whether an external
+interface will be tested, or an internal interface using a test harness, or
+will an alternate test approach be employed (e.g. in exceptional
+circumstances, a code inspection);
+
+
+b) the interface(s) that will be used to test and observe responses;
+
+
+c) the initial conditions that will need to exist for the test (i.e. any
+particular objects or subjects that will need to exist and security
+attributes they will need to have);
+
+
+d) special test equipment that will be required to either stimulate an
+interface (e.g. packet generators) or make observations of an interface
+(e.g. network analysers).
+
+
+1447 The evaluator may find it practical to test each interface using a series of test
+cases, where each test case will test a very specific aspect of expected
+behaviour of that interface.
+
+
+1448 The evaluator's test documentation should specify the derivation of each test,
+tracing it back to the relevant interface(s).
+
+
+ATE_IND.2-8 The evaluator _**shall conduct**_ testing.
+
+
+1449 The evaluator uses the test documentation developed as a basis for executing
+tests on the TOE. The test documentation is used as a basis for testing but
+this does not preclude the evaluator from performing additional ad hoc tests.
+The evaluator may devise new tests based on behaviour of the TOE
+discovered during testing. These new tests are recorded in the test
+documentation.
+
+
+ATE_IND.2-9 The evaluator _**shall record**_ the following information about the tests that
+compose the test subset:
+
+
+a) identification of the interface behaviour to be tested;
+
+
+b) instructions to connect and setup all required test equipment as
+required to conduct the test;
+
+
+c) instructions to establish all prerequisite test conditions;
+
+
+d) instructions to stimulate the interface;
+
+
+e) instructions for observing the interface;
+
+
+Page 308 of 430 Version 3.1 April 2017
+
+
+**Class ATE: Tests**
+
+
+f) descriptions of all expected results and the necessary analysis to be
+performed on the observed behaviour for comparison against
+expected results;
+
+
+g) instructions to conclude the test and establish the necessary post-test
+state for the TOE;
+
+
+h) actual test results.
+
+
+1450 The level of detail should be such that another evaluator could repeat the
+tests and obtain an equivalent result. While some specific details of the test
+results may be different (e.g. time and date fields in an audit record) the
+overall result should be identical.
+
+
+1451 There may be instances when it is unnecessary to provide all the information
+presented in this work unit (e.g. the actual test results of a test may not
+require any analysis before a comparison between the expected results can be
+made). The determination to omit this information is left to the evaluator, as
+is the justification.
+
+
+ATE_IND.2-10 The evaluator _**shall check**_ that all actual test results are consistent with the
+expected test results.
+
+
+1452 Any differences in the actual and expected test results may indicate that the
+TOE does not perform as specified or that the evaluator test documentation
+may be incorrect. Unexpected actual results may require corrective
+maintenance to the TOE or test documentation and perhaps require rerunning of impacted tests and modifying the test sample size and
+composition. This determination is left to the evaluator, as is its justification.
+
+
+ATE_IND.2-11 The evaluator _**shall report**_ in the ETR the evaluator testing effort, outlining
+the testing approach, configuration, depth and results.
+
+
+1453 The evaluator testing information reported in the ETR allows the evaluator to
+convey the overall testing approach and effort expended on the testing
+activity during the evaluation. The intent of providing this information is to
+give a meaningful overview of the testing effort. It is not intended that the
+information regarding testing in the ETR be an exact reproduction of specific
+test instructions or results of individual tests. The intention is to provide
+enough detail to allow other evaluators and evaluation authorities to gain
+some insight about the testing approach chosen, amount of evaluator testing
+performed, amount of developer tests performed, TOE test configurations,
+and the overall results of the testing activity.
+
+
+1454 Information that would typically be found in the ETR section regarding the
+evaluator testing effort is:
+
+
+a) TOE test configurations. The particular configurations of the TOE
+that were tested.
+
+
+April 2017 Version 3.1 Page 309 of 430
+
+
+**Class ATE: Tests**
+
+
+b) subset size chosen. The amount of interfaces that were tested during
+the evaluation and a justification for the size.
+
+
+c) selection criteria for the interfaces that compose the subset. Brief
+statements about the factors considered when selecting interfaces for
+inclusion in the subset.
+
+
+d) Interfaces tested. A brief listing of the interfaces that merited
+inclusion in the subset.
+
+
+e) developer tests performed. The amount of developer tests performed
+and a brief description of the criteria used to select the tests.
+
+
+f) verdict for the activity. The overall judgement on the results of
+testing during the evaluation.
+
+
+1455 This list is by no means exhaustive and is only intended to provide some
+context as to the type of information that should be present in the ETR
+concerning the testing the evaluator performed during the evaluation.
+
+
+**15.6.3** **Evaluation of sub-activity (ATE_IND.3)**
+
+
+1456 There is no general guidance; the scheme should be consulted for guidance
+on this sub-activity.
+
+
+Page 310 of 430 Version 3.1 April 2017
+
+
+**Class AVA: Vulnerability assessment**
+
+# **16 Class AVA: Vulnerability assessment**
+
+## **16.1 Introduction**
+
+
+1457 The purpose of the vulnerability assessment activity is to determine the
+exploitability of flaws or weaknesses in the TOE in the operational
+environment. This determination is based upon analysis of the evaluation
+evidence and a search of publicly available material by the evaluator and is
+supported by evaluator penetration testing.
+
+
+April 2017 Version 3.1 Page 311 of 430
+
+
+**Class AVA: Vulnerability assessment**
+
+## **16.2 Vulnerability analysis (AVA_VAN)**
+
+
+**16.2.1** **Evaluation of sub-activity (AVA_VAN.1)**
+
+
+16.2.1.1 Objectives
+
+
+1458 The objective of this sub-activity is to determine whether the TOE, in its
+operational environment, has easily identifiable exploitable vulnerabilities.
+
+
+16.2.1.2 Input
+
+
+1459 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the guidance documentation;
+
+
+c) the TOE suitable for testing;
+
+
+d) information publicly available to support the identification of
+potential vulnerabilities.
+
+
+1460 Other input for this sub-activity is:
+
+
+a) current information regarding potential vulnerabilities (e.g. from an
+evaluation authority).
+
+
+16.2.1.3 Application notes
+
+
+1461 The evaluator should consider performing additional tests as a result of
+potential vulnerabilities encountered during the conduct of other parts of the
+evaluation.
+
+
+1462 The use of the term guidance in this sub-activity refers to the operational
+guidance and the preparative guidance.
+
+
+1463 Potential vulnerabilities may be in information that is publicly available, or
+not, and may require skill to exploit, or not. These two aspects are related,
+but are distinct. It should not be assumed that, simply because a potential
+vulnerability is identifiable from information that is publicly available, it can
+be easily exploited.
+
+
+16.2.1.4 Action AVA_VAN.1.1E
+
+
+AVA_VAN.1.1C _**The TOE shall be suitable for testing.**_
+
+
+AVA_VAN.1-1 The evaluator _**shall examine**_ the TOE to determine that the test configuration
+is consistent with the configuration under evaluation as specified in the ST.
+
+
+1464 The TOE provided by the developer and identified in the test plan should
+have the same unique reference as established by the CM capabilities
+(ALC_CMC) sub-activities and identified in the ST introduction.
+
+
+Page 312 of 430 Version 3.1 April 2017
+
+
+**Class AVA: Vulnerability assessment**
+
+
+1465 It is possible for the ST to specify more than one configuration for evaluation.
+The TOE may comprise a number of distinct hardware and software entities
+that need to be tested in accordance with the ST. The evaluator verifies that
+all test configurations are consistent with the ST.
+
+
+1466 The evaluator should consider the security objectives for the operational
+environment described in the ST that may apply to the test environment and
+ensure they are met in the testing environment. There may be some
+objectives for the operational environment that do not apply to the test
+environment. For example, an objective about user clearances may not apply;
+however, an objective about a single point of connection to a network would
+apply.
+
+
+1467 If any test resources are used (e.g. meters, analysers) it will be the evaluator's
+responsibility to ensure that these resources are calibrated correctly.
+
+
+AVA_VAN.1-2 The evaluator _**shall examine**_ the TOE to determine that it has been installed
+properly and is in a known state
+
+
+1468 It is possible for the evaluator to determine the state of the TOE in a number
+of ways. For example, previous successful completion of the Evaluation of
+sub-activity (AGD_PRE.1) sub-activity will satisfy this work unit if the
+evaluator still has confidence that the TOE being used for testing was
+installed properly and is in a known state. If this is not the case, then the
+evaluator should follow the developer's procedures to install and start up the
+TOE, using the supplied guidance only.
+
+
+1469 If the evaluator has to perform the installation procedures because the TOE is
+in an unknown state, this work unit when successfully completed could
+satisfy work unit AGD_PRE.1-3.
+
+
+16.2.1.5 Action AVA_VAN.1.2E
+
+
+AVA_VAN.1-3 The evaluator _**shall examine**_ sources of information publicly available to
+identify potential vulnerabilities in the TOE.
+
+
+1470 The evaluator examines the sources of information publicly available to
+support the identification of possible potential vulnerabilities in the TOE.
+There are many sources of publicly available information, which should be
+considered, e.g. mailing lists and security forums on the world wide web that
+report known vulnerabilities in specified technologies.
+
+
+1471 The evaluator should not constrain their consideration of publicly available
+information to the above, but should consider any other relevant information
+available.
+
+
+1472 While examining the evidence provided the evaluator will use the
+information in the public domain to further search for potential
+vulnerabilities. Where the evaluators have identified areas of concern, the
+evaluator should consider information publicly available that relate to those
+areas of concern.
+
+
+April 2017 Version 3.1 Page 313 of 430
+
+
+**Class AVA: Vulnerability assessment**
+
+
+1473 The availability of information that may be readily available to an attacker
+that helps to identify and facilitate attacks effectively operates to
+substantially enhance the attack potential of a given attacker. The
+accessibility of vulnerability information and sophisticated attack tools on
+the Internet makes it more likely that this information will be used in
+attempts to identify potential vulnerabilities in the TOE and exploit them.
+Modern search tools make such information easily available to the evaluator,
+and the determination of resistance to published potential vulnerabilities and
+well known generic attacks can be achieved in a cost-effective manner.
+
+
+1474 The search of the information publicly available should be focused on those
+sources that refer specifically to the product from which the TOE is derived.
+The extensiveness of this search should consider the following factors: TOE
+type, evaluator experience in this TOE type, expected attack potential and the
+level of ADV evidence available.
+
+
+1475 The identification process is iterative, where the identification of one
+potential vulnerability may lead to identifying another area of concern that
+requires further investigation.
+
+
+1476 The evaluator will report what actions were taken to identify potential
+vulnerabilities in the information publicly available. However, in this type of
+search, the evaluator may not be able to describe the steps in identifying
+potential vulnerabilities before the outset of the examination, as the approach
+may evolve as a result of findings during the search.
+
+
+1477 The evaluator will report the evidence examined in completing the search for
+potential vulnerabilities.
+
+
+AVA_VAN.1-4 The evaluator _**shall record**_ in the ETR the identified potential vulnerabilities
+that are candidates for testing and applicable to the TOE in its operational
+environment.
+
+
+1478 It may be identified that no further consideration of the potential
+vulnerability is required if for example the evaluator identifies that measures
+in the operational environment, either IT or non-IT, prevent exploitation of
+the potential vulnerability in that operational environment. For instance,
+restricting physical access to the TOE to authorised users only may
+effectively render a potential vulnerability to tampering unexploitable.
+
+
+1479 The evaluator records any reasons for exclusion of potential vulnerabilities
+from further consideration if the evaluator determines that the potential
+vulnerability is not applicable in the operational environment. Otherwise the
+evaluator records the potential vulnerability for further consideration.
+
+
+1480 A list of potential vulnerabilities applicable to the TOE in its operational
+environment, which can be used as an input into penetration testing activities,
+shall be reported in the ETR by the evaluators.
+
+
+Page 314 of 430 Version 3.1 April 2017
+
+
+**Class AVA: Vulnerability assessment**
+
+
+16.2.1.6 Action AVA_VAN.1.3E
+
+
+AVA_VAN.1-5 The evaluator _**shall devise**_ penetration tests, based on the independent search
+for potential vulnerabilities.
+
+
+1481 The evaluator prepares for penetration testing as necessary to determine the
+susceptibility of the TOE, in its operational environment, to the potential
+vulnerabilities identified during the search of the sources of information
+publicly available. Any current information provided to the evaluator by a
+third party (e.g. evaluation authority) regarding known potential
+vulnerabilities will be considered by the evaluator, together with any
+encountered potential vulnerabilities resulting from the performance of other
+evaluation activities.
+
+
+1482 The evaluator will probably find it practical to carry out penetration test
+using a series of test cases, where each test case will test for a specific
+potential vulnerability.
+
+
+1483 The evaluator is not expected to test for potential vulnerabilities (including
+those in the public domain) beyond those which required a Basic attack
+potential. In some cases, however, it will be necessary to carry out a test
+before the exploitability can be determined. Where, as a result of evaluation
+expertise, the evaluator discovers a potential vulnerability that is beyond
+Basic attack potential, this is reported in the ETR as a residual vulnerability.
+
+
+AVA_VAN.1-6 The evaluator _**shall produce**_ penetration test documentation for the tests
+based on the list of potential vulnerabilities in sufficient detail to enable the
+tests to be repeatable. The test documentation shall include:
+
+
+a) identification of the potential vulnerability the TOE is being tested
+for;
+
+
+b) instructions to connect and setup all required test equipment as
+required to conduct the penetration test;
+
+
+c) instructions to establish all penetration test prerequisite initial
+conditions;
+
+
+d) instructions to stimulate the TSF;
+
+
+e) instructions for observing the behaviour of the TSF;
+
+
+f) descriptions of all expected results and the necessary analysis to be
+performed on the observed behaviour for comparison against
+expected results;
+
+
+g) instructions to conclude the test and establish the necessary post-test
+state for the TOE.
+
+
+1484 The evaluator prepares for penetration testing based on the list of potential
+vulnerabilities identified during the search of the public domain.
+
+
+April 2017 Version 3.1 Page 315 of 430
+
+
+**Class AVA: Vulnerability assessment**
+
+
+1485 The evaluator is not expected to determine the exploitability for potential
+vulnerabilities beyond those for which a Basic attack potential is required to
+effect an attack. However, as a result of evaluation expertise, the evaluator
+may discover a potential vulnerability that is exploitable only by an attacker
+with greater than Basic attack potential. Such vulnerabilities are to be
+reported in the ETR as residual vulnerabilities.
+
+
+1486 With an understanding of the potential vulnerability, the evaluator
+determines the most feasible way to test for the TOE's susceptibility.
+Specifically the evaluator considers:
+
+
+a) the TSFI or other TOE interface that will be used to stimulate the
+TSF and observe responses;
+
+
+b) initial conditions that will need to exist for the test (i.e. any particular
+objects or subjects that will need to exist and security attributes they
+will need to have);
+
+
+c) special test equipment that will be required to either stimulate a TSFI
+or make observations of a TSFI (although it is unlikely that specialist
+equipment would be required to exploit a potential vulnerability
+assuming a Basic attack potential);
+
+
+d) whether theoretical analysis should replace physical testing,
+particularly relevant where the results of an initial test can be
+extrapolated to demonstrate that repeated attempts of an attack are
+likely to succeed after a given number of attempts.
+
+
+1487 The evaluator will probably find it practical to carry out penetration testing
+using a series of test cases, where each test case will test for a specific
+potential vulnerability.
+
+
+1488 The intent of specifying this level of detail in the test documentation is to
+allow another evaluator to repeat the tests and obtain an equivalent result.
+
+
+AVA_VAN.1-7 The evaluator _**shall conduct**_ penetration testing.
+
+
+1489 The evaluator uses the penetration test documentation resulting from work
+unit AVA_VAN.1-5 as a basis for executing penetration tests on the TOE,
+but this does not preclude the evaluator from performing additional ad hoc
+penetration tests. If required, the evaluator may devise ad hoc tests as a result
+of information learnt during penetration testing that, if performed by the
+evaluator, are to be recorded in the penetration test documentation. Such tests
+may be required to follow up unexpected results or observations, or to
+investigate potential vulnerabilities suggested to the evaluator during the preplanned testing.
+
+
+1490 The evaluator is not expected to test for potential vulnerabilities (including
+those in the public domain) beyond those which required a Basic attack
+potential. In some cases, however, it will be necessary to carry out a test
+before the exploitability can be determined. Where, as a result of evaluation
+
+
+Page 316 of 430 Version 3.1 April 2017
+
+
+**Class AVA: Vulnerability assessment**
+
+
+expertise, the evaluator discovers a potential vulnerability that is beyond
+Basic attack potential, this is reported in the ETR as a residual vulnerability.
+
+
+AVA_VAN.1-8 The evaluator _**shall record**_ the actual results of the penetration tests.
+
+
+1491 While some specific details of the actual test results may be different from
+those expected (e.g. time and date fields in an audit record) the overall result
+should be identical. Any unexpected test results should be investigated. The
+impact on the evaluation should be stated and justified.
+
+
+AVA_VAN.1-9 The evaluator _**shall report**_ in the ETR the evaluator penetration testing effort,
+outlining the testing approach, configuration, depth and results.
+
+
+1492 The penetration testing information reported in the ETR allows the evaluator
+to convey the overall penetration testing approach and effort expended on
+this sub-activity. The intent of providing this information is to give a
+meaningful overview of the evaluator's penetration testing effort. It is not
+intended that the information regarding penetration testing in the ETR be an
+exact reproduction of specific test steps or results of individual penetration
+tests. The intention is to provide enough detail to allow other evaluators and
+evaluation authorities to gain some insight about the penetration testing
+approach chosen, amount of penetration testing performed, TOE test
+configurations, and the overall results of the penetration testing activity.
+
+
+1493 Information that would typically be found in the ETR section regarding
+evaluator penetration testing efforts is:
+
+
+a) TOE test configurations. The particular configurations of the TOE
+that were penetration tested;
+
+
+b) TSFI penetration tested. A brief listing of the TSFI and other TOE
+interfaces that were the focus of the penetration testing;
+
+
+c) verdict for the sub-activity. The overall judgement on the results of
+penetration testing.
+
+
+1494 This list is by no means exhaustive and is only intended to provide some
+context as to the type of information that should be present in the ETR
+concerning the penetration testing the evaluator performed during the
+evaluation.
+
+
+AVA_VAN.1-10 The evaluator _**shall examine**_ the results of all penetration testing to
+determine that the TOE, in its operational environment, is resistant to an
+attacker possessing a Basic attack potential.
+
+
+1495 If the results reveal that the TOE, in its operational environment, has
+vulnerabilities exploitable by an attacker possessing less than EnhancedBasic attack potential, then this evaluator action fails.
+
+
+1496 The guidance in B.4 should be used to determine the attack potential required
+to exploit a particular vulnerability and whether it can therefore be exploited
+in the intended environment. It may not be necessary for the attack potential
+
+
+April 2017 Version 3.1 Page 317 of 430
+
+
+**Class AVA: Vulnerability assessment**
+
+
+to be calculated in every instance, only if there is some doubt as to whether
+or not the vulnerability can be exploited by an attacker possessing an attack
+potential less than Enhanced-Basic.
+
+
+AVA_VAN.1-11 The evaluator _**shall report**_ in the ETR all exploitable vulnerabilities and
+residual vulnerabilities, detailing for each:
+
+
+a) its source (e.g. CEM activity being undertaken when it was conceived,
+known to the evaluator, read in a publication);
+
+
+b) the SFR(s) not met;
+
+
+c) a description;
+
+
+d) whether it is exploitable in its operational environment or not (i.e.
+exploitable or residual).
+
+
+e) the amount of time, level of expertise, level of knowledge of the TOE,
+level of opportunity and the equipment required to perform the
+identified vulnerabilities, and the corresponding values using the
+tables 3 and 4 of Annex B.4.
+
+
+**16.2.2** **Evaluation of sub-activity (AVA_VAN.2)**
+
+
+16.2.2.1 Objectives
+
+
+1497 The objective of this sub-activity is to determine whether the TOE, in its
+operational environment, has vulnerabilities exploitable by attackers
+possessing Basic attack potential.
+
+
+16.2.2.2 Input
+
+
+1498 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the functional specification;
+
+
+c) the TOE design;
+
+
+d) the security architecture description;
+
+
+e) the guidance documentation;
+
+
+f) the TOE suitable for testing;
+
+
+g) information publicly available to support the identification of
+possible potential vulnerabilities.
+
+
+1499 The remaining implicit evaluation evidence for this sub-activity depends on
+the components that have been included in the assurance package. The
+evidence provided for each component is to be used as input in this subactivity.
+
+
+Page 318 of 430 Version 3.1 April 2017
+
+
+**Class AVA: Vulnerability assessment**
+
+
+1500 Other input for this sub-activity is:
+
+
+a) current information regarding public domain potential vulnerabilities
+and attacks (e.g. from an evaluation authority).
+
+
+16.2.2.3 Application notes
+
+
+1501 The evaluator should consider performing additional tests as a result of
+potential vulnerabilities encountered during other parts of the evaluation.
+
+
+16.2.2.4 Action AVA_VAN.2.1E
+
+
+AVA_VAN.2.1C _**The TOE shall be suitable for testing.**_
+
+
+AVA_VAN.2-1 The evaluator _**shall examine**_ the TOE to determine that the test configuration
+is consistent with the configuration under evaluation as specified in the ST.
+
+
+1502 The TOE provided by the developer and identified in the test plan should
+have the same unique reference as established by the CM capabilities
+(ALC_CMC) sub-activities and identified in the ST introduction.
+
+
+1503 It is possible for the ST to specify more than one configuration for evaluation.
+The TOE may comprise a number of distinct hardware and software entities
+that need to be tested in accordance with the ST. The evaluator verifies that
+all test configurations are consistent with the ST.
+
+
+1504 The evaluator should consider the security objectives for the operational
+environment described in the ST that may apply to the test environment and
+ensure they are met in the testing environment. There may be some
+objectives for the operational environment that do not apply to the test
+environment. For example, an objective about user clearances may not apply;
+however, an objective about a single point of connection to a network would
+apply.
+
+
+1505 If any test resources are used (e.g. meters, analysers) it will be the evaluator's
+responsibility to ensure that these resources are calibrated correctly.
+
+
+AVA_VAN.2-2 The evaluator _**shall examine**_ the TOE to determine that it has been installed
+properly and is in a known state
+
+
+1506 It is possible for the evaluator to determine the state of the TOE in a number
+of ways. For example, previous successful completion of the Evaluation of
+sub-activity (AGD_PRE.1) sub-activity will satisfy this work unit if the
+evaluator still has confidence that the TOE being used for testing was
+installed properly and is in a known state. If this is not the case, then the
+evaluator should follow the developer's procedures to install and start up the
+TOE, using the supplied guidance only.
+
+
+1507 If the evaluator has to perform the installation procedures because the TOE is
+in an unknown state, this work unit when successfully completed could
+satisfy work unit AGD_PRE.1-3.
+
+
+April 2017 Version 3.1 Page 319 of 430
+
+
+**Class AVA: Vulnerability assessment**
+
+
+16.2.2.5 Action AVA_VAN.2.2E
+
+
+AVA_VAN.2-3 The evaluator _**shall examine**_ sources of information publicly available to
+identify potential vulnerabilities in the TOE.
+
+
+1508 The evaluator examines the sources of information publicly available to
+support the identification of possible potential vulnerabilities in the TOE.
+There are many sources of publicly available information which the
+evaluator should consider using items such as those available on the world
+wide web, including:
+
+
+a) specialist publications (magazines, books);
+
+
+b) research papers.
+
+
+1509 The evaluator should not constrain their consideration of publicly available
+information to the above, but should consider any other relevant information
+available.
+
+
+1510 While examining the evidence provided the evaluator will use the
+information in the public domain to further search for potential
+vulnerabilities. Where the evaluators have identified areas of concern, the
+evaluator should consider information publicly available that relate to those
+areas of concern.
+
+
+1511 The availability of information that may be readily available to an attacker
+that helps to identify and facilitate attacks may substantially enhance the
+attack potential of a given attacker. The accessibility of vulnerability
+information and sophisticated attack tools on the Internet makes it more
+likely that this information will be used in attempts to identify potential
+vulnerabilities in the TOE and exploit them. Modern search tools make such
+information easily available to the evaluator, and the determination of
+resistance to published potential vulnerabilities and well known generic
+attacks can be achieved in a cost-effective manner.
+
+
+1512 The search of the information publicly available should be focused on those
+sources that refer specifically to the product from which the TOE is derived.
+The extensiveness of this search should consider the following factors: TOE
+type, evaluator experience in this TOE type, expected attack potential and the
+level of ADV evidence available.
+
+
+1513 The identification process is iterative, where the identification of one
+potential vulnerability may lead to identifying another area of concern that
+requires further investigation.
+
+
+1514 The evaluator will report what actions were taken to identify potential
+vulnerabilities in the evidence. However, in this type of search, the evaluator
+may not be able to describe the steps in identifying potential vulnerabilities
+before the outset of the examination, as the approach may evolve as a result
+of findings during the search.
+
+
+Page 320 of 430 Version 3.1 April 2017
+
+
+**Class AVA: Vulnerability assessment**
+
+
+1515 The evaluator will report the evidence examined in completing the search for
+potential vulnerabilities. This selection of evidence may be derived from
+those areas of concern identified by the evaluator, linked to the evidence the
+attacker is assumed to be able to obtain, or according to another rationale
+provided by the evaluator.
+
+
+16.2.2.6 Action AVA_VAN.2.3E
+
+
+AVA_VAN.2-4 The evaluator _**shall conduct**_ a search of ST, guidance documentation,
+functional specification, TOE design and security architecture description
+evidence to identify possible potential vulnerabilities in the TOE.
+
+
+1516 A search of the evidence should be completed whereby specifications and
+documentation for the TOE are analysed and then potential vulnerabilities in
+the TOE are hypothesised, or speculated. The list of hypothesised potential
+vulnerabilities is then prioritised on the basis of the estimated probability that
+a potential vulnerability exists and, assuming an exploitable vulnerability
+does exist the attack potential required to exploit it, and on the extent of
+control or compromise it would provide. The prioritised list of potential
+vulnerabilities is used to direct penetration testing against the TOE.
+
+
+1517 The security architecture description provides the developer vulnerability
+analysis, as it documents how the TSF protects itself from interference from
+untrusted subjects and prevents the bypass of security enforcement
+functionality. Therefore, the evaluator should use this description of the
+protection of the TSF as a basis for the search for possible ways to
+undermine the TSF.
+
+
+1518 Subject to the SFRs the TOE is to meet in the operational environment, the
+evaluator's independent vulnerability analysis should consider generic
+potential vulnerabilities under each of the following headings:
+
+
+a) generic potential vulnerabilities relevant for the type of TOE being
+evaluated, as may be supplied by the evaluation authority;
+
+
+b) bypassing;
+
+
+c) tampering;
+
+
+d) direct attacks;
+
+
+e) monitoring;
+
+
+f) misuse.
+
+
+1519 Items b) - f) are explained in greater detail in Annex B.
+
+
+1520 The security architecture description should be considered in light of each of
+the above generic potential vulnerabilities. Each potential vulnerability
+should be considered to search for possible ways in which to defeat the TSF
+protection and undermine the TSF.
+
+
+April 2017 Version 3.1 Page 321 of 430
+
+
+**Class AVA: Vulnerability assessment**
+
+
+AVA_VAN.2-5 The evaluator _**shall record**_ in the ETR the identified potential vulnerabilities
+that are candidates for testing and applicable to the TOE in its operational
+environment.
+
+
+1521 It may be identified that no further consideration of the potential
+vulnerability is required if for example the evaluator identifies that measures
+in the operational environment, either IT or non-IT, prevent exploitation of
+the potential vulnerability in that operational environment. For instance,
+restricting physical access to the TOE to authorised users only may
+effectively render a potential vulnerability to tampering unexploitable.
+
+
+1522 The evaluator records any reasons for exclusion of potential vulnerabilities
+from further consideration if the evaluator determines that the potential
+vulnerability is not applicable in the operational environment. Otherwise the
+evaluator records the potential vulnerability for further consideration.
+
+
+1523 A list of potential vulnerabilities applicable to the TOE in its operational
+environment, which can be used as an input into penetration testing activities,
+shall be reported in the ETR by the evaluators.
+
+
+16.2.2.7 Action AVA_VAN.2.4E
+
+
+AVA_VAN.2-6 The evaluator _**shall devise**_ penetration tests, based on the independent search
+for potential vulnerabilities.
+
+
+1524 The evaluator prepares for penetration testing as necessary to determine the
+susceptibility of the TOE, in its operational environment, to the potential
+vulnerabilities identified during the search of the sources of information
+publicly available. Any current information provided to the evaluator by a
+third party (e.g. evaluation authority) regarding known potential
+vulnerabilities will be considered by the evaluator, together with any
+encountered potential vulnerabilities resulting from the performance of other
+evaluation activities.
+
+
+1525 The evaluator is reminded that, as for considering the security architecture
+description in the search for vulnerabilities (as detailed in AVA_VAN.2-4),
+testing should be performed to confirm the architectural properties. This is
+likely to require negative tests attempting to disprove the properties of the
+security architecture. In developing the strategy for penetration testing, the
+evaluator will ensure that each of the major characteristics of the security
+architecture description are tested, either in functional testing (as considered
+in 15) or evaluator penetration testing.
+
+
+1526 The evaluator will probably find it practical to carry out penetration test
+using a series of test cases, where each test case will test for a specific
+potential vulnerability.
+
+
+1527 The evaluator is not expected to test for potential vulnerabilities (including
+those in the public domain) beyond those which required a Basic attack
+potential. In some cases, however, it will be necessary to carry out a test
+before the exploitability can be determined. Where, as a result of evaluation
+
+
+Page 322 of 430 Version 3.1 April 2017
+
+
+**Class AVA: Vulnerability assessment**
+
+
+expertise, the evaluator discovers an exploitable vulnerability that is beyond
+Basic attack potential, this is reported in the ETR as a residual vulnerability.
+
+
+1528 Guidance on determining the necessary attack potential to exploit a potential
+vulnerability can be found in Annex B.4.
+
+
+1529 Potential vulnerabilities hypothesised as exploitable only by attackers
+possessing Enhanced-Basic, Moderate or High attack potential do not result
+in a failure of this evaluator action. Where analysis supports the hypothesis,
+these need not be considered further as an input to penetration testing.
+However, such vulnerabilities are reported in the ETR as residual
+vulnerabilities.
+
+
+1530 Potential vulnerabilities hypothesised as exploitable by an attacker
+possessing a Basic attack potential and resulting in a violation of the security
+objectives should be the highest priority potential vulnerabilities comprising
+the list used to direct penetration testing against the TOE.
+
+
+AVA_VAN.2-7 The evaluator _**shall produce**_ penetration test documentation for the tests
+based on the list of potential vulnerabilities in sufficient detail to enable the
+tests to be repeatable. The test documentation shall include:
+
+
+a) identification of the potential vulnerability the TOE is being tested
+for;
+
+
+b) instructions to connect and setup all required test equipment as
+required to conduct the penetration test;
+
+
+c) instructions to establish all penetration test prerequisite initial
+conditions;
+
+
+d) instructions to stimulate the TSF;
+
+
+e) instructions for observing the behaviour of the TSF;
+
+
+f) descriptions of all expected results and the necessary analysis to be
+performed on the observed behaviour for comparison against
+expected results;
+
+
+g) instructions to conclude the test and establish the necessary post-test
+state for the TOE.
+
+
+1531 The evaluator prepares for penetration testing based on the list of potential
+vulnerabilities identified during the search of the public domain and the
+analysis of the evaluation evidence.
+
+
+1532 The evaluator is not expected to determine the exploitability for potential
+vulnerabilities beyond those for which a Basic attack potential is required to
+effect an attack. However, as a result of evaluation expertise, the evaluator
+may discover a potential vulnerability that is exploitable only by an attacker
+with greater than Basic attack potential. Such vulnerabilities are to be
+reported in the ETR as residual vulnerabilities.
+
+
+April 2017 Version 3.1 Page 323 of 430
+
+
+**Class AVA: Vulnerability assessment**
+
+
+1533 With an understanding of the potential vulnerability, the evaluator
+determines the most feasible way to test for the TOE's susceptibility.
+Specifically the evaluator considers:
+
+
+a) the TSFI or other TOE interface that will be used to stimulate the
+TSF and observe responses (It is possible that the evaluator will need
+to use an interface to the TOE other than the TSFI to demonstrate
+properties of the TSF such as those described in the security
+architecture description (as required by ADV_ARC). It should the
+noted, that although these TOE interfaces provide a means of testing
+the TSF properties, they are not the subject of the test.);
+
+
+b) initial conditions that will need to exist for the test (i.e. any particular
+objects or subjects that will need to exist and security attributes they
+will need to have);
+
+
+c) special test equipment that will be required to either stimulate a TSFI
+or make observations of a TSFI (although it is unlikely that specialist
+equipment would be required to exploit a potential vulnerability
+assuming a Basic attack potential);
+
+
+d) whether theoretical analysis should replace physical testing,
+particularly relevant where the results of an initial test can be
+extrapolated to demonstrate that repeated attempts of an attack are
+likely to succeed after a given number of attempts.
+
+
+1534 The evaluator will probably find it practical to carry out penetration testing
+using a series of test cases, where each test case will test for a specific
+potential vulnerability.
+
+
+1535 The intent of specifying this level of detail in the test documentation is to
+allow another evaluator to repeat the tests and obtain an equivalent result.
+
+
+AVA_VAN.2-8 The evaluator _**shall conduct**_ penetration testing.
+
+
+1536 The evaluator uses the penetration test documentation resulting from work
+unit AVA_VAN.2-6 as a basis for executing penetration tests on the TOE,
+but this does not preclude the evaluator from performing additional ad hoc
+penetration tests. If required, the evaluator may devise ad hoc tests as a result
+of information learnt during penetration testing that, if performed by the
+evaluator, are to be recorded in the penetration test documentation. Such tests
+may be required to follow up unexpected results or observations, or to
+investigate potential vulnerabilities suggested to the evaluator during the preplanned testing.
+
+
+1537 Should penetration testing show that a hypothesised potential vulnerability
+does not exist, then the evaluator should determine whether or not the
+evaluator's own analysis was incorrect, or if evaluation deliverables are
+incorrect or incomplete.
+
+
+Page 324 of 430 Version 3.1 April 2017
+
+
+**Class AVA: Vulnerability assessment**
+
+
+1538 The evaluator is not expected to test for potential vulnerabilities (including
+those in the public domain) beyond those which required a Basic attack
+potential. In some cases, however, it will be necessary to carry out a test
+before the exploitability can be determined. Where, as a result of evaluation
+expertise, the evaluator discovers an exploitable vulnerability that is beyond
+basic attack potential, this is reported in the ETR as a residual vulnerability.
+
+
+AVA_VAN.2-9 The evaluator _**shall record**_ the actual results of the penetration tests.
+
+
+1539 While some specific details of the actual test results may be different from
+those expected (e.g. time and date fields in an audit record) the overall result
+should be identical. Any unexpected test results should be investigated. The
+impact on the evaluation should be stated and justified.
+
+
+AVA_VAN.2-10 The evaluator _**shall report**_ in the ETR the evaluator penetration testing effort,
+outlining the testing approach, configuration, depth and results.
+
+
+1540 The penetration testing information reported in the ETR allows the evaluator
+to convey the overall penetration testing approach and effort expended on
+this sub-activity. The intent of providing this information is to give a
+meaningful overview of the evaluator's penetration testing effort. It is not
+intended that the information regarding penetration testing in the ETR be an
+exact reproduction of specific test steps or results of individual penetration
+tests. The intention is to provide enough detail to allow other evaluators and
+evaluation authorities to gain some insight about the penetration testing
+approach chosen, amount of penetration testing performed, TOE test
+configurations, and the overall results of the penetration testing activity.
+
+
+1541 Information that would typically be found in the ETR section regarding
+evaluator penetration testing efforts is:
+
+
+a) TOE test configurations. The particular configurations of the TOE
+that were penetration tested;
+
+
+b) TSFI penetration tested. A brief listing of the TSFI and other TOE
+interfaces that were the focus of the penetration testing;
+
+
+c) Verdict for the sub-activity. The overall judgement on the results of
+penetration testing.
+
+
+1542 This list is by no means exhaustive and is only intended to provide some
+context as to the type of information that should be present in the ETR
+concerning the penetration testing the evaluator performed during the
+evaluation.
+
+
+AVA_VAN.2-11 The evaluator _**shall examine**_ the results of all penetration testing to
+determine that the TOE, in its operational environment, is resistant to an
+attacker possessing a Basic attack potential.
+
+
+April 2017 Version 3.1 Page 325 of 430
+
+
+**Class AVA: Vulnerability assessment**
+
+
+1543 If the results reveal that the TOE, in its operational environment, has
+vulnerabilities exploitable by an attacker possessing less than an EnhancedBasic attack potential, then this evaluator action fails.
+
+
+1544 The guidance in B.4 should be used to determine the attack potential required
+to exploit a particular vulnerability and whether it can therefore be exploited
+in the intended environment. It may not be necessary for the attack potential
+to be calculated in every instance, only if there is some doubt as to whether
+or not the vulnerability can be exploited by an attacker possessing an attack
+potential less than Enhanced-Basic.
+
+
+AVA_VAN.2-12 The evaluator _**shall report**_ in the ETR all exploitable vulnerabilities and
+residual vulnerabilities, detailing for each:
+
+
+a) its source (e.g. CEM activity being undertaken when it was conceived,
+known to the evaluator, read in a publication);
+
+
+b) the SFR(s) not met;
+
+
+c) a description;
+
+
+d) whether it is exploitable in its operational environment or not (i.e.
+exploitable or residual).
+
+
+e) the amount of time, level of expertise, level of knowledge of the TOE,
+level of opportunity and the equipment required to perform the
+identified vulnerabilities, and the corresponding values using the
+tables 3 and 4 of Annex B.4.
+
+
+**16.2.3** **Evaluation of sub-activity (AVA_VAN.3)**
+
+
+16.2.3.1 Objectives
+
+
+1545 The objective of this sub-activity is to determine whether the TOE, in its
+operational environment, has vulnerabilities exploitable by attackers
+possessing Enhanced-Basic attack potential.
+
+
+16.2.3.2 Input
+
+
+1546 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the functional specification;
+
+
+c) the TOE design;
+
+
+d) the security architecture description;
+
+
+e) the implementation subset selected;
+
+
+f) the guidance documentation;
+
+
+Page 326 of 430 Version 3.1 April 2017
+
+
+**Class AVA: Vulnerability assessment**
+
+
+g) the TOE suitable for testing;
+
+
+h) information publicly available to support the identification of
+possible potential vulnerabilities;
+
+
+i) the results of the testing of the basic design.
+
+
+1547 The remaining implicit evaluation evidence for this sub-activity depends on
+the components that have been included in the assurance package. The
+evidence provided for each component is to be used as input in this subactivity.
+
+
+1548 Other input for this sub-activity is:
+
+
+a) current information regarding public domain potential vulnerabilities
+and attacks (e.g. from an evaluation authority).
+
+
+16.2.3.3 Application notes
+
+
+1549 During the conduct of evaluation activities the evaluator may also identify
+areas of concern. These are specific portions of the TOE evidence that the
+evaluator has some reservation about, although the evidence meets the
+requirements for the activity with which the evidence is associated. For
+example, a particular interface specification looks particularly complex, and
+therefore may be prone to error either in the development of the TOE or in
+the operation of the TOE. There is no potential vulnerability apparent at this
+stage, further investigation is required. This is beyond the bounds of
+encountered, as further investigation is required.
+
+
+1550 The focused approach to the identification of potential vulnerabilities is an
+analysis of the evidence with the aim of identifying any potential
+vulnerabilities evident through the contained information. It is an
+unstructured analysis, as the approach is not predetermined. Further guidance
+on focused vulnerability analysis can be found in Annex B.2.2.2.2.
+
+
+16.2.3.4 Action AVA_VAN.3.1E
+
+
+AVA_VAN.3.1C _**The TOE shall be suitable for testing.**_
+
+
+AVA_VAN.3-1 The evaluator _**shall examine**_ the TOE to determine that the test configuration
+is consistent with the configuration under evaluation as specified in the ST.
+
+
+1551 The TOE provided by the developer and identified in the test plan should
+have the same unique reference as established by the CM capabilities
+(ALC_CMC) sub-activities and identified in the ST introduction.
+
+
+1552 It is possible for the ST to specify more than one configuration for evaluation.
+The TOE may comprise a number of distinct hardware and software entities
+that need to be tested in accordance with the ST. The evaluator verifies that
+all test configurations are consistent with the ST.
+
+
+April 2017 Version 3.1 Page 327 of 430
+
+
+**Class AVA: Vulnerability assessment**
+
+
+1553 The evaluator should consider the security objectives for the operational
+environment described in the ST that may apply to the test environment and
+ensure they are met in the testing environment. There may be some
+objectives for the operational environment that do not apply to the test
+environment. For example, an objective about user clearances may not apply;
+however, an objective about a single point of connection to a network would
+apply.
+
+
+1554 If any test resources are used (e.g. meters, analysers) it will be the evaluator's
+responsibility to ensure that these resources are calibrated correctly.
+
+
+AVA_VAN.3-2 The evaluator _**shall examine**_ the TOE to determine that it has been installed
+properly and is in a known state
+
+
+1555 It is possible for the evaluator to determine the state of the TOE in a number
+of ways. For example, previous successful completion of the Evaluation of
+sub-activity (AGD_PRE.1) sub-activity will satisfy this work unit if the
+evaluator still has confidence that the TOE being used for testing was
+installed properly and is in a known state. If this is not the case, then the
+evaluator should follow the developer's procedures to install and start up the
+TOE, using the supplied guidance only.
+
+
+1556 If the evaluator has to perform the installation procedures because the TOE is
+in an unknown state, this work unit when successfully completed could
+satisfy work unit AGD_PRE.1-3.
+
+
+16.2.3.5 Action AVA_VAN.3.2E
+
+
+AVA_VAN.3-3 The evaluator _**shall examine**_ sources of information publicly available to
+identify potential vulnerabilities in the TOE.
+
+
+1557 The evaluator examines the sources of information publicly available to
+support the identification of possible potential vulnerabilities in the TOE.
+There are many sources of publicly available information which the
+evaluator should consider using items such as those available on the world
+wide web, including:
+
+
+a) specialist publications (magazines, books);
+
+
+b) research papers;
+
+
+c) conference proceedings.
+
+
+1558 The evaluator should not constrain their consideration of publicly available
+information to the above, but should consider any other relevant information
+available.
+
+
+1559 While examining the evidence provided the evaluator will use the
+information in the public domain to further search for potential
+vulnerabilities. Where the evaluators have identified areas of concern, the
+evaluator should consider information publicly available that relate to those
+areas of concern.
+
+
+Page 328 of 430 Version 3.1 April 2017
+
+
+**Class AVA: Vulnerability assessment**
+
+
+1560 The availability of information that may be readily available to an attacker
+that helps to identify and facilitate attacks may substantially enhance the
+attack potential of a given attacker. The accessibility of vulnerability
+information and sophisticated attack tools on the Internet makes it more
+likely that this information will be used in attempts to identify potential
+vulnerabilities in the TOE and exploit them. Modern search tools make such
+information easily available to the evaluator, and the determination of
+resistance to published potential vulnerabilities and well known generic
+attacks can be achieved in a cost-effective manner.
+
+
+1561 The search of the information publicly available should be focused on those
+sources that refer to the technologies used in the development of the product
+from which the TOE is derived. The extensiveness of this search should
+consider the following factors: TOE type, evaluator experience in this TOE
+type, expected attack potential and the level of ADV evidence available.
+
+
+1562 The identification process is iterative, where the identification of one
+potential vulnerability may lead to identifying another area of concern that
+requires further investigation.
+
+
+1563 The evaluator will report what actions were taken to identify potential
+vulnerabilities in the evidence. However, in this type of search, the evaluator
+may not be able to describe the steps in identifying potential vulnerabilities
+before the outset of the examination, as the approach may evolve as a result
+of findings during the search.
+
+
+1564 The evaluator will report the evidence examined in completing the search for
+potential vulnerabilities. This selection of evidence may be derived from
+those areas of concern identified by the evaluator, linked to the evidence the
+attacker is assumed to be able to obtain, or according to another rationale
+provided by the evaluator.
+
+
+16.2.3.6 Action AVA_VAN.3.3E
+
+
+AVA_VAN.3-4 The evaluator _**shall conduct**_ a focused search of ST, guidance documentation,
+
+functional specification, TOE design, security architecture description and
+implementation representation to identify possible potential vulnerabilities in
+the TOE.
+
+
+1565 A flaw hypothesis methodology needs to be used whereby specifications and
+development and guidance evidence are analysed and then potential
+vulnerabilities in the TOE are hypothesised, or speculated.
+
+
+1566 The evaluator uses the knowledge of the TOE design and operation gained
+from the TOE deliverables to conduct a flaw hypothesis to identify potential
+flaws in the development of the TOE and potential errors in the specified
+method of operation of the TOE.
+
+
+1567 The security architecture description provides the developer vulnerability
+analysis, as it documents how the TSF protects itself from interference from
+untrusted subjects and prevents the bypass of security enforcement
+
+
+April 2017 Version 3.1 Page 329 of 430
+
+
+**Class AVA: Vulnerability assessment**
+
+
+functionality. Therefore, the evaluator should build upon the understanding
+of the TSF protection gained from the analysis of this evidence and then
+develop this in the knowledge gained from other development ADV
+evidence.
+
+
+1568 The approach taken is directed by areas of concern identified during
+examination of the evidence during the conduct of evaluation activities and
+ensuring a representative sample of the development and guidance evidence
+provided for the evaluation is searched.
+
+
+1569 For guidance on sampling see Annex A.2. This guidance should be
+considered when selecting the subset, giving reasons for:
+
+
+a) the approach used in selection;
+
+
+b) qualification that the evidence to be examined supports that approach.
+
+
+1570 The areas of concern may relate to the sufficiency of specific protection
+features detailed in the security architecture description.
+
+
+1571 The evidence to be considered during the vulnerability analysis may be
+linked to the evidence the attacker is assumed to be able to obtain. For
+example, the developer may protect the TOE design and implementation
+representations, so the only information assumed to be available to an
+attacker is the functional specification and guidance (publicly available). So,
+although the objectives for assurance in the TOE ensure the TOE design and
+implementation representation requirements are met, these design
+representations may only be searched to further investigate areas of concerns.
+
+
+1572 On the other hand, if the source is publicly available it would be reasonable
+to assume that the attacker has access to the source and can use this in
+attempts to attack the TOE. Therefore, the source should be considered in the
+focused examination approach.
+
+
+1573 The following indicates examples for the selection of the subset of evidence
+to be considered:
+
+
+a) For an evaluation where all levels of design abstraction from
+functional specification to implementation representation are
+provided, examination of information in the functional specification
+and the implementation representation may be selected, as the
+functional specification provides detail of interfaces available to an
+attacker, and the implementation representation incorporates the
+design decisions made at all other design abstractions. Therefore, the
+TOE design information will be considered as part of the
+implementation representation.
+
+
+b) Examination of a particular subset of information in each of the
+design representations provided for the evaluation.
+
+
+Page 330 of 430 Version 3.1 April 2017
+
+
+**Class AVA: Vulnerability assessment**
+
+
+c) Coverage of particular SFRs through each of the design
+representations provided for the evaluation.
+
+
+d) Examination of each of the design representations provided for the
+evaluation, considering different SFRs within each design
+representations.
+
+
+e) Examination of aspects of the evidence provided for the evaluation
+relating to current potential vulnerability information the evaluator
+has received (e.g. from a scheme).
+
+
+1574 This approach to identification of potential vulnerabilities is to take an
+ordered and planned approach; applying a system to the examination. The
+evaluator is to describe the method to be used in terms of what evidence will
+be considered, the information within the evidence that is to be examined,
+the manner in which this information is to be considered and the hypothesis
+that is to be created.
+
+
+1575 The following provide some examples that a hypothesis may take:
+
+
+a) consideration of malformed input for interfaces available to an
+attacker at the external interfaces;
+
+
+b) examination of a key security mechanism cited in the security
+architecture description, such as process separation, hypothesising
+internal buffer overflows that may lead to degradation of separation;
+
+
+c) search to identify any objects created in the TOE implementation
+representation that are then not fully controlled by the TSF, and could
+be used by an attacker to undermine SFRs.
+
+
+1576 For example, the evaluator may identify that interfaces are a potential area of
+weakness in the TOE and specify an approach to the search that โall interface
+specifications provided in the functional specification and TOE design will
+be searched to hypothesise potential vulnerabilitiesโ and go on to explain the
+methods used in the hypothesis.
+
+
+1577 The identification process is iterative, where the identification of one
+potential vulnerability may lead to identifying another area of concern that
+requires further investigation.
+
+
+1578 The evaluator will report what actions were taken to identify potential
+vulnerabilities in the evidence. However, in this type of search, the evaluator
+may not be able to describe the steps in identifying potential vulnerabilities
+before the outset of the examination, as the approach may evolve as a result
+of findings during the search.
+
+
+1579 The evaluator will report the evidence examine in completing the search for
+potential vulnerabilities. This selection of evidence may be derived from
+those areas of concern identified by the evaluator, linked to the evidence the
+
+
+April 2017 Version 3.1 Page 331 of 430
+
+
+**Class AVA: Vulnerability assessment**
+
+
+attacker is assumed to be able to obtain, or according to another rationale
+provided by the evaluator.
+
+
+1580 Subject to the SFRs the TOE is to meet in the operational environment, the
+evaluator's independent vulnerability analysis should consider generic
+potential vulnerabilities under each of the following headings:
+
+
+a) generic potential vulnerabilities relevant for the type of TOE being
+evaluated, as may be supplied by the evaluation authority;
+
+
+b) bypassing;
+
+
+c) tampering;
+
+
+d) direct attacks;
+
+
+e) monitoring;
+
+
+f) misuse.
+
+
+1581 Items b) - f) are explained in greater detail in Annex B.
+
+
+1582 The security architecture description should be considered in light of each of
+the above generic potential vulnerabilities. Each potential vulnerability
+should be considered to search for possible ways in which to defeat the TSF
+protection and undermine the TSF.
+
+
+AVA_VAN.3-5 The evaluator _**shall record**_ in the ETR the identified potential vulnerabilities
+that are candidates for testing and applicable to the TOE in its operational
+environment.
+
+
+1583 It may be identified that no further consideration of the potential
+vulnerability is required if for example the evaluator identifies that measures
+in the operational environment, either IT or non-IT, prevent exploitation of
+the potential vulnerability in that operational environment. For instance,
+restricting physical access to the TOE to authorised users only may
+effectively render a potential vulnerability to tampering unexploitable.
+
+
+1584 The evaluator records any reasons for exclusion of potential vulnerabilities
+from further consideration if the evaluator determines that the potential
+vulnerability is not applicable in the operational environment. Otherwise the
+evaluator records the potential vulnerability for further consideration.
+
+
+1585 A list of potential vulnerabilities applicable to the TOE in its operational
+environment, which can be used as an input into penetration testing activities,
+shall be reported in the ETR by the evaluators.
+
+
+16.2.3.7 Action AVA_VAN.3.4E
+
+
+AVA_VAN.3-6 The evaluator _**shall devise**_ penetration tests, based on the independent search
+for potential vulnerabilities.
+
+
+Page 332 of 430 Version 3.1 April 2017
+
+
+**Class AVA: Vulnerability assessment**
+
+
+1586 The evaluator prepares for penetration testing as necessary to determine the
+susceptibility of the TOE, in its operational environment, to the potential
+vulnerabilities identified during the search of the sources of information
+publicly available. Any current information provided to the evaluator by a
+third party (e.g. evaluation authority) regarding known potential
+vulnerabilities will be considered by the evaluator, together with any
+encountered potential vulnerabilities resulting from the performance of other
+evaluation activities.
+
+
+1587 The evaluator is reminded that, as for considering the security architecture
+description in the search for vulnerabilities (as detailed in AVA_VAN.3-4),
+testing should be performed to confirm the architectural properties. If
+requirements from ATE_DPT are included in the SARs, the developer
+testing evidence will include testing performed to confirm the correct
+implementation of any specific mechanisms detailed in the security
+architecture description. However, the developer testing will not necessarily
+include testing of all aspects of the architectural properties that protect the
+TSF, as much of this testing will be negative testing in nature, attempting to
+disprove the properties. In developing the strategy for penetration testing, the
+evaluator will ensure that all aspects of the security architecture description
+are tested, either in functional testing (as considered in 15) or evaluator
+penetration testing.
+
+
+1588 It will probably be practical to carry out penetration test using a series of test
+cases, where each test case will test for a specific potential vulnerability.
+
+
+1589 The evaluator is not expected to test for potential vulnerabilities (including
+those in the public domain) beyond those which required an Enhanced-Basic
+attack potential. In some cases, however, it will be necessary to carry out a
+test before the exploitability can be determined. Where, as a result of
+evaluation expertise, the evaluator discovers an exploitable vulnerability that
+is beyond Enhanced-Basic attack potential, this is reported in the ETR as a
+residual vulnerability.
+
+
+1590 Guidance on determining the necessary attack potential to exploit a potential
+vulnerability can be found in Annex B.4.
+
+
+1591 Potential vulnerabilities hypothesised as exploitable only by attackers
+possessing Moderate or High attack potential do not result in a failure of this
+evaluator action. Where analysis supports the hypothesis, these need not be
+considered further as an input to penetration testing. However, such
+vulnerabilities are reported in the ETR as residual vulnerabilities.
+
+
+1592 Potential vulnerabilities hypothesised as exploitable by an attacker
+possessing a Basic or Enhanced-Basic attack potential and resulting in a
+violation of the security objectives should be the highest priority potential
+vulnerabilities comprising the list used to direct penetration testing against
+the TOE.
+
+
+April 2017 Version 3.1 Page 333 of 430
+
+
+**Class AVA: Vulnerability assessment**
+
+
+AVA_VAN.3-7 The evaluator _**shall produce**_ penetration test documentation for the tests
+based on the list of potential vulnerabilities in sufficient detail to enable the
+tests to be repeatable. The test documentation shall include:
+
+
+a) identification of the potential vulnerability the TOE is being tested
+for;
+
+
+b) instructions to connect and setup all required test equipment as
+required to conduct the penetration test;
+
+
+c) instructions to establish all penetration test prerequisite initial
+conditions;
+
+
+d) instructions to stimulate the TSF;
+
+
+e) instructions for observing the behaviour of the TSF;
+
+
+f) descriptions of all expected results and the necessary analysis to be
+performed on the observed behaviour for comparison against
+expected results;
+
+
+g) instructions to conclude the test and establish the necessary post-test
+state for the TOE.
+
+
+1593 The evaluator prepares for penetration testing based on the list of potential
+vulnerabilities identified during the search of the public domain and the
+analysis of the evaluation evidence.
+
+
+1594 The evaluator is not expected to determine the exploitability for potential
+vulnerabilities beyond those for which an Enhanced-Basic attack potential is
+required to effect an attack. However, as a result of evaluation expertise, the
+evaluator may discover a potential vulnerability that is exploitable only by an
+attacker with greater than Enhanced-Basic attack potential. Such
+vulnerabilities are to be reported in the ETR as residual vulnerabilities.
+
+
+1595 With an understanding of the potential vulnerability, the evaluator
+determines the most feasible way to test for the TOE's susceptibility.
+Specifically the evaluator considers:
+
+
+a) the TSFI or other TOE interface that will be used to stimulate the
+TSF and observe responses (It is possible that the evaluator will need
+to use an interface to the TOE other than the TSFI to demonstrate
+properties of the TSF such as those described in the security
+architecture description (as required by ADV_ARC). It should the
+noted, that although these TOE interfaces provide a means of testing
+the TSF properties, they are not the subject of the test.);
+
+
+b) initial conditions that will need to exist for the test (i.e. any particular
+objects or subjects that will need to exist and security attributes they
+will need to have);
+
+
+Page 334 of 430 Version 3.1 April 2017
+
+
+**Class AVA: Vulnerability assessment**
+
+
+c) special test equipment that will be required to either stimulate a TSFI
+or make observations of a TSFI (although it is unlikely that specialist
+equipment would be required to exploit a potential vulnerability
+assuming an Enhanced-Basic attack potential);
+
+
+d) whether theoretical analysis should replace physical testing,
+particularly relevant where the results of an initial test can be
+extrapolated to demonstrate that repeated attempts of an attack are
+likely to succeed after a given number of attempts.
+
+
+1596 The evaluator will probably find it practical to carry out penetration testing
+using a series of test cases, where each test case will test for a specific
+potential vulnerability.
+
+
+1597 The intent of specifying this level of detail in the test documentation is to
+allow another evaluator to repeat the tests and obtain an equivalent result.
+
+
+AVA_VAN.3-8 The evaluator _**shall conduct**_ penetration testing.
+
+
+1598 The evaluator uses the penetration test documentation resulting from work
+unit AVA_VAN.3-6 as a basis for executing penetration tests on the TOE,
+but this does not preclude the evaluator from performing additional ad hoc
+penetration tests. If required, the evaluator may devise ad hoc tests as a result
+of information learnt during penetration testing that, if performed by the
+evaluator, are to be recorded in the penetration test documentation. Such tests
+may be required to follow up unexpected results or observations, or to
+investigate potential vulnerabilities suggested to the evaluator during the preplanned testing.
+
+
+1599 Should penetration testing show that a hypothesised potential vulnerability
+does not exist, then the evaluator should determine whether or not the
+evaluator's own analysis was incorrect, or if evaluation deliverables are
+incorrect or incomplete.
+
+
+1600 The evaluator is not expected to test for potential vulnerabilities (including
+those in the public domain) beyond those which required an Enhanced-Basic
+attack potential. In some cases, however, it will be necessary to carry out a
+test before the exploitability can be determined. Where, as a result of
+evaluation expertise, the evaluator discovers an exploitable vulnerability that
+is beyond Enhanced-Basic attack potential, this is reported in the ETR as a
+residual vulnerability.
+
+
+AVA_VAN.3-9 The evaluator _**shall record**_ the actual results of the penetration tests.
+
+
+1601 While some specific details of the actual test results may be different from
+those expected (e.g. time and date fields in an audit record) the overall result
+should be identical. Any unexpected test results should be investigated. The
+impact on the evaluation should be stated and justified.
+
+
+AVA_VAN.3-10 The evaluator _**shall report**_ in the ETR the evaluator penetration testing effort,
+outlining the testing approach, configuration, depth and results.
+
+
+April 2017 Version 3.1 Page 335 of 430
+
+
+**Class AVA: Vulnerability assessment**
+
+
+1602 The penetration testing information reported in the ETR allows the evaluator
+to convey the overall penetration testing approach and effort expended on
+this sub-activity. The intent of providing this information is to give a
+meaningful overview of the evaluator's penetration testing effort. It is not
+intended that the information regarding penetration testing in the ETR be an
+exact reproduction of specific test steps or results of individual penetration
+tests. The intention is to provide enough detail to allow other evaluators and
+evaluation authorities to gain some insight about the penetration testing
+approach chosen, amount of penetration testing performed, TOE test
+configurations, and the overall results of the penetration testing activity.
+
+
+1603 Information that would typically be found in the ETR section regarding
+evaluator penetration testing efforts is:
+
+
+a) TOE test configurations. The particular configurations of the TOE
+that were penetration tested;
+
+
+b) TSFI penetration tested. A brief listing of the TSFI and other TOE
+interfaces that were the focus of the penetration testing;
+
+
+c) Verdict for the sub-activity. The overall judgement on the results of
+penetration testing.
+
+
+1604 This list is by no means exhaustive and is only intended to provide some
+context as to the type of information that should be present in the ETR
+concerning the penetration testing the evaluator performed during the
+evaluation.
+
+
+AVA_VAN.3-11 The evaluator _**shall examine**_ the results of all penetration testing to
+determine that the TOE, in its operational environment, is resistant to an
+attacker possessing an Enhanced-Basic attack potential.
+
+
+1605 If the results reveal that the TOE, in its operational environment, has
+vulnerabilities exploitable by an attacker possessing less than Moderate
+attack potential, then this evaluator action fails.
+
+
+1606 The guidance in B.4 should be used to determine the attack potential required
+to exploit a particular vulnerability and whether it can therefore be exploited
+in the intended environment. It may not be necessary for the attack potential
+to be calculated in every instance, only if there is some doubt as to whether
+or not the vulnerability can be exploited by an attacker possessing an attack
+potential less than Moderate.
+
+
+AVA_VAN.3-12 The evaluator _**shall report**_ in the ETR all exploitable vulnerabilities and
+residual vulnerabilities, detailing for each:
+
+
+a) its source (e.g. CEM activity being undertaken when it was conceived,
+known to the evaluator, read in a publication);
+
+
+b) the SFR(s) not met;
+
+
+c) a description;
+
+
+Page 336 of 430 Version 3.1 April 2017
+
+
+**Class AVA: Vulnerability assessment**
+
+
+d) whether it is exploitable in its operational environment or not (i.e.
+exploitable or residual).
+
+
+e) the amount of time, level of expertise, level of knowledge of the TOE,
+level of opportunity and the equipment required to perform the
+identified vulnerabilities, and the corresponding values using the
+tables 3 and 4 of Annex B.4.
+
+
+**16.2.4** **Evaluation of sub-activity (AVA_VAN.4)**
+
+
+16.2.4.1 Objectives
+
+
+1607 The objective of this sub-activity is to determine whether the TOE, in its
+operational environment, has vulnerabilities exploitable by attackers
+possessing Moderate attack potential.
+
+
+16.2.4.2 Input
+
+
+1608 The evaluation evidence for this sub-activity is:
+
+
+a) the ST;
+
+
+b) the functional specification;
+
+
+c) the TOE design;
+
+
+d) the security architecture description;
+
+
+e) the implementation representation;
+
+
+f) the guidance documentation;
+
+
+g) the TOE suitable for testing;
+
+
+h) information publicly available to support the identification of
+possible potential vulnerabilities;
+
+
+i) the results of the testing of the basic design.
+
+
+1609 The remaining implicit evaluation evidence for this sub-activity depends on
+the components that have been included in the assurance package. The
+evidence provided for each component is to be used as input in this subactivity.
+
+
+1610 Other input for this sub-activity is:
+
+
+a) current information regarding public domain potential vulnerabilities
+and attacks (e.g. from an evaluation authority).
+
+
+16.2.4.3 Application notes
+
+
+1611 The methodical analysis approach takes the form of a structured examination
+of the evidence. This method requires the evaluator to specify the structure
+
+
+April 2017 Version 3.1 Page 337 of 430
+
+
+**Class AVA: Vulnerability assessment**
+
+
+and form the analysis will take (i.e. the manner in which the analysis is
+performed is predetermined, unlike the focused analysis). The method is
+specified in terms of the information that will be considered and how/why it
+will be considered. Further guidance on methodical vulnerability analysis
+can be found in Annex B.2.2.2.3.
+
+
+16.2.4.4 Action AVA_VAN.4.1E
+
+
+AVA_VAN.4.1C _**The TOE shall be suitable for testing.**_
+
+
+AVA_VAN.4-1 The evaluator _**shall examine**_ the TOE to determine that the test configuration
+is consistent with the configuration under evaluation as specified in the ST.
+
+
+1612 The TOE provided by the developer and identified in the test plan should
+have the same unique reference as established by the CM capabilities
+(ALC_CMC) sub-activities and identified in the ST introduction.
+
+
+1613 It is possible for the ST to specify more than one configuration for evaluation.
+The TOE may comprise a number of distinct hardware and software entities
+that need to be tested in accordance with the ST. The evaluator verifies that
+all test configurations are consistent with the ST.
+
+
+1614 The evaluator should consider the security objectives for the operational
+environment described in the ST that may apply to the test environment and
+ensure they are met in the testing environment. There may be some
+objectives for the operational environment that do not apply to the test
+environment. For example, an objective about user clearances may not apply;
+however, an objective about a single point of connection to a network would
+apply.
+
+
+1615 If any test resources are used (e.g. meters, analysers) it will be the evaluator's
+responsibility to ensure that these resources are calibrated correctly.
+
+
+AVA_VAN.4-2 The evaluator _**shall examine**_ the TOE to determine that it has been installed
+properly and is in a known state
+
+
+1616 It is possible for the evaluator to determine the state of the TOE in a number
+of ways. For example, previous successful completion of the Evaluation of
+sub-activity (AGD_PRE.1) sub-activity will satisfy this work unit if the
+evaluator still has confidence that the TOE being used for testing was
+installed properly and is in a known state. If this is not the case, then the
+evaluator should follow the developer's procedures to install and start up the
+TOE, using the supplied guidance only.
+
+
+1617 If the evaluator has to perform the installation procedures because the TOE is
+in an unknown state, this work unit when successfully completed could
+satisfy work unit AGD_PRE.1-3.
+
+
+16.2.4.5 Action AVA_VAN.4.2E
+
+
+AVA_VAN.4-3 The evaluator _**shall examine**_ sources of information publicly available to
+identify potential vulnerabilities in the TOE.
+
+
+Page 338 of 430 Version 3.1 April 2017
+
+
+**Class AVA: Vulnerability assessment**
+
+
+1618 The evaluator examines the sources of information publicly available to
+support the identification of possible potential vulnerabilities in the TOE.
+There are many sources of publicly available information which the
+evaluator should consider using items such as those available on the world
+wide web, including:
+
+
+a) specialist publications (magazines, books);
+
+
+b) research papers;
+
+
+c) conference proceedings.
+
+
+1619 The evaluator should not constrain their consideration of publicly available
+information to the above, but should consider any other relevant information
+available.
+
+
+1620 While examining the evidence provided the evaluator will use the
+information in the public domain to further search for potential
+vulnerabilities. Where the evaluators have identified areas of concern, the
+evaluator should consider information publicly available that relate to those
+areas of concern.
+
+
+1621 The availability of information that may be readily available to an attacker
+that helps to identify and facilitate attacks may substantially enhance the
+attack potential of a given attacker. The accessibility of vulnerability
+information and sophisticated attack tools on the Internet makes it more
+likely that this information will be used in attempts to identify potential
+vulnerabilities in the TOE and exploit them. Modern search tools make such
+information easily available to the evaluator, and the determination of
+resistance to published potential vulnerabilities and well known generic
+attacks can be achieved in a cost-effective manner.
+
+
+1622 The search of the information publicly available should be focused on those
+sources that refer to the technologies used in the development of the product
+from which the TOE is derived. The extensiveness of this search should
+consider the following factors: TOE type, evaluator experience in this TOE
+type, expected attack potential and the level of ADV evidence available.
+
+
+1623 The identification process is iterative, where the identification of one
+potential vulnerability may lead to identifying another area of concern that
+requires further investigation.
+
+
+1624 The evaluator will describe the approach to be taken to identify potential
+vulnerabilities in the publicly available material, detailing the search to be
+performed. This may be driven by factors such as areas of concern identified
+by the evaluator, linked to the evidence the attacker is assumed to be able to
+obtain. However, it is recognised that in this type of search the approach may
+further evolve as a result of findings during the search. Therefore, the
+evaluator will also report any actions taken in addition to those described in
+the approach to further investigate issues thought to lead to potential
+
+
+April 2017 Version 3.1 Page 339 of 430
+
+
+**Class AVA: Vulnerability assessment**
+
+
+vulnerabilities, and will report the evidence examined in completing the
+search for potential vulnerabilities.
+
+
+16.2.4.6 Action AVA_VAN.4.3E
+
+
+AVA_VAN.4-4 The evaluator _**shall conduct**_ a methodical analysis of ST, guidance
+documentation, functional specification, TOE design, security architecture
+description and implementation representation to identify possible potential
+vulnerabilities in the TOE.
+
+
+1625 Guidance on methodical vulnerability analysis is provided in Annex
+B.2.2.2.3.
+
+
+1626 This approach to identification of potential vulnerabilities is to take an
+ordered and planned approach. A system is to be applied in the examination.
+The evaluator is to describe the method to be used in terms of the manner in
+which this information is to be considered and the hypothesis that is to be
+created.
+
+
+1627 A flaw hypothesis methodology needs to be used whereby the ST,
+development (functional specification, TOE design and implementation
+representation) and guidance evidence are analysed and then vulnerabilities
+in the TOE are hypothesised, or speculated.
+
+
+1628 The evaluator uses the knowledge of the TOE design and operation gained
+from the TOE deliverables to conduct a flaw hypothesis to identify potential
+flaws in the development of the TOE and potential errors in the specified
+method of operation of the TOE.
+
+
+1629 The security architecture description provides the developer vulnerability
+analysis, as it documents how the TSF protects itself from interference from
+untrusted subjects and prevents the bypass of security enforcement
+functionality. Therefore, the evaluator should build upon the understanding
+of the TSF protection gained from the analysis of this evidence and then
+develop this in the knowledge gained from other development ADV
+evidence.
+
+
+1630 The approach taken to the methodical search for vulnerabilities is to consider
+any areas of concern identified in the results of the evaluator's assessment of
+the development and guidance evidence. However, the evaluator should also
+consider each aspect of the security architecture analysis to search for any
+ways in which the protection of the TSF can be undermined. It may be
+helpful to structure the methodical analysis on the basis of the material
+presented in the security architecture description, introducing concerns from
+other ADV evidence as appropriate. The analysis can then be further
+developed to ensure all other material from the ADV evidence is considered.
+
+
+1631 The following provide some examples of hypotheses that may be created
+when examining the evidence:
+
+
+Page 340 of 430 Version 3.1 April 2017
+
+
+**Class AVA: Vulnerability assessment**
+
+
+a) consideration of malformed input for interfaces available to an
+attacker at the external interfaces;
+
+
+b) examination of a key security mechanism cited in the security
+architecture description, such as process separation, hypothesising
+internal buffer overflows that may lead to degradation of separation;
+
+
+c) search to identify any objects created in the TOE implementation
+representation that are then not fully controlled by the TSF, and could
+be used by an attacker to undermine SFRs.
+
+
+1632 For example, the evaluator may identify that interfaces are a potential area of
+weakness in the TOE and specify an approach to the search that 'all interface
+specifications in the evidence provided will be searched to hypothesise
+potential vulnerabilities' and go on to explain the methods used in the
+hypothesis.
+
+
+1633 In addition, areas of concern the evaluator has identified during examination
+of the evidence during the conduct of evaluation activities. Areas of concern
+may also be identified during the conduct of other work units associated with
+this component, in particular AVA_VAN.4-7, AVA_VAN.4-5 and
+AVA_VAN.4-6 where the development and conduct of penetration tests may
+identify further areas of concerns for investigation, or potential
+vulnerabilities.
+
+
+1634 However, examination of only a subset of the development and guidance
+evidence or their contents is not permitted in this level of rigour. The
+approach description should provide a demonstration that the methodical
+approach used is complete, providing confidence that the approach used to
+search the deliverables has considered all of the information provided in
+those deliverables.
+
+
+1635 This approach to identification of potential vulnerabilities is to take an
+ordered and planned approach; applying a system to the examination. The
+evaluator is to describe the method to be used in terms of how the evidence
+will be considered; the manner in which this information is to be considered
+and the hypothesis that is to be created. This approach should be agreed with
+the evaluation authority, and the evaluation authority may provide detail of
+any additional approaches the evaluator should take to the vulnerability
+analysis and identify any additional information that should be considered by
+the evaluator.
+
+
+1636 Although a system to identifying potential vulnerabilities is predefined, the
+identification process may still be iterative, where the identification of one
+potential vulnerability may lead to identifying another area of concern that
+requires further investigation.
+
+
+1637 Subject to the SFRs the TOE is to meet in the operational environment, the
+evaluator's independent vulnerability analysis should consider generic
+potential vulnerabilities under each of the following headings:
+
+
+April 2017 Version 3.1 Page 341 of 430
+
+
+**Class AVA: Vulnerability assessment**
+
+
+a) generic potential vulnerabilities relevant for the type of TOE being
+evaluated, as may be supplied by the evaluation authority;
+
+
+b) bypassing;
+
+
+c) tampering;
+
+
+d) direct attacks;
+
+
+e) monitoring;
+
+
+f) misuse.
+
+
+1638 Items b) - f) are explained in greater detail in Annex B.
+
+
+1639 The security architecture description should be considered in light of each of
+the above generic potential vulnerabilities. Each potential vulnerability
+should be considered to search for possible ways in which to defeat the TSF
+protection and undermine the TSF.
+
+
+AVA_VAN.4-5 The evaluator _**shall record**_ in the ETR the identified potential vulnerabilities
+that are candidates for testing and applicable to the TOE in its operational
+environment.
+
+
+1640 It may be identified that no further consideration of the potential
+vulnerability is required if for example the evaluator identifies that measures
+in the operational environment, either IT or non-IT, prevent exploitation of
+the potential vulnerability in that operational environment. For instance,
+restricting physical access to the TOE to authorised users only may
+effectively render a potential vulnerability to tampering unexploitable.
+
+
+1641 The evaluator records any reasons for exclusion of potential vulnerabilities
+from further consideration if the evaluator determines that the potential
+vulnerability is not applicable in the operational environment. Otherwise the
+evaluator records the potential vulnerability for further consideration.
+
+
+1642 A list of potential vulnerabilities applicable to the TOE in its operational
+environment, which can be used as an input into penetration testing activities,
+shall be reported in the ETR by the evaluators.
+
+
+16.2.4.7 Action AVA_VAN.4.4E
+
+
+AVA_VAN.4-6 The evaluator _**shall devise**_ penetration tests, based on the independent search
+for potential vulnerabilities.
+
+
+1643 The evaluator prepares for penetration testing as necessary to determine the
+susceptibility of the TOE, in its operational environment, to the potential
+vulnerabilities identified during the search of the sources of information
+publicly available. Any current information provided to the evaluator by a
+third party (e.g. evaluation authority) regarding known potential
+vulnerabilities will be considered by the evaluator, together with any
+
+
+Page 342 of 430 Version 3.1 April 2017
+
+
+**Class AVA: Vulnerability assessment**
+
+
+encountered potential vulnerabilities resulting from the performance of other
+evaluation activities.
+
+
+1644 The evaluator is reminded that, as for considering the security architecture
+description in the search for vulnerabilities (as detailed in AVA_VAN.4-3),
+testing should be performed to confirm the architectural properties. If
+requirements from ATE_DPT are included in the SARs, the developer
+testing evidence will include testing performed to confirm the correct
+implementation of any specific mechanisms detailed in the security
+architecture description. However, the developer testing will not necessarily
+include testing of all aspects of the architectural properties that protect the
+TSF, as much of this testing will be negative testing in nature, attempting to
+disprove the properties. In developing the strategy for penetration testing, the
+evaluator will ensure that all aspects of the security architecture description
+are tested, either in functional testing (as considered in 15) or evaluator
+penetration testing.
+
+
+1645 The evaluator will probably find it practical to carry out penetration test
+using a series of test cases, where each test case will test for a specific
+potential vulnerability.
+
+
+1646 The evaluator is not expected to test for potential vulnerabilities (including
+those in the public domain) beyond those which required a Moderate attack
+potential. In some cases, however, it will be necessary to carry out a test
+before the exploitability can be determined. Where, as a result of evaluation
+expertise, the evaluator discovers an exploitable vulnerability that is beyond
+Moderate attack potential, this is reported in the ETR as a residual
+vulnerability.
+
+
+1647 Guidance on determining the necessary attack potential to exploit a potential
+vulnerability can be found in Annex B.4.
+
+
+1648 Potential vulnerabilities hypothesised as exploitable by an attacker
+possessing a Moderate (or less) attack potential and resulting in a violation of
+the security objectives should be the highest priority potential vulnerabilities
+comprising the list used to direct penetration testing against the TOE.
+
+
+AVA_VAN.4-7 The evaluator _**shall produce**_ penetration test documentation for the tests
+based on the list of potential vulnerabilities in sufficient detail to enable the
+tests to be repeatable. The test documentation shall include:
+
+
+a) identification of the potential vulnerability the TOE is being tested
+for;
+
+
+b) instructions to connect and setup all required test equipment as
+required to conduct the penetration test;
+
+
+c) instructions to establish all penetration test prerequisite initial
+conditions;
+
+
+d) instructions to stimulate the TSF;
+
+
+April 2017 Version 3.1 Page 343 of 430
+
+
+**Class AVA: Vulnerability assessment**
+
+
+e) instructions for observing the behaviour of the TSF;
+
+
+f) descriptions of all expected results and the necessary analysis to be
+performed on the observed behaviour for comparison against
+expected results;
+
+
+g) instructions to conclude the test and establish the necessary post-test
+state for the TOE.
+
+
+1649 The evaluator prepares for penetration testing based on the list of potential
+vulnerabilities identified during the search of the public domain and the
+analysis of the evaluation evidence.
+
+
+1650 The evaluator is not expected to determine the exploitability for potential
+vulnerabilities beyond those for which a Moderate attack potential is
+required to effect an attack. However, as a result of evaluation expertise, the
+evaluator may discover a potential vulnerability that is exploitable only by an
+attacker with greater than Moderate attack potential. Such vulnerabilities are
+to be reported in the ETR as residual vulnerabilities.
+
+
+1651 With an understanding of the potential vulnerability, the evaluator
+determines the most feasible way to test for the TOE's susceptibility.
+Specifically the evaluator considers:
+
+
+a) the TSFI or other TOE interface that will be used to stimulate the
+TSF and observe responses (It is possible that the evaluator will need
+to use an interface to the TOE other than the TSFI to demonstrate
+properties of the TSF such as those described in the security
+architecture description (as required by ADV_ARC). It should the
+noted, that although these TOE interfaces provide a means of testing
+the TSF properties, they are not the subject of the test.);
+
+
+b) initial conditions that will need to exist for the test (i.e. any particular
+objects or subjects that will need to exist and security attributes they
+will need to have);
+
+
+c) special test equipment that will be required to either stimulate a TSFI
+or make observations of a TSFI;
+
+
+d) whether theoretical analysis should replace physical testing,
+particularly relevant where the results of an initial test can be
+extrapolated to demonstrate that repeated attempts of an attack are
+likely to succeed after a given number of attempts.
+
+
+1652 The evaluator will probably find it practical to carry out penetration testing
+using a series of test cases, where each test case will test for a specific
+potential vulnerability.
+
+
+1653 The intent of specifying this level of detail in the test documentation is to
+allow another evaluator to repeat the tests and obtain an equivalent result.
+
+
+AVA_VAN.4-8 The evaluator _**shall conduct**_ penetration testing.
+
+
+Page 344 of 430 Version 3.1 April 2017
+
+
+**Class AVA: Vulnerability assessment**
+
+
+1654 The evaluator uses the penetration test documentation resulting from work
+unit AVA_VAN.4-6 as a basis for executing penetration tests on the TOE,
+but this does not preclude the evaluator from performing additional ad hoc
+penetration tests. If required, the evaluator may devise ad hoc tests as a result
+of information learnt during penetration testing that, if performed by the
+evaluator, are to be recorded in the penetration test documentation. Such tests
+may be required to follow up unexpected results or observations, or to
+investigate potential vulnerabilities suggested to the evaluator during the preplanned testing.
+
+
+1655 Should penetration testing show that a hypothesised potential vulnerability
+does not exist, then the evaluator should determine whether or not the
+evaluator's own analysis was incorrect, or if evaluation deliverables are
+incorrect or incomplete.
+
+
+1656 The evaluator is not expected to test for potential vulnerabilities (including
+those in the public domain) beyond those which required a Moderate attack
+potential. In some cases, however, it will be necessary to carry out a test
+before the exploitability can be determined. Where, as a result of evaluation
+expertise, the evaluator discovers an exploitable vulnerability that is beyond
+Moderate attack potential, this is reported in the ETR as a residual
+vulnerability.
+
+
+AVA_VAN.4-9 The evaluator _**shall record**_ the actual results of the penetration tests.
+
+
+1657 While some specific details of the actual test results may be different from
+those expected (e.g. time and date fields in an audit record) the overall result
+should be identical. Any unexpected test results should be investigated. The
+impact on the evaluation should be stated and justified.
+
+
+AVA_VAN.4-10 The evaluator _**shall report**_ in the ETR the evaluator penetration testing effort,
+outlining the testing approach, configuration, depth and results.
+
+
+1658 The penetration testing information reported in the ETR allows the evaluator
+to convey the overall penetration testing approach and effort expended on
+this sub-activity. The intent of providing this information is to give a
+meaningful overview of the evaluator's penetration testing effort. It is not
+intended that the information regarding penetration testing in the ETR be an
+exact reproduction of specific test steps or results of individual penetration
+tests. The intention is to provide enough detail to allow other evaluators and
+evaluation authorities to gain some insight about the penetration testing
+approach chosen, amount of penetration testing performed, TOE test
+configurations, and the overall results of the penetration testing activity.
+
+
+1659 Information that would typically be found in the ETR section regarding
+evaluator penetration testing efforts is:
+
+
+a) TOE test configurations. The particular configurations of the TOE
+that were penetration tested;
+
+
+April 2017 Version 3.1 Page 345 of 430
+
+
+**Class AVA: Vulnerability assessment**
+
+
+b) TSFI penetration tested. A brief listing of the TSFI and other TOE
+interfaces that were the focus of the penetration testing;
+
+
+c) Verdict for the sub-activity. The overall judgement on the results of
+penetration testing.
+
+
+1660 This list is by no means exhaustive and is only intended to provide some
+context as to the type of information that should be present in the ETR
+concerning the penetration testing the evaluator performed during the
+evaluation.
+
+
+AVA_VAN.4-11 The evaluator _**shall examine**_ the results of all penetration testing to
+determine that the TOE, in its operational environment, is resistant to an
+attacker possessing a Moderate attack potential.
+
+
+1661 If the results reveal that the TOE, in its operational environment, has
+vulnerabilities exploitable by an attacker possessing less than a High attack
+potential, then this evaluator action fails.
+
+
+1662 The guidance in B.4 should be used to determine the attack potential required
+to exploit a particular vulnerability and whether it can therefore be exploited
+in the intended environment. It may not be necessary for the attack potential
+to be calculated in every instance, only if there is some doubt as to whether
+or not the vulnerability can be exploited by an attacker possessing an attack
+potential less than High.
+
+
+AVA_VAN.4-12 The evaluator _**shall report**_ in the ETR all exploitable vulnerabilities and
+residual vulnerabilities, detailing for each:
+
+
+a) its source (e.g. CEM activity being undertaken when it was conceived,
+known to the evaluator, read in a publication);
+
+
+b) the SFR(s) not met;
+
+
+c) a description;
+
+
+d) whether it is exploitable in its operational environment or not (i.e.
+exploitable or residual).
+
+
+e) the amount of time, level of expertise, level of knowledge of the TOE,
+level of opportunity and the equipment required to perform the
+identified vulnerabilities, and the corresponding values using the
+tables 3 and 4 of Annex B.4.
+
+
+**16.2.5** **Evaluation of sub-activity (AVA_VAN.5)**
+
+
+1663 There is no general guidance; the scheme should be consulted for guidance
+on this sub-activity.
+
+
+Page 346 of 430 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+# **17 Class ACO: Composition**
+
+## **17.1 Introduction**
+
+
+1664 The goal of this activity is to determine whether the components can be
+integrated in a secure manner, as defined in the ST for the composed TOE.
+This is achieved through examination and testing of the interfaces between
+the components, supported by examination of the design of the components
+and the conduct of vulnerability analysis.
+
+## **17.2 Application notes**
+
+
+1665 The Reliance of dependent component (ACO_REL) family identifies where
+the dependent component is reliant upon IT in its operational environment
+(satisfied by a base component in the composed TOE evaluation) in order to
+provide its own security services. This reliance is identified in terms of the
+interfaces expected by the dependent component to be provided by the base
+component. Development evidence (ACO_DEV) then determines which
+interfaces of the base component were considered (as TSFI) during the
+component evaluation of the base component.
+
+
+1666 It should be noted that Reliance of dependent component (ACO_REL) does
+not cover other evidence that may be needed to address the technical
+integration problem of composing components (e.g. descriptions of non-TSF
+interfaces of the operating system, rules for integration, etc.). This is outside
+the security assessment of the composition and is a functional composition
+issue.
+
+
+1667 As part of Composed TOE testing (ACO_CTT) the evaluator will perform
+testing of the composed TOE SFRs at the composed TOE interfaces and of
+the interfaces of the base component relied upon by the dependent
+component to confirm they operate as specified. The subset selected will
+consider the possible effects of changes to the configuration/use of the base
+component as used in the composed TOE. These changes are identified from
+the configuration of the base component determined during the base
+component evaluation. The developer will provide test evidence for each of
+the base component interfaces (the requirements for coverage are consistent
+with those applied to the evaluation of the base component).
+
+
+1668 Composition rationale (ACO_COR) requires the evaluator to determine
+whether the appropriate assurance measures have been applied to the base
+component, and whether the base component is being used in its evaluated
+configuration. This includes determination of whether all security
+functionality required by the dependent component was within the TSF of
+the base component. The Composition rationale (ACO_COR) requirement
+may be met through the production of evidence that each of these is
+demonstrated to be upheld. This evidence may be in the form of the security
+target and a public report of the component evaluation (e.g. certification
+report).
+
+
+April 2017 Version 3.1 Page 347 of 430
+
+
+**Class ACO: Composition**
+
+
+1669 If, on the other hand, one of the above have not been upheld, then it may be
+possible that an argument can be made as to why the assurance gained during
+an original evaluation is unaffected. If this is not possible then additional
+evaluation evidence for those aspects of the base component not covered
+may have to be provided. This material is then assessed in Development
+evidence (ACO_DEV).
+
+
+1670 For example, it may be the case as described in the Interactions between
+entities (see Annex B.3, Interactions between composed IT entities in CC
+Part 3) that the dependent component requires the base component to provide
+more security functionality in the composed TOE than included in the base
+component evaluation. This would be determined during the application of
+the Reliance of dependent component (ACO_REL) and Development
+evidence (ACO_DEV) families. In this case the composition rationale
+evidence provided for Composition rationale (ACO_COR) would
+demonstrate that the assurance gained from the base component evaluation is
+unaffected. This may be achieved by means including:
+
+
+a) Performing a re-evaluation of the base component focusing on the
+evidence relating to the extended part of the TSF;
+
+
+b) Demonstrating that the extended part of the TSF cannot affect other
+portions of the TSF, and providing evidence that the extended part of
+the TSF provides the necessary security functionality.
+
+
+Page 348 of 430 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+## **17.3 Composition rationale (ACO_COR)**
+
+
+**17.3.1** **Evaluation of sub-activity (ACO_COR.1)**
+
+
+17.3.1.1 Input
+
+
+1671 The evaluation evidence for this sub-activity is:
+
+
+a) the composed ST;
+
+
+b) the composition rationale;
+
+
+c) the reliance information;
+
+
+d) the development information;
+
+
+e) unique identifier.
+
+
+17.3.1.2 Action ACO_COR.1.1E
+
+
+ACO_COR.1.1C _**The composition rationale shall demonstrate that a level of assurance at**_
+_**least as high as that of the dependent component has been obtained for the**_
+_**support functionality of the base component, when the base component is**_
+_**configured as required to support the TSF of the dependent component.**_
+
+
+ACO_COR.1-1 The evaluator _**shall examine**_ the correspondence analysis with the
+development information and the reliance information to identify the
+interfaces that are relied upon by the dependent component which are not
+detailed in the development information.
+
+
+1672 The evaluator's goal in this work unit is two fold:
+
+
+a) to determine which interfaces relied upon by the dependent
+component have had the appropriate assurance measures applied.
+
+
+b) to determine that the assurance package applied to the base
+component during the base component evaluation contained either
+the same assurance requirements as those in the package applied to
+the dependent component during its' evaluation, or hierarchically
+higher assurance requirements.
+
+
+1673 The evaluator may use the correspondence tracing in the development
+information developed during the Development evidence (ACO_DEV)
+activities (e.g. ACO_DEV.1-2, ACO_DEV.2-4, ACO_DEV.3-6) to help
+identify the interfaces identified in the reliance information that are not
+considered in the development information.
+
+
+1674 The evaluator will record the SFR-enforcing interfaces described in the
+reliance information that are not included in the development information.
+These will provide input to ACO_COR.1-3 work unit, helping to identify the
+portions of the base component in which further assurance is required.
+
+
+April 2017 Version 3.1 Page 349 of 430
+
+
+**Class ACO: Composition**
+
+
+1675 If the both the base and dependent components were evaluated against the
+same assurance package, then the determination of whether the level of
+assurance in the portions within the base component evaluation is at least as
+high as that of the dependent component is trivial. If however, the assurance
+packages applied to the components during the component evaluations differ,
+the evaluator needs to determine that the assurance requirements applied to
+the base component are all hierarchically higher to the assurance
+requirements applied to the dependent component.
+
+
+ACO_COR.1-2 The evaluator _**shall examine**_ the composition rationale to determine, for
+those included base component interfaces on which the dependent TSF relies,
+whether the interface was considered during the evaluation of the base
+component.
+
+
+1676 The ST, component public evaluation report (e.g. certification report) and
+guidance documents for the base component all provide information on the
+scope and boundary of the base component. The ST provides details of the
+logical scope and boundary of the composed TOE, allowing the evaluator to
+determine whether an interface relates to a portion of the product that was
+within the scope of the evaluation. The guidance documentation provides
+details of use of all interfaces for the composed TOE. Although the guidance
+documentation may include details of interfaces in the product that are not
+within the scope of the evaluation, any such interfaces should be identifiable,
+either from the scoping information in the ST or through a portion of the
+guidance that deals with the evaluated configuration. The public evaluation
+report may provide any additional constraints on the use of the composed
+TOE that are necessary.
+
+
+1677 Therefore, the combination of these inputs allows the evaluator to determine
+whether an interface described in the composition rationale has the necessary
+assurance associated with it, or whether further assurance is required. The
+evaluator will record those interfaces of the base component for which
+additional assurance is required, for consideration during ACO_COR.1-3.
+
+
+ACO_COR.1-3 The evaluator _**shall examine**_ the composition rationale to determine that the
+necessary assurance measures have been applied to the base component.
+
+
+1678 The evaluation verdicts, and resultant assurance, for the base component can
+be reused provided the same portions of the base component are used in the
+composed TOE and they are used in a consistent manner.
+
+
+1679 In order to determine whether the necessary assurance measures have already
+been applied to the component, and the portions of the component for which
+assurance measures still need to be applied, the evaluator should use the
+output of the ACO_DEV.*.2E action and the work units ACO_COR.1-1 and
+ACO_COR.1-2:
+
+
+a) For those interfaces identified in the reliance information (Reliance of
+dependent component (ACO_REL)), but not discussed in
+development information (Development evidence (ACO_DEV)),
+additional information is required. (Identified in ACO_COR.1-1.)
+
+
+Page 350 of 430 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+
+b) For those interfaces used inconsistently in the composed TOE from
+the base component (difference between the information provided in
+Development evidence (ACO_DEV) and Reliance of dependent
+component (ACO_REL) the impact of the differences in use need to
+be considered. (Identified in ACO_DEV.*.2E.)
+
+
+c) For those interfaces identified in composition rationale for which no
+assurance has previously been gained, additional information is
+required. (Identified in ACO_COR.1-2.)
+
+
+d) For those interfaces consistently described in the reliance information,
+composition rationale and the development information, no further
+action is required as the results from the base component evaluation
+can be re-used.
+
+
+1680 The interfaces of the base component reported to be required by the reliance
+information but not included in the development information indicate the
+portions of the base component where further assurance is required. The
+interfaces identify the entry points into the base component.
+
+
+1681 For those interfaces included in both the development information and
+reliance information, the evaluator is to determine whether the interfaces are
+being used in the composed TOE in a manner that is consistent with the base
+component evaluation. The method of use of the interface will be considered
+during the Development evidence (ACO_DEV) activities to determine that
+the use of the interface is consistent in both the base component and the
+composed TOE. The remaining consideration is the determination of whether
+the configurations of the base component and the composed TOE are
+consistent. To determine this, the evaluator will consider the guidance
+documentation of each to ensure they are consistent (see further guidance
+below regarding consistent guidance documentation). Any deviation in the
+documentation will be further analysed by the evaluation to determine the
+possible effects.
+
+
+1682 For those interfaces that are consistently described in the reliance
+information and development information, and for which the guidance is
+consistent for the base component and the composed TOE, the required level
+of assurance has been provided.
+
+
+1683 The following subsections provide guidance on how to determine
+consistency between assurance gained in the base component, the evidence
+provided for the composed TOE, and the analysis performed by the evaluator
+in the instances where inconsistencies are identified.
+
+
+17.3.1.2.1 Development
+
+
+1684 The reliance information identifies the interfaces in the dependent
+component that are to be matched by the base component. If an interface
+identified in the reliance information is not identified in the development
+information, then the composition rationale is to provide a justification of
+how the base component provides the required interfaces.
+
+
+April 2017 Version 3.1 Page 351 of 430
+
+
+**Class ACO: Composition**
+
+
+1685 If an interface identified in the reliance information is identified in the
+development information, but there are inconsistencies between the
+descriptions, further analysis is required. The evaluator identifies the
+differences in use of the base component as considered in the base
+component evaluation and the composed TOE evaluation. The evaluator will
+devise testing to be performed (during the conduct of Composed TOE testing
+(ACO_CTT)) to test the interface.
+
+
+1686 The patch status of the base and dependent components as used in the
+composed TOE should be compared to the patch status of the components
+during the component evaluations. If any patches have been applied to the
+components, the composition rationale is to include details of the patches,
+including any potential impact to the SFRs of the evaluated component. The
+evaluator should consider the details of the changes provided and verify the
+accuracy of the potential impact of the change on the component SFRs. The
+evaluator should then consider whether the changes made by the patch
+should be verified through testing, and will identify the necessary testing
+approach. The testing may take the form of repeating the applicable
+evaluator/developer testing performed for the component evaluation of the
+component or it may be necessary for the evaluator to devise new tests to
+confirm the modified component.
+
+
+1687 If any of the individual components have been the subject of assurance
+continuity activities since the completion of the component evaluation, the
+evaluator will consider the changes assessed in the assurance continuity
+activities during the independent vulnerability analysis activity for the
+composed TOE (in Composition vulnerability analysis (ACO_VUL)).
+
+
+17.3.1.2.2 Guidance
+
+
+1688 The guidance for the composed TOE is likely to make substantial reference
+out to the guidance for the individual components. The minimal guidance
+expected to be necessary is the identification of any ordering dependencies in
+the application of guidance for the dependent and base components,
+particularly during the preparation (installation) of the composed TOE.
+
+
+1689 In addition to the application of the Preparative procedures (AGD_PRE) and
+Operational user guidance (AGD_OPE) families to the guidance for the
+composed TOE, it is necessary to analyse the consistency between the
+guidance for the components and the composed TOE, to identify any
+deviations.
+
+
+1690 If the composed TOE guidance refers out to the base component and
+dependent component guidance, then the consideration for consistency is
+limited to consistency between the guidance documentation provided for
+each of the components (i.e. consistency between the base component
+guidance and the dependent component guidance). However, if additional
+guidance is provided for the composed TOE, to that provided for the
+components, greater analysis is required, as consistency is also required
+between the guidance documentation for the components and guidance
+documentation for the composed TOE.
+
+
+Page 352 of 430 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+
+1691 _Consistent_ in this instance is understood to mean that either the guidance is
+the same or it places additional constraints on the operation of the individual
+components when combined, in a similar manner to _refinement_ of
+functional/assurance components.
+
+
+1692 With the information available (that used as input for Development evidence
+(ACO_DEV) or the development aspects discussed above) the evaluator may
+be able to determine all possible impacts of the deviation from the
+configuration of the base component specified in the component evaluation.
+However, for high EALs (where evaluation of the base component included
+TOE design (ADV_TDS) requirements) it is possible that, unless detailed
+design abstractions for the base component are delivered as part of the
+development information for the composed TOE, the possible impacts of the
+modification to the guidance cannot be fully determined as the internals are
+unknown. In this case the evaluator will report the residual risk of the
+analysis.
+
+
+1693 These residual risks are to be included in any public evaluation report for the
+composed TOE.
+
+
+1694 The evaluator will note these variances in the guidance for input into
+evaluator independent testing activities (Composed TOE testing
+(ACO_CTT)).
+
+
+1695 The guidance for the composed TOE may add to the guidance for the
+components, particularly in terms of installation and the ordering of
+installation steps for the base component in relation to the installation steps
+for the dependent component. The ordering of the steps for the installation of
+the individual components should not change, however they may need to be
+interleaved. The evaluator will examine this guidance to ensure that it still
+meets the requirement of the AGD_PRE activity performed during the
+evaluations of the components.
+
+
+1696 It may be the case that the reliance information identifies that interfaces of
+the base component, in addition to those identified as TSFIs of the base
+component, are relied upon by the dependent component are identified in the
+reliance information. It may be necessary for guidance to be provided for the
+use of any such additional interfaces in the base component. Provided the
+consumer of the composed TOE is to receive the guidance documentation for
+the base component, then the results of the AGD_PRE and AGD_OPE
+verdicts for the base component can be reused for those interfaces considered
+in the evaluation of the base component. However, for the additional
+interfaces relied upon by the dependent component, the evaluator will need
+to determine that the guidance documentation for the base component meets
+the requirements of AGD_PRE and AGD_OPE, as applied in the base
+component evaluations.
+
+
+1697 For those interfaces considered during the base component evaluation, and
+therefore, for which assurance has already been gained, the evaluator will
+ensure that the guidance for the use of each interface for the composed TOE
+is consistent with that provided for the base component. To determine the
+
+
+April 2017 Version 3.1 Page 353 of 430
+
+
+**Class ACO: Composition**
+
+
+guidance for the composed TOE is consistent with that for the base
+component, the evaluator should perform a mapping for each interface to the
+guidance provided for both the composed TOE and the base component. The
+evaluator then compares the guidance to determine consistency.
+
+
+1698 Examples of additional constraints provided in composed TOE guidance that
+would be considered to be consistent with component guidance are (guidance
+for a component is given followed by an example of guidance for a
+composed TOE that would be considered to provide additional constraints):
+
+
+๏ญ Component: The password length must be set to a minimum of 8
+characters length, including alphabetic and numeric characters.
+
+
+๏ญ Composed TOE: The password length must be set to a minimum of
+10 characters in length, including alphabetic and numeric characters
+and _at least one of the following special characters: ( ) { } ^ < > - __
+
+
+๏ญ NOTE: It would only be acceptable to increase the password length
+to [ _integer > 8_ ] characters while removing the mandate for the
+inclusion of both alphabetic and numeric characters for the composed
+TOE, if the same or a higher metric was achieved for the strength
+rating (taking into account the likelihood of the password being
+guessed).
+
+
+๏ญ Component: The following services are to be disabled in the registry
+settings: WWW Publishing Service and ICDBReporter service.
+
+
+๏ญ Composed TOE: The following services are to be disabled in the
+registry settings: _Publishing Service, ICDBReporter service, Remote_
+_Procedure Call (RPC) Locator and Procedure Call (RPC) Service_ .
+
+
+๏ญ Component: Select the following attributes to be included in the
+accounting log files: date, time, type of event, subject identity and
+success/failure.
+
+
+๏ญ Composed TOE: Select the following attributes to be included in the
+accounting log files: date, time, type of event, subject identity,
+success/failure, _event message and process thread_ .
+
+
+1699 If the guidance for the composed TOE deviates (is not a refinement) from
+that provided for the base component, the evaluator will assess the potential
+risks of the modification to the guidance. The evaluator will use the
+information available (including that provided in the public domain, the
+architectural description of the base component in the public evaluation
+report (e.g. certification report), the context of the guidance from the
+remainder of the guidance documentation) to identify likely impact of the
+modification to the guidance on the SFRs of the composed TOE.
+
+
+1700 If during the dependent component evaluation the trial installation used the
+base component to satisfy the environment requirements of the dependent
+component this work unit for the composed TOE is considered to be satisfied.
+
+
+Page 354 of 430 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+
+If the base component was not used in satisfaction of the work unit
+AGD_PRE.1-3 during the dependent component evaluation, the evaluator
+will apply the user procedures provided for the composed TOE to prepare the
+composed TOE, in accordance with the guidance specified in AGD_PRE.1-3.
+This will allow the evaluator to determine that the preparative guidance
+provided for the composed TOE is sufficient to prepare the composed TOE
+and its operational environment securely.
+
+
+17.3.1.2.3 Life-cycle
+
+
+Delivery
+
+
+1701 If there is a different delivery mechanism used for the delivery of the
+composed TOE (i.e. the components are not delivered to the consumer in
+accordance with the secure delivery procedures defined and assessed during
+the evaluation of the components), the delivery procedures for the composed
+TOE will require evaluation against the Delivery (ALC_DEL) requirements
+applied during the components evaluations.
+
+
+1702 The composed TOE may be delivered as an integrated product or may
+require the components to be delivered separately.
+
+
+1703 If the components are delivered separately, the results of the delivery of the
+base component and dependent component are reused. The delivery of the
+base component is checked during the evaluator trial installation of the
+dependent component, using the specified guidance and checking the aspects
+of delivery that are the responsibility of the user, as described in the guidance
+documentation for the base component.
+
+
+1704 If the composed TOE is delivered as a new entity, then the method of
+delivery of that entity must be considered in the composed TOE evaluation
+activities.
+
+
+1705 The assessment of the delivery procedures for composed TOE items is to be
+performed in accordance with the methodology for Delivery (ALC_DEL) as
+for any other [component] TOE, ensuring any additional items (e.g.
+additional guidance documents for the composed TOE) are considered in the
+delivery procedures.
+
+
+CM Capabilities
+
+
+1706 The unique identification of the composed TOE is considered during the
+application of Evaluation of sub-activity (ALC_CMC.1) and the items from
+which that composed TOE is comprised are considered during the
+application of Evaluation of sub-activity (ALC_CMS.2).
+
+
+1707 Although additional guidance may be produced for the composed TOE, the
+unique identification of this guidance (considered as part of the unique
+identification of the composed TOE during Evaluation of sub-activity
+(ALC_CMC.1)) is considered sufficient control of the guidance.
+
+
+April 2017 Version 3.1 Page 355 of 430
+
+
+**Class ACO: Composition**
+
+
+1708 The verdicts of the remaining (not considered above) Class ALC: Life-cycle
+support activities can be reused from the base component evaluation, as no
+further development is performed during integration of the composed TOE.
+
+
+1709 There are no additional considerations for development security as the
+integration is assumed to take place at either the consumer's site or, in the
+instance that the composed TOE is delivered as an integrated product, at the
+site of the dependent component developer. Control at the consumer's site is
+outside the consideration of the CC. No additional requirements or guidance
+are necessary if integration is at the same site as that for the dependent
+component, as all components are considered to be configuration items for
+the composed TOE, and should therefore be considered under the dependent
+component developer's security procedures anyway.
+
+
+1710 Tools and techniques adopted during integration will be considered in the
+evidence provided by the dependent component developer. Any
+tools/techniques relevant to the base component will have been considered
+during the evaluation of the base component. For example, if the base
+component is delivered as source code and requires compilation by the
+consumer (e.g. dependent component developer who is performing
+integration) the compiler would have been specified and assessed, along with
+the appropriate arguments, during evaluation of the base component.
+
+
+1711 There is no life-cycle definition applicable to the composed TOE, as no
+further development of items is taking place.
+
+
+1712 The results of flaw remediation for a component are not applicable to the
+composed TOE. If flaw remediation is included in the assurance package for
+the composed TOE, then the Flaw remediation (ALC_FLR) requirements are
+to be applied during the composed TOE evaluation (as for any augmentation).
+
+
+17.3.1.2.4 Tests
+
+
+1713 The composed TOE will have been tested during the conduct of the Class
+ATE: Tests activities for evaluation of the dependent component, as the
+configurations used for testing of the dependent component should have
+included the base component to satisfy the requirements for IT in the
+operational environment. If the base component was not used in the testing
+of the dependent component for the dependent component evaluation, or the
+configuration of either component varied from their evaluated configurations,
+then the developer testing performed for evaluation of the dependent
+component to satisfy the Class ATE: Tests requirements is to be repeated on
+the composed TOE.
+
+
+Page 356 of 430 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+## **17.4 Development evidence (ACO_DEV)**
+
+
+**17.4.1** **Evaluation of sub-activity (ACO_DEV.1)**
+
+
+17.4.1.1 Objectives
+
+
+1714 The objective of this sub-activity is to determine that the appropriate security
+functionality is provided by the base component to support the dependent
+component. This is achieved through examination of the interfaces of the
+base component to determine that they are consistent with the interfaces
+specified in the reliance information; those required by the dependent
+component.
+
+
+1715 The description of the interfaces into the base component is to be provided at
+a level of detail consistent with Evaluation of sub-activity (ADV_FSP.2)
+although not all of the aspects necessary for satisfaction of Evaluation of
+sub-activity (ADV_FSP.2) are required for Evaluation of sub-activity
+(ACO_DEV.1), as once the interface has been identified and the purpose
+described the remaining detail of the interface specification can be reused
+from evaluation of the base component.
+
+
+17.4.1.2 Input
+
+
+1716 The evaluation evidence for this sub-activity is:
+
+
+a) the composed ST;
+
+
+b) the development information;
+
+
+c) the reliance information.
+
+
+17.4.1.3 Action ACO_DEV.1.1E
+
+
+ACO_DEV.1.1C _**The development information shall describe the purpose of each interface**_
+_**of the base component used in the composed TOE.**_
+
+
+ACO_DEV.1-1 The evaluator _**shall examine**_ the development information to determine that
+it describes the purpose of each interface.
+
+
+1717 The base component provides interfaces to support interaction with the
+dependent component in the provision of the dependent TSF. The purpose of
+each interface is to be described at the same level as the description of the
+interfaces to the dependent component TSF functionality, as would be
+provided between subsystems in the TOE design (Evaluation of sub-activity
+(ADV_TDS.1)). This description is to provide the reader with an
+understanding of how the base component provides the services required by
+the dependent component TSF.
+
+
+1718 This work unit may be satisfied by the provision of the functional
+specification for the base component for those interfaces that are TSFIs of
+the base component.
+
+
+April 2017 Version 3.1 Page 357 of 430
+
+
+**Class ACO: Composition**
+
+
+ACO_DEV.1.2C _**The development information shall show correspondence between the**_
+_**interfaces, used in the composed TOE, of the base component and the**_
+_**dependent component to support the TSF of the dependent component.**_
+
+
+ACO_DEV.1-2 The evaluator _**shall examine**_ the development information to determine the
+correspondence, between the interfaces of the base component and the
+interfaces on which the dependent component relies, is accurate.
+
+
+1719 The correspondence between the interfaces of the base component and the
+interfaces on which the dependent component relies may take the form of a
+matrix or table. The interfaces that are relied upon by the dependent
+component are identified in the reliance information (as examined during
+Reliance of dependent component (ACO_REL) activity).
+
+
+1720 There is, during this activity, no requirement to determine completeness of
+the coverage of interfaces that are relied upon by the dependent component,
+only that the correspondence is correct and ensuring that interfaces of the
+base component are mapped to interfaces required by the dependent
+component wherever possible. The completeness of the coverage is
+considered in Composition rationale (ACO_COR) activities.
+
+
+17.4.1.4 Action ACO_DEV.1.2E
+
+
+ACO_DEV.1-3 The evaluator _**shall examine**_ the development information and the reliance
+information to determine that the interfaces are described consistently.
+
+
+1721 The evaluator's goal in this work unit is to determine that the interfaces
+described in the development information for the base component and the
+reliance information for the dependent component are represented
+consistently.
+
+
+**17.4.2** **Evaluation of sub-activity (ACO_DEV.2)**
+
+
+17.4.2.1 Objectives
+
+
+1722 The objective of this sub-activity is to determine that the appropriate security
+functionality is provided by the base component to support the dependent
+component. This is achieved through examination of the interfaces and
+associated security behaviour of the base component to determine that they
+are consistent with the interfaces specified in the reliance information; those
+required by the dependent component.
+
+
+17.4.2.2 Input
+
+
+1723 The evaluation evidence for this sub-activity is:
+
+
+a) the composed ST;
+
+
+b) the development information;
+
+
+c) reliance information.
+
+
+Page 358 of 430 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+
+17.4.2.3 Action ACO_DEV.2.1E
+
+
+ACO_DEV.2.1C _**The development information shall describe the purpose and method of use**_
+_**of each interface of the base component used in the composed TOE.**_
+
+
+ACO_DEV.2-1 The evaluator _**shall examine**_ the development information to determine that
+it describes the purpose of each interface.
+
+
+1724 The base component provides interfaces to support interaction with the
+dependent component in the provision of the dependent TSF. The purpose of
+each interface is to be described at the same level as the description of the
+interfaces to the dependent component TSF functionality, as would be
+provided between subsystems in the TOE design (Evaluation of sub-activity
+(ADV_TDS.1)). This description is to provide the reader with an
+understanding of how the base component provides the services required by
+the dependent component TSF.
+
+
+1725 This work unit may be satisfied by the provision of the functional
+specification for the base component for those interfaces that are TSFIs of
+the base component.
+
+
+ACO_DEV.2-2 The evaluator _**shall examine**_ the development information to determine that
+it describes the method of use for each interface.
+
+
+1726 The method of use for an interface summarises how the interface is
+manipulated in order to invoke the operations and obtain results associated
+with the interface. The evaluator should be able to determine from reading
+this material in the development information how to use each interface. This
+does not necessarily mean that there needs to be a separate method of use for
+each interface, as it may be possible to describe in general how APIs are
+invoked, for instance, and then identify each interface using that general style.
+
+
+1727 This work unit may be satisfied by the provision of the functional
+specification for the base component for those interfaces that are TSFIs of
+the base component.
+
+
+ACO_DEV.2.2C _**The development information shall provide a high-level description of the**_
+_**behaviour of the base component, which supports the enforcement of the**_
+_**dependent component SFRs.**_
+
+
+ACO_DEV.2-3 The evaluator _**shall examine**_ the development information to determine that
+it describes the behaviour of the base component that supports the
+enforcement of the dependent component SFRs.
+
+
+1728 The dependent component invokes interfaces of the base component for the
+provision of services by the base component. For the interfaces of the base
+component that are invoked, the development information shall provide a
+high-level description of the associated security behaviour of the base
+component. The description of the base component security behaviour will
+outline how the base component provides the necessary service when the call
+to the interface is made. This description is to be at a level similar to that
+
+
+April 2017 Version 3.1 Page 359 of 430
+
+
+**Class ACO: Composition**
+
+
+provided for ADV_TDS.1.4C. Therefore, the provision of the TOE design
+evidence from the base component evaluation would satisfy this work unit,
+where the interfaces invoked by the dependent component are TSFI of the
+base component. If the interfaces invoked by the dependent component are
+not TSFIs of the base component it is the associated security behaviour will
+not necessarily be described in the base component TOE design evidence.
+
+
+ACO_DEV.2.3C _**The development information shall show correspondence between the**_
+_**interfaces, used in the composed TOE, of the base component and the**_
+_**dependent component to support the TSF of the dependent component.**_
+
+
+ACO_DEV.2-4 The evaluator _**shall examine**_ the development information to determine the
+correspondence, between the interfaces of the base component and the
+interfaces on which the dependent component relies, is accurate.
+
+
+1729 The correspondence between the interfaces of the base component and the
+interfaces on which the dependent component relies may take the form of a
+matrix or table. The interfaces that are relied upon by the dependent
+component are identified in the reliance information (as examined during
+Reliance of dependent component (ACO_REL)).
+
+
+1730 There is, during this activity, no requirement to determine completeness of
+the coverage of interfaces that are relied upon by the dependent component,
+only that the correspondence is correct and ensuring that interfaces of the
+base component are mapped to interfaces required by the dependent
+component wherever possible. The completeness of the coverage is
+considered in Composition rationale (ACO_COR) activities.
+
+
+17.4.2.4 Action ACO_DEV.2.2E
+
+
+ACO_DEV.2-5 The evaluator _**shall examine**_ the development information and the reliance
+information to determine that the interfaces are described consistently.
+
+
+1731 The evaluator's goal in this work unit is to determine that the interfaces
+described in the development information for the base component and the
+reliance information for the dependent component are represented
+consistently.
+
+
+**17.4.3** **Evaluation of sub-activity (ACO_DEV.3)**
+
+
+17.4.3.1 Objectives
+
+
+1732 The objective of this sub-activity is to determine that the appropriate security
+functionality is provided by the base component to support the dependent
+component. This is achieved through examination of the interfaces and
+associated security behaviour of the base component to determine that they
+are consistent with the interfaces specified in the reliance information; those
+required by the dependent component.
+
+
+1733 In addition to the interface description, the subsystems of the base
+component that provide the security functionality required by the dependent
+
+
+Page 360 of 430 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+
+component will be described to enable the evaluator to determine whether or
+not that interface formed part of the TSF of the base component.
+
+
+17.4.3.2 Input
+
+
+1734 The evaluation evidence for this sub-activity is:
+
+
+a) the composed ST;
+
+
+b) the development information;
+
+
+c) reliance information.
+
+
+17.4.3.3 Action ACO_DEV.3.1E
+
+
+ACO_DEV.3.1C _**The development information shall describe the purpose and method of use**_
+_**of each interface of the base component used in the composed TOE.**_
+
+
+ACO_DEV.3-1 The evaluator _**shall examine**_ the development information to determine that
+it describes the purpose of each interface.
+
+
+1735 The base component provides interfaces to support interaction with the
+dependent component in the provision of the dependent TSF. The purpose of
+each interface is to be described at the same level as the description of the
+interfaces to the dependent component TSF functionality, as would be
+provided between subsystems in the TOE design (Evaluation of sub-activity
+(ADV_TDS.1)). This description is to provide the reader with an
+understanding of how the base component provides the services required by
+the dependent component TSF.
+
+
+1736 This work unit may be satisfied by the provision of the functional
+specification for the base component for those interfaces that are TSFIs of
+the base component.
+
+
+ACO_DEV.3-2 The evaluator _**shall examine**_ the development information to determine that
+it describes the method of use for each interface.
+
+
+1737 The method of use for an interface summarises how the interface is
+manipulated in order to invoke the operations and obtain results associated
+with the interface. The evaluator should be able to determine from reading
+this material in the development information how to use each interface. This
+does not necessarily mean that there needs to be a separate method of use for
+each interface, as it may be possible to describe in general how APIs are
+invoked, for instance, and then identify each interface using that general style.
+
+
+1738 This work unit may be satisfied by the provision of the functional
+specification for the base component for those interfaces that are TSFIs of
+the base component.
+
+
+ACO_DEV.3.2C _**The development information shall identify the subsystems of the base**_
+_**component that provide interfaces of the base component used in the**_
+_**composed TOE.**_
+
+
+April 2017 Version 3.1 Page 361 of 430
+
+
+**Class ACO: Composition**
+
+
+ACO_DEV.3-3 The evaluator _**shall examine**_ the development information to determine that
+all subsystems of the base component that provide interfaces to the
+dependent component are identified.
+
+
+1739 For those interfaces that are considered to form part of the TSFI of the base
+component, the subsystems associated with the interface will be subsystems
+considered in the TOE design (ADV_TDS) activity during the base
+component evaluation. The interfaces on which the dependent component
+relies that did not form part of the TSFI of the base component will map to
+subsystems outside of the base component TSF.
+
+
+ACO_DEV.3.3C _**The development information shall provide a high-level description of the**_
+_**behaviour of the base component subsystems, which support the**_
+_**enforcement of the dependent component SFRs.**_
+
+
+ACO_DEV.3-4 The evaluator _**shall examine**_ the development information to determine that
+it describes the behaviour of the base component subsystems that support the
+enforcement of the dependent component SFRs.
+
+
+1740 The dependent component invokes interfaces of the base component for the
+provision of services by the base component. For the interfaces of the base
+component that are invoked, the development information shall provide a
+high-level description of the associated security behaviour of the base
+component. The description of the base component security behaviour will
+outline how the base component provides the necessary service when the call
+to the interface is made. This description is to be at a level similar to that
+provided for ADV_TDS.1.4C. Therefore, the provision of the TOE design
+evidence from the base component evaluation would satisfy this work unit,
+where the interfaces invoked by the dependent component are TSFI of the
+base component. If the interfaces invoked by the dependent component are
+not TSFIs of the base component it is the associated security behaviour will
+not necessarily be described in the base component TOE design evidence.
+
+
+ACO_DEV.3.4C _**The development information shall provide a mapping from the interfaces**_
+_**to the subsystems of the base component.**_
+
+
+ACO_DEV.3-5 The evaluator _**shall examine**_ the development information to determine that
+the correspondence between the interfaces and subsystems of the base
+component is accurate.
+
+
+1741 If the TOE design and functional specification evidence from the base
+component evaluation is available, this can be used to verify the accuracy of
+the correspondence between the interfaces and subsystems of the base
+component as used in the composed TOE. Those interfaces of the base
+component, which formed part of the base component TSFI will be described
+in the base component functional specification, and the associated
+subsystems will be described in the base component TOE design evidence.
+The tracing between the two will be provided in the base component TOE
+design evidence.
+
+
+Page 362 of 430 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+
+1742 If, however, the base component interface did not form part of the TSFI of
+the base component, the description of the subsystem behaviour provided in
+the development information will be used to verify the accuracy of the
+correspondence.
+
+
+ACO_DEV.3.5C _**The development information shall show correspondence between the**_
+_**interfaces, used in the composed TOE, of the base component and the**_
+_**dependent component to support the TSF of the dependent component.**_
+
+
+ACO_DEV.3-6 The evaluator _**shall examine**_ the development information to determine the
+correspondence, between the interfaces of the base component and the
+interfaces on which the dependent component relies, is accurate.
+
+
+1743 The correspondence between the interfaces of the base component and the
+interfaces on which the dependent component relies may take the form of a
+matrix or table. The interfaces that are relied upon by the dependent
+component are identified in the reliance information (as examined during
+Reliance of dependent component (ACO_REL)).
+
+
+1744 There is, during this activity, no requirement to determine completeness of
+the coverage of interfaces that are relied upon by the dependent component,
+only that the correspondence is correct and ensuring that interfaces of the
+base component are mapped to interfaces required by the dependent
+component wherever possible. The completeness of the coverage is
+considered in Composition rationale (ACO_COR) activities.
+
+
+17.4.3.4 Action ACO_DEV.3.2E
+
+
+ACO_DEV.3-7 The evaluator _**shall examine**_ the development information and the reliance
+information to determine that the interfaces are described consistently.
+
+
+1745 The evaluator's goal in this work unit is to determine that the interfaces
+described in the development information for the base component and the
+reliance information for the dependent component are represented
+consistently.
+
+
+April 2017 Version 3.1 Page 363 of 430
+
+
+**Class ACO: Composition**
+
+## **17.5 Reliance of dependent component (ACO_REL)**
+
+
+**17.5.1** **Evaluation of sub-activity (ACO_REL.1)**
+
+
+17.5.1.1 Objectives
+
+
+1746 The objectives of this sub-activity are to determine whether the developer's
+reliance evidence provides sufficient information to determine that the
+necessary functionality is available in the base component, and the means by
+which that functionality is invoked. These are provided in terms of a highlevel description.
+
+
+17.5.1.2 Input
+
+
+1747 The evaluation evidence for this sub-activity is:
+
+
+a) the composed ST;
+
+
+b) the dependent component functional specification;
+
+
+c) the dependent component design;
+
+
+d) the dependent component architectural design;
+
+
+e) the reliance information.
+
+
+17.5.1.3 Application notes
+
+
+1748 A dependent component whose TSF interacts with the base component
+requires functionality provided by that base component (e.g., remote
+authentication, remote audit data storage). In these cases, those invoked
+services need to be described for those charged with configuring the
+composed TOE for end users. The rationale for requiring this documentation
+is to aid integrators of the composed TOE to determine what services in the
+base component might have adverse effects on the dependent component,
+and to provide information against which to determine the compatibility of
+the components when applying the Development evidence (ACO_DEV)
+family.
+
+
+17.5.1.4 Action ACO_REL.1.1E
+
+
+ACO_REL.1.1C _**The reliance information shall describe the functionality of the base**_
+_**component hardware, firmware and/or software that is relied upon by the**_
+_**dependent component TSF.**_
+
+
+ACO_REL.1-1 The evaluator _**shall check**_ the reliance information to determine that it
+describes the functionality of the base dependent hardware, firmware and/or
+software that is relied upon by the dependent component TSF.
+
+
+1749 The evaluator assesses the description of the security functionality that the
+dependent component TSF requires to be provided by the base component's
+hardware, firmware and software. The emphasis of this work unit is on the
+
+
+Page 364 of 430 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+
+level of detail of this description, rather than on an assessment of the
+information's accuracy. (The assessment of the accuracy of the information is
+the focus of the next work unit.)
+
+
+1750 This description of the base component's functionality need not be any more
+detailed than the level of the description of a component of the TSF, as
+would be provided in the TOE Design (TOE design (ADV_TDS))
+
+
+ACO_REL.1-2 The evaluator _**shall examine**_ the reliance information to determine that it
+accurately reflects the objectives specified for the operational environment of
+the dependent component.
+
+
+1751 The reliance information contains the description of the base component's
+security functionality relied upon by the dependent component. To ensure
+that the reliance information is consistent with the expectations of the
+operational environment of the dependent component, the evaluator
+compares the reliance information with the statement of objectives for the
+environment in the ST for the dependent component.
+
+
+1752 For example, if the reliance information claims that the dependent
+component TSF relies upon the base component to store and protect audit
+data, yet other evaluation evidence (e.g. the dependent component design)
+makes it clear that the dependent component TSF itself is storing and
+protecting the audit data, this would indicate an inaccuracy.
+
+
+1753 It should be noted that the objectives for the operational environment may
+include objectives that can be met by non-IT measures. While the services
+that the base component environment is expected to provide may be
+described in the description of IT objectives for the operational environment
+in the dependent component ST, it is not required that all such expectations
+on the environment be described in the reliance information.
+
+
+ACO_REL.1.2C _**The reliance information shall describe all interactions through which the**_
+_**dependent component TSF requests services from the base component.**_
+
+
+ACO_REL.1-3 The evaluator _**shall examine**_ the reliance information to determine that it
+describes all interactions between the dependent component and the base
+component, through which the dependent component TSF requests services
+from the base component.
+
+
+1754 The dependent component TSF may request services of the base component
+that were not within the TSF of the base component (see B.3, Interactions
+between composed IT entities in CC Part 3).
+
+
+1755 The interfaces to the base component's functionality are described at the
+same level as the description of the interfaces to the dependent component
+TSF functionality, as would be provided between subsystems in the TOE
+design (Evaluation of sub-activity (ADV_TDS.1)).
+
+
+1756 The purpose of describing the interactions between the dependent component
+and the base component is to provide an understanding of how the dependent
+
+
+April 2017 Version 3.1 Page 365 of 430
+
+
+**Class ACO: Composition**
+
+
+component TSF relies upon the base component for the provision of services
+to support the operation of security functionality of the dependent component.
+These interactions do not need to be characterised at the implementation
+level (e.g. parameters passed from one routine in a component to a routine in
+another component), but the data elements identified for a particular
+component that are going to be used by another component should be
+covered in this description. The statement should help the reader understand
+in general why the interaction is necessary.
+
+
+1757 Accuracy and completeness of the interfaces is based on the security
+functionality that the TSF requires to be provided by the base component, as
+assessed in work units ACO_REL.1-1 and ACO_REL.1-2. It should be
+possible to map all of the functionality described in the earlier work units to
+the interfaces identified in this work unit, and vice versa. An interface that
+does not correspond to described functionality would also indicate an
+inadequacy.
+
+
+ACO_REL.1.3C _**The reliance information shall describe how the dependent TSF protects**_
+_**itself from interference and tampering by the base component.**_
+
+
+ACO_REL.1-4 The evaluator _**shall examine**_ the reliance information to determine that it
+describes how the dependent TSF protects itself from interference and
+tampering by the base component.
+
+
+1758 The description of how the dependent component protects itself from
+interference and tampering by the base component is to be provided at the
+same level of detail as necessary for ADV_ARC.1-4.
+
+
+**17.5.2** **Evaluation of sub-activity (ACO_REL.2)**
+
+
+17.5.2.1 Objectives
+
+
+1759 The objectives of this sub-activity are to determine whether the developer's
+reliance evidence provides sufficient information to determine that the
+necessary functionality is available in the base component, and the means by
+which that functionality is invoked. This is provided in terms of the
+interfaces between the dependent and base component and the return values
+from those interfaces called by the dependent component.
+
+
+17.5.2.2 Input
+
+
+1760 The evaluation evidence for this sub-activity is:
+
+
+a) the composed ST;
+
+
+b) the dependent component functional specification;
+
+
+c) the dependent component design;
+
+
+d) the dependent component implementation representation;
+
+
+e) the dependent component architectural design;
+
+
+Page 366 of 430 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+
+f) the reliance information.
+
+
+17.5.2.3 Application notes
+
+
+1761 A dependent component whose TSF interacts with the base component
+requires functionality provided by that base component (e.g., remote
+authentication, remote audit data storage). In these cases, those invoked
+services need to be described for those charged with configuring the
+composed TOE for end users. The rationale for requiring this documentation
+is to aid integrators of the composed TOE to determine what services in the
+base component might have adverse effects on the dependent component,
+and to provide information against which to determine the compatibility of
+the components when applying the Development evidence (ACO_DEV)
+family.
+
+
+17.5.2.4 Action ACO_REL.2.1E
+
+
+ACO_REL.2.1C _**The reliance information shall describe the functionality of the base**_
+_**component hardware, firmware and/or software that is relied upon by the**_
+_**dependent component TSF.**_
+
+
+ACO_REL.2-1 The evaluator _**shall check**_ the reliance information to determine that it
+describes the functionality of the base dependent hardware, firmware and/or
+software that is relied upon by the dependent component TSF.
+
+
+1762 The evaluator assesses the description of the security functionality that the
+dependent component TSF requires to be provided by the base component's
+hardware, firmware and software. The emphasis of this work unit is on the
+level of detail of this description, rather than on an assessment of the
+information's accuracy. (The assessment of the accuracy of the information is
+the focus of the next work unit.)
+
+
+1763 This description of the base component's functionality need not be any more
+detailed than the level of the description of a component of the TSF, as
+would be provided in the TOE Design (TOE design (ADV_TDS))
+
+
+ACO_REL.2-2 The evaluator _**shall examine**_ the reliance information to determine that it
+accurately reflects the objectives specified for the operational environment of
+the dependent component.
+
+
+1764 The reliance information contains the description of the base component's
+security functionality relied upon by the dependent component. To ensure
+that the reliance information is consistent with the expectations of the
+operational environment of the dependent component, the evaluator
+compares the reliance information with the statement of objectives for the
+environment in the ST for the dependent component.
+
+
+1765 For example, if the reliance information claims that the dependent
+component TSF relies upon the base component to store and protect audit
+data, yet other evaluation evidence (e.g. the dependent component design)
+
+
+April 2017 Version 3.1 Page 367 of 430
+
+
+**Class ACO: Composition**
+
+
+makes it clear that the dependent component TSF itself is storing and
+protecting the audit data, this would indicate an inaccuracy.
+
+
+1766 It should be noted that the objectives for the operational environment may
+include objectives that can be met by non-IT measures. While the services
+that the base component environment is expected to provide may be
+described in the description of IT objectives for the operational environment
+in the dependent component ST, it is not required that all such expectations
+on the environment be described in the reliance information.
+
+
+ACO_REL.2.2C _**The reliance information shall describe all interactions through which the**_
+_**dependent component TSF requests services from the base component.**_
+
+
+ACO_REL.2-3 The evaluator _**shall examine**_ the reliance information to determine that it
+describes all interactions between the dependent component and the base
+component, through which the dependent component TSF requests services
+from the base component.
+
+
+1767 The dependent component TSF may request services of the base component
+that were not within the TSF of the base component (see Annex B.3,
+Interactions between composed IT entities in CC Part 3).
+
+
+1768 The interfaces to the base component's functionality are described at the
+same level as the description of the interfaces to the dependent component
+TSF functionality, as would be provided between subsystems in the TOE
+design (Evaluation of sub-activity (ADV_TDS.1)).
+
+
+1769 The purpose of describing the interactions between the dependent component
+and the base component is to provide an understanding of how the dependent
+component TSF relies upon the base component for the provision of services
+to support the operation of security functionality of the dependent component.
+These interactions do not need to be characterised at the implementation
+level (e.g. parameters passed from one routine in a component to a routine in
+another component), but the data elements identified for a particular
+component that are going to be used by another component should be
+covered in this description. The statement should help the reader understand
+in general why the interaction is necessary.
+
+
+1770 Accuracy and completeness of the interfaces is based on the security
+functionality that the TSF requires to be provided by the base component, as
+assessed in work units ACO_REL.2-1 and ACO_REL.2-2. It should be
+possible to map all of the functionality described in the earlier work units to
+the interfaces identified in this work unit, and vice versa. An interface that
+does not correspond to described functionality would also indicate an
+inadequacy.
+
+
+ACO_REL.2.3C _**The reliance information shall describe each interaction in terms of the**_
+_**interface used and the return values from those interfaces.**_
+
+
+ACO_REL.2-4 The reliance information shall describe each interaction in terms of the
+interface used and the return values from those interfaces.
+
+
+Page 368 of 430 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+
+1771 The identification of the interfaces used by the dependent component TSF
+when making services requests of the base component allows an integrator to
+determine whether the base component provides all the necessary
+corresponding interfaces. This understanding is further gained through the
+specification of the return values expected by the dependent component. The
+evaluator ensures that interfaces are described for each interaction specified
+(as analysed in ACO_REL.2-3).
+
+
+ACO_REL.2.4C _**The reliance information shall describe how the dependent TSF protects**_
+_**itself from interference and tampering by the base component.**_
+
+
+ACO_REL.2-5 The evaluator _**shall examine**_ the reliance information to determine that it
+describes how the dependent TSF protects itself from interference and
+tampering by the base component.
+
+
+1772 The description of how the dependent component protects itself from
+interference and tampering by the base component is to be provided at the
+same level of detail as necessary for ADV_ARC.1-4.
+
+
+April 2017 Version 3.1 Page 369 of 430
+
+
+**Class ACO: Composition**
+
+## **17.6 Composed TOE testing (ACO_CTT)**
+
+
+**17.6.1** **Evaluation of sub-activity (ACO_CTT.1)**
+
+
+17.6.1.1 Objectives
+
+
+1773 The objective of this sub-activity is to determine whether the developer
+correctly performed and documented tests for each of the base component
+interfaces on which the dependent component relies. As part of this
+determination the evaluator repeats a sample of the tests performed by the
+developer and performs any additional tests required to ensure the expected
+behaviour of all composed TOE SFRs and interfaces of the base component
+relied upon by the dependent component is demonstrated.
+
+
+17.6.1.2 Input
+
+
+1774 The evaluation evidence for this sub-activity is:
+
+
+a) the composed TOE suitable for testing;
+
+
+b) the composed TOE testing evidence;
+
+
+c) the reliance information;
+
+
+d) the development information.
+
+
+17.6.1.3 Action ACO_CTT.1.1E
+
+
+ACO_CTT.1.1C _**The composed TOE and base component interface test documentation**_
+_**shall consist of test plans, expected test results and actual test results.**_
+
+
+ACO_CTT.1-1 The evaluator _**shall examine**_ the composed TOE test documentation to
+determine that it consists of test plans, expected test results and actual test
+results.
+
+
+1775 This work unit may be satisfied by provision of the test evidence from the
+evaluation of the dependent component if the base component was used to
+satisfy the requirements for IT in the operational environment of the
+dependent component.
+
+
+1776 All work units necessary for the satisfaction of ATE_FUN.1.1E will be
+applied to determine:
+
+
+a) that the test documentation consist of test plans expected test results
+and actual test results;
+
+
+b) that the test documentation contains the information necessary to
+ensure the tests are repeatable;
+
+
+c) the level of developer effort that was applied to testing of the base
+component.
+
+
+Page 370 of 430 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+
+ACO_CTT.1-2 The evaluator _**shall examine**_ the base component interface test
+documentation to determine that it consists of test plans, expected test results
+and actual test results.
+
+
+1777 This work unit may be satisfied by provision of the test evidence from the
+evaluation of the base component for those interfaces relied upon in the
+composed TOE by the dependent component are TSFIs of the successfully
+evaluated base component. The determination of whether the interfaces of
+the base component relied upon by the dependent component were in fact
+TSFIs of the evaluated base component is made during the ACO_COR
+activity.
+
+
+1778 All work units necessary for the satisfaction of ATE_FUN.1.1E will be
+applied to determine:
+
+
+a) that the test documentation consist of test plans expected test results
+and actual test results;
+
+
+b) that the test documentation contains the information necessary to
+ensure the tests are repeatable;
+
+
+c) the level of developer effort that was applied to testing of the base
+component.
+
+
+ACO_CTT.1.2C _**The test documentation from the developer execution of the composed**_
+_**TOE tests shall demonstrate that the TSF behaves as specified.**_
+
+
+ACO_CTT.1-3 The evaluator _**shall examine**_ the test documentation to determine that the
+developer execution of the composed TOE tests shall demonstrate that the
+TSF behaves as specified.
+
+
+1779 The evaluator should construct a mapping between the tests described in the
+test plan and the SFRs specified for the composed TOE to identify which
+SFRs have been tested by the developer.
+
+
+1780 Guidance on this work unit can be found in:
+
+
+a) Chapter 15.2.1.
+
+
+b) Chapter 15.2.2.
+
+
+1781 The outputs from the successful execution of the tests (as assessed for
+ATE_FUN.1.3C can be compared with the mapping to determine that the
+SFRs of the composed TOE, as tested by the developer, behave as expected.
+
+
+ACO_CTT.1.3C _**The test documentation from the developer execution of the base**_
+_**component interface tests shall demonstrate that the base component**_
+_**interface relied upon by the dependent component behaves as specified.**_
+
+
+ACO_CTT.1-4 The evaluator _**shall examine**_ the test documentation to determine that the
+developer execution of the base component interface tests shall demonstrate
+
+
+April 2017 Version 3.1 Page 371 of 430
+
+
+**Class ACO: Composition**
+
+
+that the base component interfaces relied upon by the dependent component
+behave as specified.
+
+
+1782 The evaluator should construct a mapping between the tests described in the
+test plan and the interfaces of the base component relied upon by the
+dependent component (as specified in the reliance information, examined
+under ACO_REL) to identify which base component interfaces have been
+tested by the developer.
+
+
+1783 Guidance on this work unit can be found in:
+
+
+a) Chapter 15.2.1.
+
+
+b) Chapter 15.2.2.
+
+
+1784 The outputs from the successful execution of the tests (as assessed for
+ATE_FUN.1.3C can be compared with the mapping to determine that the
+interfaces of the base component, as tested by the developer, behave as
+expected.
+
+
+ACO_CTT.1.4C _**The base component shall be suitable for testing.**_
+
+
+ACO_CTT.1-5 The evaluator _**shall examine**_ the composed TOE to determine that it has
+been installed properly and is in a known state.
+
+
+1785 To determine that the composed TOE has been installed properly and is in a
+known state the ATE_IND.2-1 and ATE_IND.2-2 work units will be applied
+to the TOE provided by the developer for testing.
+
+
+ACO_CTT.1-6 The evaluator _**shall examine**_ the set of resources provided by the developer
+to determine that they are equivalent to the set of resources used by the base
+component developer to functionally test the base component.
+
+
+1786 To determine that the set of resources provided are equivalent to those used
+to functionally test the base component as used in the composed TOE, the
+ATE_IND.2-3 work unit will be applied.
+
+
+17.6.1.4 Action ACO_CTT.1.2E
+
+
+ACO_CTT.1-7 The evaluator _**shall perform**_ testing in accordance with ATE_IND.2.2E, for a
+subset of the SFRs specified in the composed security target, to verify the
+developer test results.
+
+
+1787 The evaluator will apply all work units necessary for the satisfaction of
+ATE_IND.2.2E, reporting in the ETR for the composed TOE all analysis,
+results and verdicts as dictated by the associated work units.
+
+
+17.6.1.5 Action ACO_CTT.1.3E
+
+
+ACO_CTT.1-8 The evaluator _**shall perform**_ testing in accordance with ATE_IND.2.3E, for a
+subset of the SFRs specified in the composed security target, to confirm that
+the TSF operates as specified.
+
+
+Page 372 of 430 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+
+1788 The evaluator will apply all work units necessary for the satisfaction of
+ATE_IND.2.3E, reporting in the ETR for the composed TOE all analysis,
+results and verdicts as dictated by the work units.
+
+
+1789 When selecting interfaces of the TSF of the composed TOE to test, the
+evaluator should take into account any modifications to the components from
+the evaluated version or configuration. Modifications to the component from
+that evaluated may include patches introduced, a different configuration as a
+result of modified guidance documentation, reliance an additional portion of
+the component that was not within the TSF of the component. These
+modifications will have been identified during the Composition rationale
+(ACO_COR) activity.
+
+
+**17.6.2** **Evaluation of sub-activity (ACO_CTT.2)**
+
+
+17.6.2.1 Objectives
+
+
+1790 The objective of this sub-activity is to determine whether the developer
+correctly performed and documented tests for each of the base component
+interfaces on which the dependent component relies. As part of this
+determination the evaluator repeats a sample of the tests performed by the
+developer and performs any additional tests required to fully demonstrate the
+expected behaviour of the composed TOE and the interfaces of the base
+component relied upon by the dependent component.
+
+
+17.6.2.2 Input
+
+
+1791 The evaluation evidence for this sub-activity is:
+
+
+a) the composed TOE suitable for testing;
+
+
+b) the composed TOE testing evidence;
+
+
+c) the reliance information;
+
+
+d) the development information.
+
+
+17.6.2.3 Action ACO_CTT.2.1E
+
+
+ACO_CTT.2.1C _**The composed TOE and base component interface test documentation**_
+_**shall consist of test plans, expected test results and actual test results.**_
+
+
+ACO_CTT.2-1 The evaluator _**shall examine**_ the composed TOE test documentation to
+determine that it consists of test plans, expected test results and actual test
+results.
+
+
+1792 This work unit may be satisfied by provision of the test evidence from the
+evaluation of the dependent component if the base component was used to
+satisfy the requirements for IT in the operational environment of the
+dependent component.
+
+
+April 2017 Version 3.1 Page 373 of 430
+
+
+**Class ACO: Composition**
+
+
+1793 All work units necessary for the satisfaction of ATE_FUN.1.1E will be
+applied to determine:
+
+
+a) that the test documentation consist of test plans expected test results
+and actual test results;
+
+
+b) that the test documentation contains the information necessary to
+ensure the tests are repeatable;
+
+
+c) the level of developer effort that was applied to testing of the base
+component.
+
+
+ACO_CTT.2-2 The evaluator _**shall examine**_ the base component interface test
+documentation to determine that it consists of test plans, expected test results
+and actual test results.
+
+
+1794 This work unit may be satisfied by provision of the test evidence from the
+evaluation of the base component for those interfaces relied upon in the
+composed TOE by the dependent component are TSFIs of the successfully
+evaluated base component. The determination of whether the interfaces of
+the base component relied upon by the dependent component were in fact
+TSFIs of the evaluated base component is made during the ACO_COR
+activity.
+
+
+1795 All work units necessary for the satisfaction of ATE_FUN.1.1E will be
+applied to determine:
+
+
+a) that the test documentation consist of test plans expected test results
+and actual test results;
+
+
+b) that the test documentation contains the information necessary to
+ensure the tests are repeatable;
+
+
+c) the level of developer effort that was applied to testing of the base
+component.
+
+
+ACO_CTT.2.2C _**The test documentation from the developer execution of the composed**_
+_**TOE tests shall demonstrate that the TSF behaves as specified and is**_
+_**complete.**_
+
+
+ACO_CTT.2-3 The evaluator _**shall examine**_ the test documentation to determine that it
+provides accurate correspondence between the tests in the test documentation
+relating to the testing of the composed TOE and the composed TOE SFRs in
+the composed TOE security target.
+
+
+1796 A simple cross-table may be sufficient to show test correspondence. The
+identification of correspondence between the tests and SFRs presented in the
+test documentation has to be unambiguous.
+
+
+ACO_CTT.2-4 The evaluator _**shall examine**_ the test documentation to determine that the
+developer execution of the composed TOE tests shall demonstrate that the
+TSF behaves as specified.
+
+
+Page 374 of 430 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+
+1797 Guidance on this work unit can be found in:
+
+
+a) Chapter 15.2.1.
+
+
+b) Chapter 15.2.2.
+
+
+1798 The outputs from the successful execution of the tests (as assessed for
+ATE_FUN.1.3C can be compared with the mapping to determine that the
+SFRs of the composed TOE, as tested by the developer, behave as expected.
+
+
+ACO_CTT.2.3C _**The test documentation from the developer execution of the base**_
+_**component interface tests shall demonstrate that the base component**_
+_**interface relied upon by the dependent component behaves as specified and**_
+_**is complete.**_
+
+
+ACO_CTT.2-5 The evaluator _**shall examine**_ the test documentation to determine that it
+provides accurate correspondence between the tests in the test documentation
+relating to the testing of the base component interfaces relied upon by the
+dependent component and the interfaces specified in the reliance information.
+
+
+1799 A simple cross-table may be sufficient to show test correspondence. The
+identification of correspondence between the tests and interfaces presented in
+the test documentation has to be unambiguous.
+
+
+ACO_CTT.2-6 The evaluator _**shall examine**_ the test documentation to determine that the
+developer execution of the base component interface tests shall demonstrate
+that the base component interfaces relied upon by the dependent component
+behave as specified.
+
+
+1800 Guidance on this work unit can be found in:
+
+
+a) Chapter 15.2.1.
+
+
+b) Chapter 15.2.2.
+
+
+1801 The outputs from the successful execution of the tests (as assessed for
+ATE_FUN.1.3C can be compared with the mapping to determine that the
+interfaces of the base component, as tested by the developer, behave as
+expected.
+
+
+ACO_CTT.2.4C _**The base component shall be suitable for testing.**_
+
+
+ACO_CTT.2-7 The evaluator _**shall examine**_ the composed TOE to determine that it has
+been installed properly and is in a known state.
+
+
+1802 To determine that the composed TOE has been installed properly and is in a
+known state the ATE_IND.2-1 and ATE_IND.2-2 work units will be applied
+to the TOE provided by the developer for testing.
+
+
+ACO_CTT.2-8 The evaluator _**shall examine**_ the set of resources provided by the developer
+to determine that they are equivalent to the set of resources used by the base
+component developer to functionally test the base component.
+
+
+April 2017 Version 3.1 Page 375 of 430
+
+
+**Class ACO: Composition**
+
+
+1803 To determine that the set of resources provided are equivalent to those used
+to functionally test the base component as used in the composed TOE, the
+ATE_IND.2-3 work unit will be applied.
+
+
+17.6.2.4 Action ACO_CTT.2.2E
+
+
+ACO_CTT.2-9 The tests are to be selected and executed in accordance with ATE_IND.2.2E,
+to demonstrate the correct behaviour of the SFRs specified in the composed
+TOE security target.
+
+
+1804 The evaluator will apply all work units necessary for the satisfaction of
+ATE_IND.2.2E, reporting in the ETR for the composed TOE all analysis,
+results and verdicts as dictated by the associated work units.
+
+
+17.6.2.5 Action ACO_CTT.2.3E
+
+
+ACO_CTT.2-10 The evaluator _**shall perform**_ testing in accordance with ATE_IND.2.3E, for a
+subset of the SFRs specified in the composed security target, to confirm that
+the TSF operates as specified.
+
+
+1805 The evaluator will apply all work units necessary for the satisfaction of
+ATE_IND.2.3E, reporting in the ETR for the composed TOE all analysis,
+results and verdicts as dictated by the work units.
+
+
+1806 When selecting interfaces of the TSF of the composed TOE to test, the
+evaluator should take into account any modifications to the components from
+the evaluated version or configuration. Modifications to the component from
+that evaluated may include patches introduced, a different configuration as a
+result of modified guidance documentation, reliance an additional portion of
+the component that was not within the TSF of the component. These
+modifications will have been identified during the Composition rationale
+(ACO_COR) activity.
+
+
+ACO_CTT.2-11 The evaluator _**shall perform**_ testing, in accordance with Evaluation of subactivity (ATE_IND.2), for a subset of the interfaces to the base component to
+confirm they operate as specified.
+
+
+1807 The evaluator will apply all work units necessary for the satisfaction of
+ATE_IND.2.3E, reporting in the ETR for the composed TOE all analysis,
+results and verdicts as dictated by the work units.
+
+
+1808 When selecting interfaces of the base component to test, the evaluator should
+take into account any modifications to the base component from the
+evaluated version or configuration. In particular, the evaluator should
+consider the development of tests to demonstrate the correct behaviour of
+interfaces of the base component that were not considered during the
+evaluation of the base component. These additional interfaces and other
+modifications to the base component will have been identified during the
+Composition rationale (ACO_COR) activity.
+
+
+Page 376 of 430 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+## **17.7 Composition vulnerability analysis (ACO_VUL)**
+
+
+**17.7.1** **Evaluation of sub-activity (ACO_VUL.1)**
+
+
+17.7.1.1 Objectives
+
+
+1809 The objective of this sub-activity is to determine whether the composed TOE,
+in its operational environment, has easily exploitable vulnerabilities.
+
+
+1810 The developer provides details of any residual vulnerabilities reported from
+evaluation of the components. The evaluator performs an analysis of the
+disposition the residual vulnerabilities reported and also performs a search of
+the public domain, to identify any new potential vulnerabilities in the
+components (i.e. those issues that have been reported in the public domain
+since evaluation of the base component). The evaluator then performs
+penetration testing to demonstrate that the potential vulnerabilities cannot be
+exploited in the TOE, in its operational environment, by an attacker with
+basic attack potential.
+
+
+17.7.1.2 Input
+
+
+1811 The evaluation evidence for this sub-activity is:
+
+
+a) the composed TOE suitable for testing;
+
+
+b) the composed ST;
+
+
+c) the composition rationale;
+
+
+d) the guidance documentation;
+
+
+e) information publicly available to support the identification of
+possible security vulnerabilities;
+
+
+f) residual vulnerabilities reported during evaluation of each component.
+
+
+17.7.1.3 Application notes
+
+
+1812 See the application notes for Evaluation of sub-activity (AVA_VAN.1).
+
+
+17.7.1.4 Action ACO_VUL.1.1E
+
+
+ACO_VUL.1.1C _**The composed TOE shall be suitable for testing.**_
+
+
+ACO_VUL.1-1 The evaluator _**shall examine**_ the composed TOE to determine that it has
+been installed properly and is in a known state.
+
+
+1813 To determine that the composed TOE has been installed properly and is in a
+known state the ATE_IND.2-1 and ATE_IND.2-2 work units will be applied
+to the composed TOE.
+
+
+April 2017 Version 3.1 Page 377 of 430
+
+
+**Class ACO: Composition**
+
+
+1814 If the assurance package includes a component from the ACO_CTT family,
+then the evaluator may refer to the result of the work unit ACO_CTT*-1 to
+demonstrate this has been satisfied.
+
+
+ACO_VUL.1-2 The evaluator _**shall examine**_ the composed TOE configuration to determine
+that any assumptions and objectives in the STs the components relating to IT
+entities for are fulfilled by the other components.
+
+
+1815 The STs for the component may include assumptions about other
+components that may use the component to which the ST relates, e.g. the ST
+for an operating system used as a base component may include an
+assumption that any applications loaded on the operating system do not run
+in privileged mode. These assumptions and objectives are to be fulfilled by
+other components in the composed TOE.
+
+
+17.7.1.5 Action ACO_VUL.1.2E
+
+
+ACO_VUL.1-3 The evaluator _**shall examine**_ the residual vulnerabilities from the base
+component evaluation to determine that they are not exploitable in the
+composed TOE in its operational environment.
+
+
+1816 The list of vulnerabilities identified in the product during the evaluation of
+the base component, which were demonstrated to be non-exploitable in the
+base component, is to be used as an input into this activity. The evaluator
+will determine that the premise(s) on which a vulnerability was deemed to be
+non-exploitable is upheld in the composed TOE, or whether the combination
+has re-introduced the potential vulnerability. For example, if during
+evaluation of the base component it was assumed that a particular operating
+system service was disabled, which is enabled in the composed TOE
+evaluation, any potential vulnerabilities relating to that service previously
+scoped out should now be considered.
+
+
+1817 Also, this list of known, non-exploitable vulnerabilities resulting from the
+evaluation of the base component should be considered in the light of any
+known, non-exploitable vulnerabilities for the other components (e.g.
+dependent component) within the composed TOE. This is to consider the
+case where a potential vulnerability that is non-exploitable in isolation is
+exploitable when integrated with an IT entity containing another potential
+vulnerability.
+
+
+ACO_VUL.1-4 The evaluator _**shall examine**_ the residual vulnerabilities from the dependent
+component evaluation to determine that they are not exploitable in the
+composed TOE in its operational environment.
+
+
+1818 The list of vulnerabilities identified in the product during the evaluation of
+the dependent component, which were demonstrated to be non-exploitable in
+the dependent component, is to be used as an input into this activity. The
+evaluator will determine that the premise(s) on which a vulnerability was
+deemed to be non-exploitable is upheld in the composed TOE, or whether the
+combination has re-introduced the potential vulnerability. For example, if
+during evaluation of the dependent component it was assumed that IT
+
+
+Page 378 of 430 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+
+meeting the operational environment requirements would not return a certain
+value in response to a service request, which is provided by the base
+component in the composed TOE evaluation, any potential vulnerabilities
+relating to that return value previously scoped out should now be considered.
+
+
+1819 Also, this list of known, non-exploitable vulnerabilities resulting from the
+evaluation of the dependent component should be considered in the light of
+any known, non-exploitable vulnerabilities for the other components (e.g.
+base component) within the composed TOE. This is to consider the case
+where a potential vulnerability that is non-exploitable in isolation is
+exploitable when integrated with an IT entity containing another potential
+vulnerability.
+
+
+17.7.1.6 Action ACO_VUL.1.3E
+
+
+ACO_VUL.1-5 The evaluator _**shall examine**_ the sources of information publicly available to
+support the identification of possible security vulnerabilities in the base
+component that have become known since the completion of evaluation of
+the base component.
+
+
+1820 The evaluator will use the information in the public domain as described in
+AVA_VAN.1-2 to search for vulnerabilities in the base component.
+
+
+1821 Those potential vulnerabilities that were publicly available prior to the
+evaluation of the base component do not have to be further investigated
+unless it is apparent to the evaluator that the attack potential required by an
+attacker to exploit the potential vulnerability has been significantly reduced.
+This may be through the introduction of some new technology since the base
+component evaluation that means the exploitation of the potential
+vulnerability has been simplified.
+
+
+ACO_VUL.1-6 The evaluator _**shall examine**_ the sources of information publicly available to
+support the identification of possible security vulnerabilities in the dependent
+component that have become known since the completion of the dependent
+component evaluation.
+
+
+1822 The evaluator will use the information in the public domain as described in
+AVA_VAN.1-2 to search for vulnerabilities in the dependent component.
+
+
+1823 Those potential vulnerabilities that were publicly available prior to the
+evaluation of the dependent component do not have to be further investigated
+unless it is apparent to the evaluator that the attack potential required by an
+attacker to exploit the potential vulnerability has been significantly reduced.
+This may be through the introduction of some new technology since
+evaluation of the dependent component that means the exploitation of the
+potential vulnerability has been simplified.
+
+
+ACO_VUL.1-7 The evaluator _**shall record**_ in the ETR the identified potential security
+vulnerabilities that are candidates for testing and applicable to the composed
+TOE in its operational environment.
+
+
+April 2017 Version 3.1 Page 379 of 430
+
+
+**Class ACO: Composition**
+
+
+1824 The ST, guidance documentation and functional specification are used to
+determine whether the vulnerabilities are relevant to the composed TOE in
+its operational environment.
+
+
+1825 The evaluator records any reasons for exclusion of vulnerabilities from
+further consideration if the evaluator determines that the vulnerability is not
+applicable in the operational environment. Otherwise the evaluator records
+the potential vulnerability for further consideration.
+
+
+1826 A list of potential vulnerabilities applicable to the composed TOE in its
+operational environment, which can be used as an input into penetration
+testing activities (i.e. ACO_VUL.1.4E), shall be reported in the ETR by the
+evaluators.
+
+
+17.7.1.7 Action ACO_VUL.1.4E
+
+
+ACO_VUL.1-8 The evaluator _**shall conduct**_ penetration testing as detailed for
+AVA_VAN.1.3E.
+
+
+1827 The evaluator will apply all work units necessary for the satisfaction of
+evaluator action AVA_VAN.1.3E, reporting in the ETR for the composed
+TOE all analysis and verdicts as dictated by the work units.
+
+
+1828 The evaluator will also apply the work units for the evaluator action
+AVA_VAN.1.1E to determine that the composed TOE provided by the
+developer is suitable for testing.
+
+
+**17.7.2** **Evaluation of sub-activity (ACO_VUL.2)**
+
+
+17.7.2.1 Objectives
+
+
+1829 The objective of this sub-activity is to determine whether the composed TOE,
+in its operational environment, has vulnerabilities exploitable by attackers
+possessing basic attack potential.
+
+
+1830 The developer provides an analysis of the disposition of any residual
+vulnerabilities reported for the components and of any vulnerabilities
+introduced through the combination of the base and dependent components.
+The evaluator performs a search of the public domain to identify any new
+potential vulnerabilities in the components (i.e. those issues that have been
+reported in the public domain since the completion of the evaluation of the
+components). The evaluator will also perform an independent vulnerability
+analysis of the composed TOE and penetration testing.
+
+
+17.7.2.2 Input
+
+
+1831 The evaluation evidence for this sub-activity is:
+
+
+a) the composed TOE suitable for testing;
+
+
+b) the composed ST;
+
+
+Page 380 of 430 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+
+c) the composition rationale;
+
+
+d) the reliance information;
+
+
+e) the guidance documentation;
+
+
+f) information publicly available to support the identification of
+possible security vulnerabilities.
+
+
+g) residual vulnerabilities reported during evaluation of each component.
+
+
+17.7.2.3 Application notes
+
+
+1832 See the application notes for Evaluation of sub-activity (AVA_VAN.2).
+
+
+17.7.2.4 Action ACO_VUL.2.1E
+
+
+ACO_VUL.2.1C _**The composed TOE shall be suitable for testing.**_
+
+
+ACO_VUL.2-1 The evaluator _**shall examine**_ the composed TOE to determine that it has
+been installed properly and is in a known state.
+
+
+1833 To determine that the composed TOE has been installed properly and is in a
+known state the ATE_IND.2-1 and ATE_IND.2-2 work units will be applied
+to the composed TOE.
+
+
+1834 If the assurance package includes ACO_CTT family, then the evaluator may
+refer to the result of the work unit Composed TOE testing (ACO_CTT)*-1 to
+demonstrate this has been satisfied.
+
+
+ACO_VUL.2-2 The evaluator _**shall examine**_ the composed TOE configuration to determine
+that any assumptions and objectives in the STs the components relating to IT
+entities for are fulfilled by the other components.
+
+
+1835 The STs for the component may include assumptions about other
+components that may use the component to which the ST relates, e.g. the ST
+for an operating system used as a base component may include an
+assumption that any applications loaded on the operating system do not run
+in privileged mode. These assumptions and objectives are to be fulfilled by
+other components in the composed TOE.
+
+
+17.7.2.5 Action ACO_VUL.2.2E
+
+
+ACO_VUL.2-3 The evaluator _**shall examine**_ the residual vulnerabilities from the base
+component evaluation to determine that they are not exploitable in the
+composed TOE in its operational environment.
+
+
+1836 The list of vulnerabilities identified in the product during the evaluation of
+the base component, which were demonstrated to be non-exploitable in the
+base component, is to be used as an input into this activity. The evaluator
+will determine that the premise(s) on which a vulnerability was deemed to be
+non-exploitable is upheld in the composed TOE, or whether the combination
+
+
+April 2017 Version 3.1 Page 381 of 430
+
+
+**Class ACO: Composition**
+
+
+has re-introduced the potential vulnerability. For example, if during
+evaluation of the base component it was assumed that a particular operating
+system service was disabled, which is enabled in the composed TOE
+evaluation, any potential vulnerabilities relating to that service previously
+scoped out should now be considered.
+
+
+1837 Also, this list of known, non-exploitable vulnerabilities resulting from the
+evaluation of the base component should be considered in the light of any
+known, non-exploitable vulnerabilities for the other components (e.g.
+dependent component) within the composed TOE. This is to consider the
+case where a potential vulnerability that is non-exploitable in isolation is
+exploitable when integrated with an IT entity containing another potential
+vulnerability.
+
+
+ACO_VUL.2-4 The evaluator _**shall examine**_ the residual vulnerabilities from the dependent
+component evaluation to determine that they are not exploitable in the
+composed TOE in its operational environment.
+
+
+1838 The list of vulnerabilities identified in the product during the evaluation of
+the dependent component, which were demonstrated to be non-exploitable in
+the dependent component, is to be used as an input into this activity. The
+evaluator will determine that the premise(s) on which a vulnerability was
+deemed to be non-exploitable is upheld in the composed TOE, or whether the
+combination has re-introduced the potential vulnerability. For example, if
+during evaluation of the dependent component it was assumed that IT
+meeting the operational environment requirements would not return a certain
+value in response to a service request, which is provided by the base
+component in the composed TOE evaluation, any potential vulnerabilities
+relating to that return value previously scoped out should now be considered.
+
+
+1839 Also, this list of known, non-exploitable vulnerabilities resulting from the
+evaluation of the dependent component should be considered in the light of
+any known, non-exploitable vulnerabilities for the other components (e.g.
+base component) within the composed TOE. This is to consider the case
+where a potential vulnerability that is non-exploitable in isolation is
+exploitable when integrated with an IT entity containing another potential
+vulnerability.
+
+
+17.7.2.6 Action ACO_VUL.2.3E
+
+
+ACO_VUL.2-5 The evaluator _**shall examine**_ the sources of information publicly available to
+support the identification of possible security vulnerabilities in the base
+component that have become known since the completion of the base
+component evaluation.
+
+
+1840 The evaluator will use the information in the public domain as described in
+AVA_VAN.2-2 to search for vulnerabilities in the base component.
+
+
+1841 Those potential vulnerabilities that were publicly available prior to the
+evaluation of the base component do not have to be further investigated
+unless it is apparent to the evaluator that the attack potential required by an
+
+
+Page 382 of 430 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+
+attacker to exploit the potential vulnerability has been significantly reduced.
+This may be through the introduction of some new technology since the base
+component evaluation that means the exploitation of the potential
+vulnerability has been simplified.
+
+
+ACO_VUL.2-6 The evaluator _**shall examine**_ the sources of information publicly available to
+support the identification of possible security vulnerabilities in the dependent
+component that have become known since the completion of the dependent
+component evaluation.
+
+
+1842 The evaluator will use the information in the public domain as described in
+AVA_VAN.2-2 to search for vulnerabilities in the dependent component.
+
+
+1843 Those potential vulnerabilities that were publicly available prior to the
+evaluation of the dependent component do not have to be further investigated
+unless it is apparent to the evaluator that the attack potential required by an
+attacker to exploit the potential vulnerability has been significantly reduced.
+This may be through the introduction of some new technology since
+evaluation of the dependent component that means the exploitation of the
+potential vulnerability has been simplified.
+
+
+ACO_VUL.2-7 The evaluator _**shall record**_ in the ETR the identified potential security
+vulnerabilities that are candidates for testing and applicable to the composed
+TOE in its operational environment.
+
+
+1844 The ST, guidance documentation and functional specification are used to
+determine whether the vulnerabilities are relevant to the composed TOE in
+its operational environment.
+
+
+1845 The evaluator records any reasons for exclusion of vulnerabilities from
+further consideration if the evaluator determines that the vulnerability is not
+applicable in the operational environment. Otherwise the evaluator records
+the potential vulnerability for further consideration.
+
+
+1846 A list of potential vulnerabilities applicable to the composed TOE in its
+operational environment, which can be used as an input into penetration
+testing activities (ACO_VUL.2.5E), shall be reported in the ETR by the
+evaluators.
+
+
+17.7.2.7 Action ACO_VUL.2.4E
+
+
+ACO_VUL.2-8 The evaluator _**shall conduct**_ a search of the composed TOE ST, guidance
+documentation, reliance information and composition rationale to identify
+possible security vulnerabilities in the composed TOE.
+
+
+1847 The consideration of the components of the composed TOE in the
+independent evaluator vulnerability analysis will take a slightly different
+form to that documented in AVA_VAN.2.3E for a component evaluation, as
+it will not necessarily consider all layers of design abstraction relevant to the
+assurance package. These will have already been considered during the
+evaluation of the components, but the evidence may not be available for the
+
+
+April 2017 Version 3.1 Page 383 of 430
+
+
+**Class ACO: Composition**
+
+
+composed TOE evaluation. However, the general approach described in the
+work units associated with AVA_VAN.2.3E is applicable and should form
+the basis of the evaluator's search for potential vulnerabilities in the
+composed TOE.
+
+
+1848 A vulnerability analysis of the individual components used in the composed
+TOE will have already been performed during evaluation of the individual
+components. The focus of the vulnerability analysis during the composed
+TOE evaluation is to identify any vulnerabilities introduced as a result of the
+integration of the components or due to any changes in the use of the
+components between the evaluated component configuration to the
+composed TOE configuration.
+
+
+1849 The evaluator will use the understanding of the component's construction as
+detailed in the reliance information for the dependent component, and the
+development information and composition rationale for the base component,
+together with the dependent component design information. This information
+will allow the evaluator to gain an understanding of how the base component
+and dependent component interact and identify potential vulnerabilities that
+may be introduced as a result of this interaction.
+
+
+1850 The evaluator will consider any new guidance provided for the installation,
+start-up and operation of the composed TOE to identify any potential
+vulnerabilities introduced through this revised guidance.
+
+
+1851 If any of the individual components have been through assurance continuity
+activities since the completion of the component evaluation, the evaluator
+will consider the patch(es) in the independent vulnerability analysis.
+Information related to the change provided in a public report of the assurance
+continuity activities (e.g. Maintenance Report) will be the main source of
+input material of the change. This will be supplemented by any updates to
+the guidance documentation resulting from the change and any information
+regarding the change available in the public domain, e.g. vendor website.
+
+
+1852 Any risks identified due to the lack of evidence to establish the full impact of
+any patches or deviations in the configuration of a component from the
+evaluated configuration are to be documented in the evaluator's vulnerability
+analysis.
+
+
+17.7.2.8 Action ACO_VUL.2.5E
+
+
+ACO_VUL.2-9 The evaluator _**shall conduct**_ penetration testing as detailed for
+AVA_VAN.2.4E.
+
+
+1853 The evaluator will apply all work units necessary for the satisfaction of
+evaluator action AVA_VAN.2.4E, reporting in the ETR for the composed
+TOE all analysis and verdicts as dictated by the work units.
+
+
+1854 The evaluator will also apply the work units for the evaluator action
+AVA_VAN.2.1E to determine that the composed TOE provided by the
+developer is suitable for testing.
+
+
+Page 384 of 430 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+
+**17.7.3** **Evaluation of sub-activity (ACO_VUL.3)**
+
+
+17.7.3.1 Objectives
+
+
+1855 The objective of this sub-activity is to determine whether the composed TOE,
+in its operational environment, has vulnerabilities exploitable by attackers
+possessing Enhanced-Basic attack potential.
+
+
+1856 The developer provides an analysis of the disposition of any residual
+vulnerabilities reported for the components and of any vulnerabilities
+introduced through the combination of the base and dependent components.
+The evaluator performs a search of the public domain to identify any new
+potential vulnerabilities in the components (i.e. those issues that have been
+reported in the public domain since the completion of the component
+evaluations). The evaluator will also perform an independent vulnerability
+analysis of the composed TOE and penetration testing.
+
+
+17.7.3.2 Input
+
+
+1857 The evaluation evidence for this sub-activity is:
+
+
+a) the composed TOE suitable for testing;
+
+
+b) the composed ST;
+
+
+c) the composition rationale;
+
+
+d) the reliance information;
+
+
+e) the guidance documentation;
+
+
+f) information publicly available to support the identification of
+possible security vulnerabilities.
+
+
+g) residual vulnerabilities reported during evaluation of each component.
+
+
+17.7.3.3 Application notes
+
+
+1858 See the application notes for Evaluation of sub-activity (AVA_VAN.3).
+
+
+17.7.3.4 Action ACO_VUL.3.1E
+
+
+ACO_VUL.3.1C _**The composed TOE shall be suitable for testing.**_
+
+
+ACO_VUL.3-1 The evaluator _**shall examine**_ the composed TOE to determine that it has
+been installed properly and is in a known state.
+
+
+1859 To determine that the composed TOE has been installed properly and is in a
+known state the ATE_IND.2-1 and ATE_IND.2-2 work units will be applied
+to the composed TOE.
+
+
+April 2017 Version 3.1 Page 385 of 430
+
+
+**Class ACO: Composition**
+
+
+1860 If the assurance package includes ACO_CTT family, then the evaluator may
+refer to the result of the work unit Composed TOE testing (ACO_CTT)*-1 to
+demonstrate this has been satisfied.
+
+
+ACO_VUL.3-2 The evaluator _**shall examine**_ the composed TOE configuration to determine
+that any assumptions and objectives in the STs the components relating to IT
+entities for are fulfilled by the other components.
+
+
+1861 The STs for the component may include assumptions about other
+components that may use the component to which the ST relates, e.g. the ST
+for an operating system used as a base component may include an
+assumption that any applications loaded on the operating system do not run
+in privileged mode. These assumptions and objectives are to be fulfilled by
+other components in the composed TOE.
+
+
+17.7.3.5 Action ACO_VUL.3.2E
+
+
+ACO_VUL.3-3 The evaluator _**shall examine**_ the residual vulnerabilities from the base
+component evaluation to determine that they are not exploitable in the
+composed TOE in its operational environment.
+
+
+1862 The list of vulnerabilities identified in the product during the evaluation of
+the base component, which were demonstrated to be non-exploitable in the
+base component, is to be used as an input into this activity. The evaluator
+will determine that the premise(s) on which a vulnerability was deemed to be
+non-exploitable is upheld in the composed TOE, or whether the combination
+has re-introduced the potential vulnerability. For example, if during
+evaluation of the base component it was assumed that a particular operating
+system service was disabled, which is enabled in the composed TOE
+evaluation, any potential vulnerabilities relating to that service previously
+scoped out should now be considered.
+
+
+1863 Also, this list of known, non-exploitable vulnerabilities resulting from the
+evaluation of the base component should be considered in the light of any
+known, non-exploitable vulnerabilities for the other components (e.g.
+dependent component) within the composed TOE. This is to consider the
+case where a potential vulnerability that is non-exploitable in isolation is
+exploitable when integrated with an IT entity containing another potential
+vulnerability.
+
+
+ACO_VUL.3-4 The evaluator _**shall examine**_ the residual vulnerabilities from the dependent
+component evaluation to determine that they are not exploitable in the
+composed TOE in its operational environment.
+
+
+1864 The list of vulnerabilities identified in the product during the evaluation of
+the dependent component, which were demonstrated to be non-exploitable in
+the dependent component, is to be used as an input into this activity. The
+evaluator will determine that the premise(s) on which a vulnerability was
+deemed to be non-exploitable is upheld in the composed TOE, or whether the
+combination has re-introduced the potential vulnerability. For example, if
+during evaluation of the dependent component it was assumed that IT
+
+
+Page 386 of 430 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+
+meeting the operational environment requirements would not return a certain
+value in response to a service request, which is provided by the base
+component in the composed TOE evaluation, any potential vulnerabilities
+relating to that return value previously scoped out should now be considered.
+
+
+1865 Also, this list of known, non-exploitable vulnerabilities resulting from the
+evaluation of the dependent component should be considered in the light of
+any known, non-exploitable vulnerabilities for the other components (e.g.
+base component) within the composed TOE. This is to consider the case
+where a potential vulnerability that is non-exploitable in isolation is
+exploitable when integrated with an IT entity containing another potential
+vulnerability.
+
+
+17.7.3.6 Action ACO_VUL.3.3E
+
+
+ACO_VUL.3-5 The evaluator _**shall examine**_ the sources of information publicly available to
+support the identification of possible security vulnerabilities in the base
+component that have become known since the completion of the base
+component evaluation.
+
+
+1866 The evaluator will use the information in the public domain as described in
+AVA_VAN.3-2 to search for vulnerabilities in the base component.
+
+
+1867 Those potential vulnerabilities that were publicly available prior to the
+evaluation of the base component do not have to be further investigated
+unless it is apparent to the evaluator that the attack potential required by an
+attacker to exploit the potential vulnerability has been significantly reduced.
+This may be through the introduction of some new technology since the base
+component evaluation that means the exploitation of the potential
+vulnerability has been simplified.
+
+
+ACO_VUL.3-6 The evaluator _**shall examine**_ the sources of information publicly available to
+support the identification of possible security vulnerabilities in the dependent
+component that have become known since completion of the dependent
+component evaluation.
+
+
+1868 The evaluator will use the information in the public domain as described in
+AVA_VAN.3-2 to search for vulnerabilities in the dependent component.
+
+
+1869 Those potential vulnerabilities that were publicly available prior to the
+evaluation of the dependent component do not have to be further investigated
+unless it is apparent to the evaluator that the attack potential required by an
+attacker to exploit the potential vulnerability has been significantly reduced.
+This may be through the introduction of some new technology since
+evaluation of the dependent component that means the exploitation of the
+potential vulnerability has been simplified.
+
+
+ACO_VUL.3-7 The evaluator _**shall record**_ in the ETR the identified potential security
+vulnerabilities that are candidates for testing and applicable to the composed
+TOE in its operational environment.
+
+
+April 2017 Version 3.1 Page 387 of 430
+
+
+**Class ACO: Composition**
+
+
+1870 The ST, guidance documentation and functional specification are used to
+determine whether the vulnerabilities are relevant to the composed TOE in
+its operational environment.
+
+
+1871 The evaluator records any reasons for exclusion of vulnerabilities from
+further consideration if the evaluator determines that the vulnerability is not
+applicable in the operational environment. Otherwise the evaluator records
+the potential vulnerability for further consideration.
+
+
+1872 A list of potential vulnerabilities applicable to the composed TOE in its
+operational environment, which can be used as an input into penetration
+testing activities (ACO_VUL.3.5E), shall be reported in the ETR by the
+evaluators.
+
+
+17.7.3.7 Action ACO_VUL.3.4E
+
+
+ACO_VUL.3-8 The evaluator _**shall conduct**_ a search of the composed TOE ST, guidance
+documentation, reliance information and composition rationale to identify
+possible security vulnerabilities in the composed TOE.
+
+
+1873 The consideration of the components in the independent evaluator
+vulnerability analysis will take a slightly different form to that documented
+in AVA_VAN.3.3E for a component evaluation, as it will not necessarily
+consider all layers of design abstraction relevant to the assurance package.
+These will have already been considered during the evaluation of the base
+component, but the evidence may not be available for the composed TOE
+evaluation. However, the general approach described in the work units
+associated with AVA_VAN.3.3E is applicable and should form the basis of
+the evaluator's search for potential vulnerabilities in the composed TOE.
+
+
+1874 A vulnerability analysis of the individual components used in the composed
+TOE will have already been performed during evaluation of the components.
+The focus of the vulnerability analysis during the composed TOE evaluation
+is to identify any vulnerabilities introduced as a result of the integration of
+the components or due to any changes in the use of the components between
+the configuration of the component determined during the component
+evaluation and the composed TOE configuration.
+
+
+1875 The evaluator will use the understanding of the component's construction as
+detailed in the reliance information for the dependent component, and the
+composition rationale and development information for the base component,
+together with the dependent component design information. This information
+will allow the evaluator to gain an understanding of how the base component
+and dependent component interact.
+
+
+1876 The evaluator will consider any new guidance provided for the installation,
+start-up and operation of the composed TOE to identify any potential
+vulnerabilities introduced through this revised guidance.
+
+
+1877 If any of the individual components have been through assurance continuity
+activities since the completion of the component evaluation, the evaluator
+
+
+Page 388 of 430 Version 3.1 April 2017
+
+
+**Class ACO: Composition**
+
+
+will consider the patch in the independent vulnerability analysis. Information
+related to the change provided in a public report of the assurance continuity
+activities (e.g. Maintenance Report). This will be supplemented by any
+updates to the guidance documentation resulting from the change and any
+information regarding the change available in the public domain, e.g. vendor
+website.
+
+
+1878 Any risks identified due to the lack of evidence to establish the full impact of
+any patches or deviations in the configuration of a component from the
+evaluated configuration are to be documented in the evaluator's vulnerability
+analysis.
+
+
+17.7.3.8 Action ACO_VUL.3.5E
+
+
+ACO_VUL.3-9 The evaluator _**shall conduct**_ penetration testing as detailed for
+AVA_VAN.3.4E.
+
+
+1879 The evaluator will apply all work units necessary for the satisfaction of
+evaluator action AVA_VAN.3.4E, reporting in the ETR for the composed
+TOE all analysis and verdicts as dictated by the work units.
+
+
+1880 The evaluator will also apply the work units for the evaluator action
+AVA_VAN.3.1E to determine that the composed TOE provided by the
+developer is suitable for testing.
+
+
+April 2017 Version 3.1 Page 389 of 430
+
+
+**General evaluation guidance**
+
+# **A General evaluation guidance** **(informative)**
+
+## **A.1 Objectives**
+
+
+1881 The objective of this chapter is to cover general guidance used to provide
+technical evidence of evaluation results. The use of such general guidance
+helps in achieving objectivity, repeatability and reproducibility of the work
+performed by the evaluator.
+
+## **A.2 Sampling**
+
+
+1882 This Section provides general guidance on sampling. Specific and detailed
+information is given in those work units under the specific evaluator action
+elements where sampling has to be performed.
+
+
+1883 Sampling is a defined procedure of an evaluator whereby some subset of a
+required set of evaluation evidence is examined and assumed to be
+representative for the entire set. It allows the evaluator to gain enough
+confidence in the correctness of particular evaluation evidence without
+analysing the whole evidence. The reason for sampling is to conserve
+resources while maintaining an adequate level of assurance. Sampling of the
+evidence can provide two possible outcomes:
+
+
+a) The subset reveals no errors, allowing the evaluator to have some
+confidence that the entire set is correct.
+
+
+b) The subset reveals errors and therefore the validity of the entire set is
+called into question. Even the resolution of all errors that were found
+may be insufficient to provide the evaluator the necessary confidence
+and as a result the evaluator may have to increase the size of the
+subset, or stop using sampling for this particular evidence.
+
+
+1884 Sampling is a technique which can be used to reach a reliable conclusion if a
+set of evidence is relatively homogeneous in nature, e.g. if the evidence has
+been produced during a well defined process.
+
+
+1885 Sampling in the cases identified in the CC, and in cases specifically covered
+in CEM work items, is recognised as a cost-effective approach to performing
+evaluator actions. Sampling in other areas is permitted only in exceptional
+cases, where performance of a particular activity in its entirety would require
+effort disproportionate to the other evaluation activities, and where this
+would not add correspondingly to assurance. In such cases a rationale for the
+use of sampling in that area will need to be made. Neither the fact that the
+TOE is large and complex, nor that it has many security functional
+requirements, is sufficient justification, since evaluations of large, complex
+TOEs can be expected to require more effort. Rather it is intended that this
+exception be limited to cases such as that where the TOE development
+
+
+Page 390 of 430 Version 3.1 April 2017
+
+
+**General evaluation guidance**
+
+
+approach yields large quantities of material for a particular CC requirement
+that would normally all need to be checked or examined, and where such an
+action would not be expected to raise assurance correspondingly.
+
+
+1886 Sampling needs to be justified taking into account the possible impact on the
+security objectives and threats of the TOE. The impact depends on what
+might be missed as a result of sampling. Consideration also needs to be given
+to the nature of the evidence to be sampled, and the requirement not to
+diminish or ignore any security functions.
+
+
+1887 It should be recognised that sampling of evidence directly related to the
+implementation of the TOE (e.g. developer test results) requires a different
+approach to sampling, then sampling related to the determination of whether
+a process is being followed. In many cases the evaluator is required to
+determine that a process is being followed, and a sampling strategy is
+recommended. The approach for sampling a developer's test results will
+differ. This is because the former case is concerned with ensuring that a
+process is in place, and the latter deals with determining correct
+implementation of the TOE. Typically, larger sample sizes should be
+analysed in cases related to the correct implementation of the TOE than
+would be necessary to ensure that a process is in place.
+
+
+1888 In certain cases it may be appropriate for the evaluator to give greater
+emphasis to the repetition of developer testing. For example if the
+independent tests left for the evaluator to perform would be only
+superficially different from those included in an extensive developer test set
+(possibly because the developer has performed more testing than necessary
+to satisfy the Coverage (ATE_COV) and Depth (ATE_DPT) criteria) then it
+would be appropriate for the evaluator to give greater focus to the repetition
+of developer tests. Note that this does not necessarily imply a requirement for
+a high percentage sample for repetition of developer tests; indeed, given an
+extensive developer test set, the evaluator may be able to justify a low
+percentage sample.
+
+
+1889 Where the developer has used an automated test suite to perform functional
+testing, it will usually be easier for the evaluator to re-run the entire test suite
+rather than repeat only a sample of developer tests. However the evaluator
+does have an obligation to check that the automatic testing does not give
+misrepresentative results. The implication is thus that this check must be
+performed for a sample of the automatic test suite, with the principles for
+selecting some tests in preference to others and ensuring a sufficient sample
+size applying equally in this case.
+
+
+1890 The following principles should be followed whenever sampling is
+performed:
+
+
+a) Sampling should not be random, rather it should be chosen such that
+it is representative of all of the evidence. The sample size and
+composition must always be justified.
+
+
+April 2017 Version 3.1 Page 391 of 430
+
+
+**General evaluation guidance**
+
+
+b) When sampling relates to the correct implementation of the TOE, the
+sample should be representative of all aspects relevant to the areas
+that are sampled. In particular, the selection should cover a variety of
+components, interfaces, developer and operational sites (if more than
+one is involved) and hardware platform types (if more than one is
+involved). The sample size should be commensurate with the cost
+effectiveness of the evaluation and will depend on a number of TOE
+dependent factors (e.g. the size and complexity of the TOE, the
+amount of documentation).
+
+
+c) Also, when sampling relates to specifically gaining evidence that the
+developer testing is repeatable and reproducible the sample used must
+be sufficient to represent all distinct aspects of developer testing, such
+as different test regimes. The sample used must be sufficient to detect
+any systematic problem in the developer's functional testing process.
+The evaluator contribution resulting from the combination of
+repeating developer tests and performing independent tests must be
+sufficient to address the major points of concern for the TOE.
+
+
+d) Where sampling relates to gaining evidence that a process (e.g.
+visitor control or design review) the evaluator should sample
+sufficient information to gain reasonable confidence that the
+procedure is being followed.
+
+
+e) The sponsor and developer should not be informed in advance of the
+exact composition of the sample, subject to ensuring timely delivery
+of the sample and supporting deliverable, e.g. test harnesses and
+equipment to the evaluator in accordance with the evaluation
+schedule.
+
+
+f) The choice of the sample should be free from bias to the degree
+possible (one should not always choose the first or last item). Ideally
+the sample selection should be done by someone other than the
+evaluator.
+
+
+1891 Errors found in the sample can be categorised as being either systematic or
+sporadic. If the error is systematic, the problem should be corrected and a
+complete new sample taken. If properly explained, sporadic errors might be
+solved without the need for a new sample, although the explanation should
+be confirmed. The evaluator should use judgement in determining whether to
+increase the sample size or use a different sample.
+
+## **A.3 Dependencies**
+
+
+1892 In general it is possible to perform the required evaluation activities, subactivities, and actions in any order or in parallel. However, there are different
+kinds of dependencies which have to be considered by the evaluator. This
+Section provides general guidance on dependencies between different
+activities, sub-activities, and actions.
+
+
+Page 392 of 430 Version 3.1 April 2017
+
+
+**General evaluation guidance**
+
+
+**A.3.1** **Dependencies between activities**
+
+
+1893 For some cases the different assurance classes may recommend or even
+require a sequence for the related activities. A specific instance is the ST
+activity. The ST evaluation activity is started prior to any TOE evaluation
+activities since the ST provides the basis and context to perform them.
+However, a final verdict on the ST evaluation may not be possible until the
+TOE evaluation is complete, since changes to the ST may result from activity
+findings during the TOE evaluation.
+
+
+**A.3.2** **Dependencies between sub-activities**
+
+
+1894 Dependencies identified between components in CC Part 3 have to be
+considered by the evaluator. Most dependencies are one way, e.g. Evaluation
+of sub-activity (AVA_VAN.1) claims a dependency on Evaluation of subactivity (ADV_FSP.1) and Evaluation of sub-activity (AGD_OPE.1). There
+are also instances of mutual dependencies, where both components depend
+on each other. An example of this is Evaluation of sub-activity
+(ATE_FUN.1) and Evaluation of sub-activity (ATE_COV.1).
+
+
+1895 A sub-activity can be assigned a pass verdict normally only if all those subactivities are successfully completed on which it has a one-way dependency.
+For example, a pass verdict on Evaluation of sub-activity (AVA_VAN.1) can
+normally only be assigned if the sub-activities related to Evaluation of subactivity (ADV_FSP.1) and Evaluation of sub-activity (AGD_OPE.1) are
+assigned a pass verdict too. In the case of mutual dependency the ordering of
+these components is down to the evaluator deciding which sub-activity to
+perform first. Note this indicates that pass verdicts can normally only be
+assigned once both sub-activities have been successful.
+
+
+1896 So when determining whether a sub-activity will impact another sub-activity,
+the evaluator should consider whether this activity depends on potential
+evaluation results from any dependent sub-activities. Indeed, it may be the
+case that a dependent sub-activity will impact this sub-activity, requiring
+previously completed evaluator actions to be performed again.
+
+
+1897 A significant dependency effect occurs in the case of evaluator-detected
+flaws. If a flaw is identified as a result of conducting one sub-activity, the
+assignment of a pass verdict to a dependent sub-activity may not be possible
+until all flaws related to the sub-activity upon which it depends are resolved.
+
+
+**A.3.3** **Dependencies between actions**
+
+
+1898 It may be the case, that results which are generated by the evaluator during
+one action are used for performing another action. For example, actions for
+completeness and consistency cannot be completed until the checks for
+content and presentation have been completed. This means for example that
+the evaluator is recommended to evaluate the PP/ST rationale after
+evaluating the constituent parts of the PP/ST.
+
+
+April 2017 Version 3.1 Page 393 of 430
+
+
+**General evaluation guidance**
+
+## **A.4 Site Visits**
+
+
+**A.4.1** **Introduction**
+
+
+1899 The assurance class ALC includes requirements for
+
+
+a) the application of configuration management, ensuring that the
+integrity of the TOE is preserved;
+
+
+b) measures, procedures, and standards concerned with secure delivery
+of the TOE, ensuring that the security protection offered by the TOE
+is not compromised during the transfer to the user,
+
+
+c) security measures, used to protect the development environment.
+
+
+1900 A development site visit is a useful means whereby the evaluator determines
+whether procedures are being followed in a manner consistent with that
+described in the documentation.
+
+
+1901 Reasons for visiting sites include:
+
+
+a) to observe the use of the CM system as described in the CM plan;
+
+
+b) to observe the practical application of delivery procedures as
+described in the delivery documentation;
+
+
+c) to observe the application of security measures during development
+and maintenance of the TOE as described in the development security
+documentation.
+
+
+1902 Specific and detailed information is given in work units for those activities
+where site visits are performed:
+
+
+a) CM capabilities (ALC_CMC).n with n>=3 (especially work unit
+ALC_CMC.3-10 = ALC_CMC.4-13 = ALC_CMC.5-19);
+
+
+b) Delivery (ALC_DEL) (especially work unit ALC_DEL.1-2);
+
+
+c) Development security (ALC_DVS) (especially work unit
+ALC_DVS.1-3 = ALC_DVS.2-4).
+
+
+**A.4.2** **General Approach**
+
+
+1903 During an evaluation it is often necessary that the evaluator will meet the
+developer more than once and it is a question of good planning to combine
+the site visit with another meeting to reduce costs. For example one might
+combine the site visits for configuration management, for the developer's
+security and for delivery. It may also be necessary to perform more than one
+site visit to the same site to allow the checking of all development phases. It
+should be considered that development could occur at multiple facilities
+within a single building, multiple buildings at the same site, or at multiple
+sites.
+
+
+Page 394 of 430 Version 3.1 April 2017
+
+
+**General evaluation guidance**
+
+
+1904 The first site visit should be scheduled early during the evaluation. In the
+case of an evaluation which starts during the development phase of the TOE,
+this will allow corrective actions to be taken, if necessary. In the case of an
+evaluation which starts after the development of the TOE, an early site visit
+could allow corrective measures to be put in place if serious deficiencies in
+the applied procedures emerge. This avoids unnecessary evaluation effort.
+
+
+1905 Interviews are also a useful means of determining whether the written
+procedures reflect what is done. In conducting such interviews, the evaluator
+aims to gain a deeper understanding of the analysed procedures at the
+development site, how they are used in practise and whether they are being
+applied as described in the provided evaluation evidence. Such interviews
+complement but do not replace the examination of evaluation evidence.
+
+
+1906 As a first step preparing the site visits the evaluators should perform the
+evaluator work units concerning the assurance class ALC excluding the
+aspects describing the results of the site visit. Based on the information
+provided by the relevant developer documentation and the remaining open
+questions which were not answered by the documentation the evaluators
+compile a check list of the questions which are to be resolved by the site
+visits.
+
+
+1907 The first version of the evaluation report concerning the ALC class and the
+check list serves as input for the consultation with the evaluation authority
+concerning the site visits.
+
+
+1908 The check list serve as a guide line for the site visits, which questions are to
+be answered by inspection of the relevant measures, their application and
+results, and by interviews. Where appropriate, sampling is used for gaining
+the required level of confidence (see Section A.2).
+
+
+1909 The results of the site visits are recorded and serve as input for the final
+version of the evaluation report concerning the assurance class ALC.
+
+
+1910 Other approaches to gain confidence should be considered that provide an
+equivalent level of assurance (e.g. to analyse evaluation evidence). Any
+decision not to make a visit should be determined in consultation with the
+evaluation authority. Appropriate security criteria and a methodology should
+be based on other standards of the Information Security Management
+Systems area.
+
+
+**A.4.3** **Orientation Guide for the Preparation of the Check List**
+
+
+1911 In the following some keywords are provided, which topics should be
+checked during an audit.
+
+
+**A.4.3.1** Aspects of configuration management
+
+
+1912 Basic
+
+
+April 2017 Version 3.1 Page 395 of 430
+
+
+**General evaluation guidance**
+
+
+๏ญ Items of the configuration list, including TOE, source code, run time
+libraries, design documentation, development tools (ALC_CMC.3-8).
+
+
+๏ญ Tracking of design documentation, source code, user guidance to
+different versions of the TOE.
+
+
+๏ญ Integration of the configuration system in the design and
+development process, test planning, test analysis and quality
+management procedures.
+
+
+1913 Test analysis
+
+
+๏ญ Tracking of test plans and results to specific configurations and
+versions of the TOE.
+
+
+1914 Access control to development systems
+
+
+๏ญ Policies for access control and logging.
+
+
+๏ญ Policies for project specific assignment and changing of access rights.
+
+
+1915 Clearance
+
+
+๏ญ Policies for clearance of the TOE and user guidance to the customer.
+
+
+๏ญ Policies for testing and approving of components and the TOE before
+deployment.
+
+
+**A.4.3.2** Aspects of development security
+
+
+1916 Infrastructure
+
+
+๏ญ Security measures for physical access control to the development site
+and rationale for the effectiveness of these measures.
+
+
+1917 Organisational measures
+
+
+๏ญ Organisational structure of the company in respect of the security of
+the development environment.
+
+
+๏ญ Organisational separation between development, production, testing
+and quality assurance.
+
+
+1918 Personal measures
+
+
+๏ญ Measures for education of the personnel in respect of development
+security.
+
+
+๏ญ Measures and legal agreements of non disclosure of internal
+information.
+
+
+1919 Access control
+
+
+Page 396 of 430 Version 3.1 April 2017
+
+
+**General evaluation guidance**
+
+
+๏ญ Assignment of secured objects (for instance TOE, source code, run
+time libraries, design documentation, development tools, user
+guidance) and security policies.
+
+
+๏ญ Policies and responsibilities concerning the access control and the
+handling of authentication information.
+
+
+๏ญ Policies for logging of any kind access to the development site and
+protection of the logging data.
+
+
+1920 Input, processing and output of data
+
+
+๏ญ Security measures for protection of output and output devices (printer,
+plotter and displays).
+
+
+๏ญ Securing of local networks and communication connections.
+
+
+1921 Storage, transfer and destruction of documents and data media.
+
+
+๏ญ Policies for handling of documents and data media.
+
+
+๏ญ Policies and responsibilities for destruction of sorted out documents
+and logging of these events.
+
+
+1922 Data protection
+
+
+๏ญ Policies and responsibilities for data and information protection (e.g.
+for performing backups).
+
+
+1923 Contingency plan
+
+
+๏ญ Practises in case of emergency and responsibilities.
+
+
+๏ญ Documentation of the contingency measures concerning access
+control.
+
+
+๏ญ Information of the personnel about applicable practises in extreme
+cases. protection (e.g. for performing backups).
+
+
+**A.4.4** **Example of a checklist**
+
+
+1924 The examples of checklists for site visits consist in tables for the preparation
+of an audit and for the presentation of the results of an audit.
+
+
+1925 The checklist structure given in the following is preliminary. Dependent on
+the concrete contents of the new guideline, changes might become necessary.
+
+
+1926 The checklist is divided into three sections according to the subjects
+indicated in the introduction (Section A.4.1).
+
+
+a) Configuration management system.
+
+
+April 2017 Version 3.1 Page 397 of 430
+
+
+**General evaluation guidance**
+
+
+b) Delivery procedures.
+
+
+c) Security measures during development.
+
+
+1927 These sections correspond to the actual CC class ALC, especially the
+families CM capabilities (ALC_CMC).n with n>=3, Delivery (ALC_DEL)
+and Development security (ALC_DVS).
+
+
+1928 The sections are subdivided further into rows corresponding to the relevant
+work units of the CEM.
+
+
+1929 The columns of the checklist contain in turn
+
+
+๏ญ a consecutive number,
+
+
+๏ญ the referenced work unit,
+
+
+๏ญ the references to the corresponding developer documentation,
+
+
+๏ญ the explicit reproduction of the developer measures,
+
+
+๏ญ special remarks and questions to be clarified on the visit (beyond the
+standard evaluator task to verify the application of the indicated
+measures),
+
+
+๏ญ the result of the examinations during the visit.
+
+
+1930 If it is decided to have separate checklists for preparation and reporting of the
+audit, the result column is omitted in the preparation list and the remarks and
+questions column is omitted in the reporting list. The remaining columns
+should be identical in both lists.
+
+
+
+
+
+
+
+
+
+
+
+
+|Table 1 Example of a checklist at EAL 4 (extract)|Col2|Col3|Col4|Col5|Col6|
+|---|---|---|---|---|---|
+|A. Examination of the CM system (ALC_CMC.4 andALC_CMS.4)|A. Examination of the CM system (ALC_CMC.4 andALC_CMS.4)|A. Examination of the CM system (ALC_CMC.4 andALC_CMS.4)|A. Examination of the CM system (ALC_CMC.4 andALC_CMS.4)|A. Examination of the CM system (ALC_CMC.4 andALC_CMS.4)|A. Examination of the CM system (ALC_CMC.4 andALC_CMS.4)|
+|No.|Work Unit|Developer
Documentation|Measures|Questions and
Remarks|Result|
+|A.1|ALC_CMC.4-11,
ALC_CMC.4-12|โConfiguration
Management
Systemโ, ch. ...|The system
automatically
managing the
source code
files is
capable of
administering
user profiles
and graded
access rights,
and of
checking
identification
and|Does reading
or updating of
a source code
file require a
user
authentication?|If a user
has not the
right to
access a
confidential
document,
it is not
even
displayed
to him in
the file list.|
+
+
+
+Page 398 of 430 Version 3.1 April 2017
+
+
+**General evaluation guidance**
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+|A. Examination of the CM system (ALC_CMC.4 and ALC_CMS.4)|Col2|Col3|Col4|Col5|Col6|
+|---|---|---|---|---|---|
+|No.|Work Unit|Developer
Documentation|Measures|Questions and
Remarks|Result|
+||||authentication
of users.|||
+|...|...|...|...|...|...|
+|B. Examination of the Delivery Procedures (ALC_DEL.1)|B. Examination of the Delivery Procedures (ALC_DEL.1)|B. Examination of the Delivery Procedures (ALC_DEL.1)|B. Examination of the Delivery Procedures (ALC_DEL.1)|B. Examination of the Delivery Procedures (ALC_DEL.1)|B. Examination of the Delivery Procedures (ALC_DEL.1)|
+|No.|Work Unit|Developer
Documentation|Measures|Questions and
Remarks|Result|
+|B.1|ALC_DEL.1-1,
ALC_DEL.1-2|โDelivery of
the TOEโ,
ch. ...|The software
is transmitted
PGP-signed
and
encrypted to
the customer.|---|The
evaluators
have
checked the
process and
found it as
described,
additionally
a checksum
is
transmitted.|
+|...|...|...|...|...|...|
+|C. Examination of the organisational and infrastructural developer security (ALC_DVS.1,
ALC_LCD.1, ALC_TAT.1)|C. Examination of the organisational and infrastructural developer security (ALC_DVS.1,
ALC_LCD.1, ALC_TAT.1)|C. Examination of the organisational and infrastructural developer security (ALC_DVS.1,
ALC_LCD.1, ALC_TAT.1)|C. Examination of the organisational and infrastructural developer security (ALC_DVS.1,
ALC_LCD.1, ALC_TAT.1)|C. Examination of the organisational and infrastructural developer security (ALC_DVS.1,
ALC_LCD.1, ALC_TAT.1)|C. Examination of the organisational and infrastructural developer security (ALC_DVS.1,
ALC_LCD.1, ALC_TAT.1)|
+|No.|Work Unit|Developer
Documentation|Measures|Questions and
Remarks|Result|
+|C.1|ALC_DVS.1-1,
ALC_DVS.1-2|โSecurity of
the
development
environmentโ,
ch. ...
(Premises)|The premises
are protected
by security
fencing.|Is the fencing
sufficiently
strong and
high to
prevent an
easy intrusion
into the
premises?|The
evaluators
considered
the fencing
to be
sufficiently
strong and
high.|
+|C.2|ALC_DVS.1-1,
ALC_DVS.1-2|โSecurity of
the
development
environmentโ,
ch. ...
(Building)|The building
has the
following
access
possibilities:
The main
entrance
which is
surveyed by
the reception
and is closed
if the
reception is
not manned.
And an
access in the
goods|Is the listing
of the access
possibilities
complete?|Beyond the
indicated
access
possibilities,
there is an
emergency
exit that
cannot be
opened
from the
outside. The
roller
shutters
mentioned
before can
be operated
only from|
+
+
+
+April 2017 Version 3.1 Page 399 of 430
+
+
+**General evaluation guidance**
+
+
+
+
+
+
+
+|C. Examination of the organisational and infrastructural developer security (ALC_DVS.1,
ALC_LCD.1, ALC_TAT.1)|Col2|Col3|Col4|Col5|Col6|
+|---|---|---|---|---|---|
+|No.|Work Unit|Developer
Documentation|Measures|Questions and
Remarks|Result|
+||||reception
which is
secured by
two roller
shutters.||inside.|
+|...|...|...|...|...|...|
+
+## **A.5 Scheme Responsibilities**
+
+1931 This CEM describes the minimum technical work that evaluations conducted
+under oversight (scheme) bodies must perform. However, it also recognises
+(both explicitly and implicitly) that there are activities or methods upon
+which mutual recognition of evaluation results do not rely. For the purposes
+of thoroughness and clarity, and to better delineate where the CEM ends and
+an individual scheme's methodology begins, the following matters are left up
+to the discretion of the schemes. Schemes may choose to provide the
+following, although they may choose to leave some unspecified. (Every
+effort has been made to ensure this list is complete; evaluators encountering
+a subject neither listed here nor addressed in the CEM should consult with
+their evaluation schemes to determine under whose auspices the subject
+falls.)
+
+
+1932 The matters that schemes may choose to specify include:
+
+
+a) what is required in ensuring that an evaluation was done sufficiently every scheme has a means of verifying the technical competence,
+understanding of work and the work of its evaluators, whether by
+requiring the evaluators to present their findings to the oversight body,
+by requiring the oversight body to redo the evaluator's work, or by
+some other means that assures the scheme that all evaluation bodies
+are adequate and comparable;
+
+
+b) process for disposing of evaluation evidence upon completion of an
+evaluation;
+
+
+c) any requirements for confidentiality (on the part of the evaluator and
+the non-disclosure of information obtained during evaluation);
+
+
+d) the course of action to be taken if a problem is encountered during the
+evaluation (whether the evaluation continues once the problem is
+remedied, or the evaluation ends immediately and the remedied
+product must be re-submitted for evaluation);
+
+
+e) any specific (natural) language in which documentation must be
+provided;
+
+
+Page 400 of 430 Version 3.1 April 2017
+
+
+**General evaluation guidance**
+
+
+f) any recorded evidence that must be submitted in the ETR - this CEM
+specifies the minimum to be reported in an ETR; however, individual
+schemes may require additional information to be included;
+
+
+g) any additional reports (other than the ETR) required from the
+evaluators -for example, testing reports;
+
+
+h) any specific ORs that may be required by the scheme, including the
+structure, recipients, etc. of any such ORs;
+
+
+i) any specific content structure of any written report as a result from an
+ST evaluation - a scheme may have a specific format for all of its
+reports detailing results of an evaluation, be it the evaluation of a
+TOE or of an ST;
+
+
+j) any additional PP/ST identification information required;
+
+
+k) any activities to determine the suitability of explicitly-stated
+requirements in an ST;
+
+
+l) any requirements for provision of evaluator evidence to support reevaluation and re-use of evidence;
+
+
+m) any specific handling of scheme identifiers, logos, trademarks, etc.;
+
+
+n) any specific guidance in dealing with cryptography;
+
+
+o) handling and application of scheme, national and international
+interpretations;
+
+
+p) a list or characterisations of suitable alternative approaches to testing
+where testing is infeasible;
+
+
+q) the mechanism by which an evaluation authority can determine what
+steps an evaluator took while testing;
+
+
+r) preferred test approach (if any): at internal interface or at external
+interface;
+
+
+s) a list or characterisation of acceptable means of conducting the
+evaluator's vulnerability analysis (e.g. flaw hypothesis methodology);
+
+
+t) information regarding any vulnerabilities and weaknesses to be
+considered.
+
+
+April 2017 Version 3.1 Page 401 of 430
+
+
+**Vulnerability Assessment (AVA)**
+
+# **B Vulnerability Assessment (AVA)** **(informative)**
+
+
+1933 This annex provides an explanation of the AVA_VAN criteria and examples
+of their application. This annex does not define the AVA criteria; this
+definition can be found in CC Part 3 Section Class AVA: Vulnerability
+assessment.
+
+
+1934 This annex consists of 2 major parts:
+
+
+a) _Guidance for completing an independent vulnerability analysis_ . This
+is summarised in section B.1, and described in more detail in section
+B.2 . These sections describe how an evaluator should approach the
+construction of an independent Vulnerability Analysis.
+
+
+b) How to characterise and use assumed Attack Potential of an attacker.
+This is described in sections B.3 to B.5. These sections provide an
+example of describe how an attack potential can be characterised and
+should be used, and provide examples.
+
+## **B.1 What is Vulnerability Analysis**
+
+
+1935 The purpose of the vulnerability assessment activity is to determine the
+existence and exploitability of flaws or weaknesses in the TOE in the
+operational environment. This determination is based upon analysis
+performed by the evaluator, and is supported by evaluator testing.
+
+
+1936 At the lowest levels of Vulnerability analysis (AVA_VAN) the evaluator
+simply performs a search of publicly available information to identify any
+known weaknesses in the TOE, while at the higher levels the evaluator
+performs a structured analysis of the TOE evaluation evidence.
+
+
+1937 There are three main factors in performing a vulnerability analysis, namely:
+
+
+a) the identification of potential vulnerabilities;
+
+
+b) assessment to determine whether the identified potential
+vulnerabilities could allow an attacker with the relevant attack
+potential to violate the SFRs.
+
+
+c) penetration testing to determine whether the identified potential
+vulnerabilities are exploitable in the operational environment of the
+TOE.
+
+
+1938 The identification of vulnerabilities can be further decomposed into the
+evidence to be searched and how hard to search that evidence to identify
+potential vulnerabilities. In a similar manner, the penetration testing can be
+further decomposed into analysis of the potential vulnerability to identify
+attack methods and the demonstration of the attack methods.
+
+
+Page 402 of 430 Version 3.1 April 2017
+
+
+**Vulnerability Assessment (AVA)**
+
+
+1939 These main factors are iterative in nature, i.e. penetration testing of potential
+vulnerabilities may lead to the identification of further potential
+vulnerabilities. Hence, these are performed as a single vulnerability analysis
+activity.
+
+## **B.2 Evaluator construction of a Vulnerability Analysis**
+
+
+1940 The evaluator vulnerability analysis is to determine that the TOE is resistant
+to penetration attacks performed by an attacker possessing a Basic (for
+AVA_VAN.1 and AVA_VAN.2), Enhanced-Basic (for AVA_VAN.3),
+Moderate (for AVA_VAN.4) or High (for AVA_VAN.5) attack potential.
+The evaluator first assesses the exploitability of all identified potential
+vulnerabilities. This is accomplished by conducting penetration testing. The
+evaluator should assume the role of an attacker with a Basic (for
+AVA_VAN.1 and AVA_VAN.2), Enhanced-Basic (for AVA_VAN.3),
+Moderate (for AVA_VAN.4) or High (for AVA_VAN.5) attack potential
+when attempting to penetrate the TOE.
+
+
+1941 The evaluator considers potential vulnerabilities encountered by the
+evaluator during the conduct of other evaluation activities. The evaluator
+penetration testing determining TOE resistance to these potential
+vulnerabilities should be performed assuming the role of an attacker with a
+Basic (for AVA_VAN.1 and AVA_VAN.2), Enhanced-Basic (for
+AVA_VAN.3), Moderate (for AVA_VAN.4) or High (for AVA_VAN.5)
+attack potential.
+
+
+1942 However, vulnerability analysis should not be performed as an isolated
+activity. It is closely linked with ADV and AGD. The evaluator performs
+these other evaluation activities with a focus on identifying potential
+vulnerabilities or โareas of concernโ. Therefore, evaluator familiarity with
+the generic vulnerability guidance (provided in Section B.2.1) is required.
+
+
+**B.2.1** **Generic vulnerability guidance**
+
+
+1943 The following five categories provide discussion of generic vulnerabilities.
+
+
+**B.2.1.1** Bypassing
+
+
+1944 Bypassing includes any means by which an attacker could avoid security
+enforcement, by:
+
+
+a) exploiting the capabilities of interfaces to the TOE, or of utilities
+which can interact with the TOE;
+
+
+b) inheriting privileges or other capabilities that should otherwise be
+denied;
+
+
+c) (where confidentiality is a concern) reading sensitive data stored or
+copied to inadequately protected areas.
+
+
+April 2017 Version 3.1 Page 403 of 430
+
+
+**Vulnerability Assessment (AVA)**
+
+
+1945 Each of the following should be considered (where relevant) in the
+evaluator's independent vulnerability analysis.
+
+
+a) Attacks based on exploiting the capabilities of interfaces or utilities
+generally take advantage of the absence of the required security
+enforcement on those interfaces. For example, gaining access to
+functionality that is implemented at a lower level than that at which
+access control is enforced. Relevant items include:
+
+
+1) changing the predefined sequence of invocation of TSFI;
+
+
+2) invoking an additional TSFI;
+
+
+3) using a component in an unexpected context or for an
+unexpected purpose;
+
+
+4) using implementation detail introduced in less abstract
+representations;
+
+
+5) using the delay between time of access check and time of use.
+
+
+b) Changing the predefined sequence of invocation of components
+should be considered where there is an expected order in which
+interfaces to the TOE (e.g. user commands) are called to invoke a
+TSFI (e.g. opening a file for access and then reading data from it). If
+a TSFI is invoked through one of the TOE interfaces (e.g. an access
+control check), the evaluator should consider whether it is possible to
+bypass the control by performing the call at a later point in the
+sequence or by missing it out altogether.
+
+
+c) Executing an additional component (in the predefined sequence) is a
+similar form of attack to the one described above, but involves the
+calling of some other TOE interface at some point in the sequence. It
+can also involve attacks based on interception of sensitive data passed
+over a network by use of network traffic analysers (the additional
+component here being the network traffic analyser).
+
+
+d) Using a component in an unexpected context or for an unexpected
+purpose includes using an unrelated TOE interface to bypass the TSF
+by using it to achieve a purpose that it was not designed or intended
+to achieve. Covert channels are an example of this type of attack (see
+B.2.1.4 for further discussion of covert channels). The use of
+undocumented interfaces, which may be insecure, also falls into this
+category. Such interfaces may include undocumented support and
+help facilities.
+
+
+e) Using implementation detail introduced in lower representations may
+allow an attacker to take advantage of additional functions, resources
+or attributes that are introduced to the TOE as a consequence of the
+refinement process. Additional functionality may include test harness
+
+
+Page 404 of 430 Version 3.1 April 2017
+
+
+**Vulnerability Assessment (AVA)**
+
+
+code contained in software modules and back-doors introduced
+during the implementation process.
+
+
+f) Using the delay between time of check and time of use includes
+scenarios where an access control check is made and access granted,
+and an attacker is subsequently able to create conditions in which,
+had they applied at the time the access check was made, would have
+caused the check to fail. An example would be a user creating a
+background process to read and send highly sensitive data to the
+user's terminal, and then logging out and logging back in again at a
+lower sensitivity level. If the background process is not terminated
+when the user logs off, the MAC checks would have been effectively
+bypassed.
+
+
+g) Attacks based on inheriting privileges are generally based on illicitly
+acquiring the privileges or capabilities of some privileged component,
+usually by exiting from it in an uncontrolled or unexpected manner.
+Relevant items include:
+
+
+1) executing data not intended to be executable, or making it
+executable;
+
+
+2) generating unexpected input for a component;
+
+
+3) invalidating assumptions and properties on which lower-level
+components rely.
+
+
+h) Executing data not intended to be executable, or making it executable
+includes attacks involving viruses (e.g. putting executable code or
+commands in a file which are automatically executed when the file is
+edited or accessed, thus inheriting any privileges the owner of the file
+has).
+
+
+i) Generating unexpected input for a component can have unexpected
+effects which an attacker could take advantage of. For example, if the
+TSF could be bypassed if a user gains access to the underlying
+operating system, it may be possible to gain such access following
+the login sequence by exploring the effect of hitting various control
+or escape sequences whilst a password is being authenticated.
+
+
+j) Invalidating assumptions and properties on which lower level
+components rely includes attacks based on breaking out of the
+constraints of an application to gain access to an underlying operating
+system in order to bypass the TSF of an application. In this case the
+assumption being invalidated is that it is not possible for a user of the
+application to gain such access. A similar attack can be envisaged
+against an application on an underlying database management
+system: again the TSF could be bypassed if an attacker can break out
+of the constraints of the application.
+
+
+April 2017 Version 3.1 Page 405 of 430
+
+
+**Vulnerability Assessment (AVA)**
+
+
+k) Attacks based on reading sensitive data stored in inadequately
+protected areas (applicable where confidentiality is a concern)
+include the following issues which should be considered as possible
+means of gaining access to sensitive data:
+
+
+1) disk scavenging;
+
+
+2) access to unprotected memory;
+
+
+3) exploiting access to shared writable files or other shared
+resources (e.g. swap files);
+
+
+4) Activating error recovery to determine what access users can
+obtain. For example, after a crash an automatic file recovery
+system may employ a lost and found directory for headerless
+files, which are on disk without labels. If the TOE implements
+mandatory access controls, it is important to investigate at
+what security level this directory is kept (e.g. at system high),
+and who has access to this directory.
+
+
+1946 There are a number of different methods through which an evaluator may
+identify a back-door, including two main techniques. Firstly, by the evaluator
+inadvertently identifying during testing an interface that can be misused.
+Secondly, through testing each external interface of the TSF in a debugging
+mode to identify any modules that are not called as a part of testing the
+documented interfaces and then inspecting the code that is not called to
+consider whether it is a back-door.
+
+
+1947 For a software TOE where Evaluation of sub-activity (ADV_IMP.2) and
+ALC_TAT.2 or higher components are included in the assurance package,
+the evaluator may consider during their analysis of the tools the libraries and
+packages that are linked by the compiler at compilation stage to determine
+that back-doors are not introduced at this stage.
+
+
+**B.2.1.2** Tampering
+
+
+1948 Tampering includes any attack based on an attacker attempting to influence
+the behaviour of the TSF (i.e. corruption or de-activation), for example by:
+
+
+a) accessing data on whose confidentiality or integrity the TSF relies;
+
+
+b) forcing the TOE to cope with unusual or unexpected circumstances;
+
+
+c) disabling or delaying security enforcement;
+
+
+d) physical modification the TOE.
+
+
+1949 Each of the following should be considered (where relevant) in the
+evaluator's independent vulnerability analysis.
+
+
+a) Attacks based on accessing data, whose confidentiality or integrity
+are protected, include:
+
+
+Page 406 of 430 Version 3.1 April 2017
+
+
+**Vulnerability Assessment (AVA)**
+
+
+1) reading, writing or modifying internal data directly or
+indirectly;
+
+
+2) using a component in an unexpected context or for an
+unexpected purpose;
+
+
+3) using interfaces between components that are not visible at a
+higher level of abstraction.
+
+
+b) Reading, writing or modifying internal data directly or indirectly
+includes the following types of attack which should be considered:
+
+
+1) reading โsecretsโ stored internally, such as user passwords;
+
+
+2) spoofing internal data that security enforcing mechanisms rely
+upon;
+
+
+3) modifying environment variables (e.g. logical names), or data
+in configuration files or temporary files.
+
+
+c) It may be possible to deceive a trusted process into modifying a
+protected file that it wouldn't normally access.
+
+
+d) The evaluator should also consider the following โdangerous
+featuresโ:
+
+
+1) source code resident on the TOE along with a compiler (for
+instance, it may be possible to modify the login source code);
+
+
+2) an interactive debugger and patch facility (for instance, it may
+be possible to modify the executable image);
+
+
+3) the possibility of making changes at device controller level,
+where file protection does not exist;
+
+
+4) diagnostic code which exists in the source code and that may
+be optionally included;
+
+
+5) developer's tools left in the TOE.
+
+
+e) Using a component in an unexpected context or for an unexpected
+purpose includes (for example), where the TOE is an application built
+upon an operating system, users exploiting knowledge of a word
+processor package or other editor to modify their own command file
+(e.g. to acquire greater privileges).
+
+
+f) Using interfaces between components which are not visible at a
+higher level of abstraction includes attacks exploiting shared access
+to resources, where modification of a resource by one component can
+influence the behaviour of another (trusted) component, e.g. at source
+code level, through the use of global data or indirect mechanisms
+such as shared memory or semaphores.
+
+
+April 2017 Version 3.1 Page 407 of 430
+
+
+**Vulnerability Assessment (AVA)**
+
+
+g) Attacks based on forcing the TOE to cope with unusual or
+unexpected circumstances should always be considered. Relevant
+items include:
+
+
+1) generating unexpected input for a component;
+
+
+2) invalidating assumptions and properties on which lower-level
+components rely.
+
+
+h) Generating unexpected input for a component includes investigating
+the behaviour of the TOE when:
+
+
+1) command input buffers overflow (possibly โcrashing the
+stackโ or overwriting other storage, which an attacker may be
+able to take advantage of, or forcing a crash dump that may
+contain sensitive information such as clear-text passwords);
+
+
+2) invalid commands or parameters are entered (including
+supplying a read-only parameter to an interface which expects
+to return data via that parameter and supplying improperly
+formatted input that should fail parsing such as SQL-injection,
+format strings);
+
+
+3) an end-of-file marker (e.g. CTRL-Z or CTRL-D) or null
+character is inserted in an audit trail.
+
+
+i) Invalidating assumptions and properties on which lower-level
+components rely includes attacks taking advantage of errors in the
+source code where the code assumes (explicitly or implicitly) that
+security relevant data is in a particular format or has a particular
+range of values. In these cases the evaluator should determine
+whether they can invalidate such assumptions by causing the data to
+be in a different format or to have different values, and if so whether
+this could confer advantage to an attacker.
+
+
+j) The correct behaviour of the TSF may be dependent on assumptions
+that are invalidated under extreme circumstances where resource
+limits are reached or parameters reach their maximum value. The
+evaluator should consider (where practical) the behaviour of the TOE
+when these limits are reached, for example:
+
+
+1) changing dates (e.g. examining how the TOE behaves when a
+critical date threshold is passed);
+
+
+2) filling disks;
+
+
+3) exceeding the maximum number of users;
+
+
+4) filling the audit log;
+
+
+5) saturating security alarm queues at a console;
+
+
+Page 408 of 430 Version 3.1 April 2017
+
+
+**Vulnerability Assessment (AVA)**
+
+
+6) overloading various parts of a multi-user TOE which relies
+heavily upon communications components;
+
+
+7) swamping a network, or individual hosts, with traffic;
+
+
+8) filling buffers or fields.
+
+
+k) Attacks based on disabling or delaying security enforcement include
+the following items:
+
+
+1) using interrupts or scheduling functions to disrupt sequencing;
+
+
+2) disrupting concurrence;
+
+
+3) using interfaces between components which are not visible at
+a higher level of abstraction.
+
+
+l) Using interrupts or scheduling functions to disrupt sequencing
+includes investigating the behaviour of the TOE when:
+
+
+1) a command is interrupted (with CTRL-C, CTRL-Y, etc.);
+
+
+2) a second interrupt is issued before the first is acknowledged.
+
+
+m) The effects of terminating security critical processes (e.g. an audit
+daemon) should be explored. Similarly, it may be possible to delay
+the logging of audit records or the issuing or receipt of alarms such
+that it is of no use to an administrator (since the attack may already
+have succeeded).
+
+
+n) Disrupting concurrence includes investigating the behaviour of the
+TOE when two or more subjects attempt simultaneous access. It may
+be that the TOE can cope with the interlocking required when two
+subjects attempt simultaneous access, but that the behaviour becomes
+less well defined in the presence of further subjects. For example, a
+critical security process could be put into a resource-wait state if two
+other processes are accessing a resource which it requires.
+
+
+o) Using interfaces between components which are not visible at a
+higher level of abstraction may provide a means of delaying a timecritical trusted process.
+
+
+p) Physical attacks can be categorised into physical probing, physical
+manipulation, physical modification, and substitution.
+
+
+1) Physical probing by penetrating the TOE targeting internals of
+the TOE, e.g. reading at internal communication interfaces,
+lines or memories.
+
+
+2) Physical manipulation can be with the TOE internals aiming
+at internal modifications of the TOE (e.g. by using optical
+fault induction as an interaction process), at the external
+
+
+April 2017 Version 3.1 Page 409 of 430
+
+
+**Vulnerability Assessment (AVA)**
+
+
+interfaces of the TOE (e.g. by power or clock glitches) and at
+the TOE environment (e.g. by modifying temperature).
+
+
+3) Physical modification of TOE internal security enforcing
+attributes to inherit privileges or other capabilities that should
+be denied in regular operation. Such modifications can be
+caused, e.g., by optical fault induction. Attacks based on
+physical modification may also yield a modification of the
+TSF itself, e.g. by causing faults at TOE internal program data
+transfers before execution. Note, that such kind of bypassing
+by modifying the TSF itself can jeopardise every TSF unless
+there are other measures (possibly environmental measures)
+that prevent an attacker from gaining physical access to the
+TOE.
+
+
+4) Physical substitution to replace the TOE with another IT
+entity, during delivery or operation of the TOE. Substitution
+during delivery of the TOE from the development
+environment to the user should be prevented through
+application of secure delivery procedures (such as those
+considered under Development security (ALC_DVS)).
+Substitution of the TOE during operation may be considered
+through a combination of user guidance and the operational
+environment, such that the user is able to be confident that
+they are interacting with the TOE.
+
+
+**B.2.1.3** Direct attacks
+
+
+1950 Direct attack includes the identification of any penetration tests necessary to
+test the strength of permutational or probabilistic mechanism and other
+mechanisms to ensure they withstand direct attack.
+
+
+1951 For example, it may be a flawed assumption that a particular implementation
+of a pseudo-random number generator will possess the required entropy
+necessary to seed the security mechanism.
+
+
+1952 Where a probabilistic or permutational mechanism relies on selection of
+security attribute value (e.g. selection of password length) or entry of data by
+a human user (e.g. choice of password), the assumptions made should reflect
+the worst case.
+
+
+1953 Probabilistic or permutational mechanisms should be identified during
+examination of evaluation evidence required as input to this sub-activity
+(security target, functional specification, TOE design and implementation
+representation subset) and any other TOE (e.g. guidance) documentation may
+identify additional probabilistic or permutational mechanisms.
+
+
+1954 Where the design evidence or guidance includes assertions or assumptions
+(e.g. about how many authentication attempts are possible per minute), the
+evaluator should independently confirm that these are correct. This may be
+achieved through testing or through independent analysis.
+
+
+Page 410 of 430 Version 3.1 April 2017
+
+
+**Vulnerability Assessment (AVA)**
+
+
+1955 Direct attacks reliant upon a weakness in a cryptographic algorithm should
+not be considered under Vulnerability analysis (AVA_VAN), as this is
+outside the scope of the CC. Correctness of the implementation of the
+cryptographic algorithm is considered during the ADV and ATE activities.
+
+
+**B.2.1.4** Monitoring
+
+
+1956 Information is an abstract view on relation between the properties of entities,
+i.e. a signal contains information for a system, if the TOE is able to react to
+this signal. The TOE resources processes and stores information represented
+by user data. Therefore:
+
+
+a) information may flow with the user data between subjects by internal
+TOE transfer or export from the TOE;
+
+
+b) information may be generated and passed to other user data;
+
+
+c) information may be gained through monitoring the operations on data
+representing the information.
+
+
+1957 The information represented by user data may be characterised by security
+attributes like โclassification levelโ having values, for example unclassified,
+confidential, secret, top secret, to control operations to the data. This
+information and therefore the security attributes may be changed by
+operations e.g. FDP_ACC.2 may describe decrease of the level by
+โsanitarisationโ or increase of level by combination of data. This is one
+aspects of an information flow analysis focused on controlled operations of
+controlled subjects on controlled objects.
+
+
+1958 The other aspect is the analysis of _**illicit information flow**_ . This aspect is
+more general than the direct access to objects containing user data addressed
+by the FDP_ACC family. An _**unenforced**_ signalling channel carrying
+information under control of the information flow control policy can also be
+caused by monitoring of the processing of any object containing or related to
+this information (e.g. side channels). An _**enforced**_ signalling channels may
+be identified in terms of the subjects manipulating resources and the subject
+or user that observe such manipulation. Classically, covert channels have
+been identified as timing or storage channels, according to the resource being
+modified or modulated. As for other monitoring attacks, the use of the TOE
+is in accordance with the SFRs.
+
+
+1959 Covert channels are normally applicable in the case when the TOE has
+unobservability AND multi-level separation policy requirements. Covert
+channels may be routinely spotted during vulnerability analysis and design
+activities, and should therefore be tested. However, generally such
+monitoring attacks are only identified through specialised analysis
+techniques commonly referred to as โcovert channel analysisโ. These
+techniques have been the subject of much research and there are many papers
+published on this subject. Guidance for the conduct of covert channel
+analysis should be sought from the evaluation authority.
+
+
+April 2017 Version 3.1 Page 411 of 430
+
+
+**Vulnerability Assessment (AVA)**
+
+
+1960 _Unenforced_ information flow monitoring attacks include passive analysis
+techniques aiming at disclosure of sensitive internal data of the TOE by
+operating the TOE in the way that corresponds to the guidance documents.
+
+
+1961 Side Channel Analysis includes crypt analytical techniques based on physical
+leakage of the TOE. Physical leakage can occur by timing information,
+power consumption or power emanation during computation of a TSF.
+Timing information can be collected also by a remote-attacker (having
+network access to the TOE), power based information channels requires that
+the attacker is in the near-by environment of the TOE.
+
+
+1962 Eavesdropping techniques include interception of all forms of energy, e.g.,
+electromagnetic or optical emanation of computer displays, not necessarily in
+the near-field of the TOE.
+
+
+1963 Monitoring also includes exploits of protocol flaws, e.g., an attack on SSL
+implementation.
+
+
+**B.2.1.5** Misuse
+
+
+1964 Misuse may arise from:
+
+
+a) incomplete guidance documentation;
+
+
+b) unreasonable guidance;
+
+
+c) unintended misconfiguration of the TOE;
+
+
+d) forced exception behaviour of the TOE.
+
+
+1965 If the guidance documentation is incomplete the user may not know how to
+operate the TOE in accordance with the SFRs. The evaluator should apply
+familiarity with the TOE gained from performing other evaluation activities
+to determine that the guidance is complete. In particular, the evaluator should
+consider the functional specification. The TSF described in this document
+should be described in the guidance as required to permit secure
+administration and use through the TSFI available to human users. In
+addition, the different modes of operation should be considered to ensure that
+guidance is provided for all modes of operation.
+
+
+1966 The evaluator may, as an aid, prepare an informal mapping between the
+guidance and these documents. Any omissions in this mapping may indicate
+incompleteness.
+
+
+1967 The guidance is considered to be unreasonable if it makes demands on the
+TOE's usage or operational environment that are inconsistent with the ST or
+unduly onerous to maintain security.
+
+
+1968 A TOE may use a variety of ways to assist the consumer in effectively using
+that TOE in accordance with the SFRs and prevent unintentional
+misconfiguration. A TOE may employ functionality (features) to alert the
+consumer when the TOE is in a state that is inconsistent with the SFRs,
+
+
+Page 412 of 430 Version 3.1 April 2017
+
+
+**Vulnerability Assessment (AVA)**
+
+
+whilst other TOEs may be delivered with enhanced guidance containing
+suggestions, hints, procedures, etc. on using the existing security features
+most effectively; for instance, guidance on using the audit feature as an aid
+for detecting when the SFRs are being compromised; namely insecure.
+
+
+1969 The evaluator considers the TOE's functionality, its purpose and security
+objectives for the operational environment to arrive at a conclusion of
+whether or not there is reasonable expectation that use of the guidance would
+permit transition into an insecure state to be detected in a timely manner.
+
+
+1970 The potential for the TOE to enter into insecure states may be determined
+using the evaluation deliverables, such as the ST, the functional specification
+and any other design representations provided as evidence for components
+included in the assurance package for the TOE (e.g. the TOE/TSF design
+specification if a component from TOE design (ADV_TDS) is included).
+
+
+1971 Instances of forced exception behaviour of the TSF could include, but are not
+limited to, the following:
+
+
+a) behaviour of the TOE when start-up, close-down or error recovery is
+activated;
+
+
+b) behaviour of the TOE under extreme circumstances (sometimes
+termed overload or asymptotic behaviour), particularly where this
+could lead to the de-activation or disabling of parts of the TSF;
+
+
+c) any potential for unintentional misconfiguration or insecure use
+arising from attacks noted in the section on tampering above.
+
+
+**B.2.2** **Identification of Potential Vulnerabilities**
+
+
+1972 Potential vulnerabilities may be identified by the evaluator during different
+activities. They may become apparent during an evaluation activity or they
+may be identified as a result of analysis of evidence to search for
+vulnerabilities.
+
+
+**B.2.2.1** Encountered
+
+
+1973 The encountered identification of vulnerabilities is where potential
+vulnerabilities are identified by the evaluator during the conduct of
+evaluation activities, i.e. the evidence are not being analysed with the express
+aim of identifying potential vulnerabilities.
+
+
+1974 The encountered method of identification is dependent on the evaluator's
+experience and knowledge; which is monitored and controlled by the
+evaluation authority. It is not reproducible in approach, but will be
+documented to ensure repeatability of the conclusions from the reported
+potential vulnerabilities.
+
+
+1975 There are no formal analysis criteria required for this method. Potential
+vulnerabilities are identified from the evidence provided as a result of
+
+
+April 2017 Version 3.1 Page 413 of 430
+
+
+**Vulnerability Assessment (AVA)**
+
+
+knowledge and experience. However, this method of identification is not
+constrained to any particular subset of evidence.
+
+
+1976 Evaluator is assumed to have knowledge of the TOE-type technology and
+known security flaws as documented in the public domain. The level of
+knowledge assumed is that which can be gained from a security e-mail list
+relevant to the TOE type, the regular bulletins (bug, vulnerability and
+security flaw lists) published by those organisations researching security
+issues in products and technologies in widespread use. This knowledge is not
+expected to extend to specific conference proceedings or detailed theses
+produced by university research for AVA_VAN.1 or AVA_VAN.2.
+However, to ensure the knowledge applied is up to date, the evaluator may
+need to perform a search of public domain material.
+
+
+1977 For AVA_VAN.3 to AVA_VAN.5 the search of publicly available
+information is expected to include conference proceeding and theses
+produced during research activities by universities and other relevant
+organisations.
+
+
+1978 Examples of how these may arise (how the evaluator may encounter
+potential vulnerabilities):
+
+
+a) while the evaluator is examining some evidence, it sparks a memory
+of a potential vulnerability identified in a similar product type, that
+the evaluator believes to also be present in the TOE under evaluation;
+
+
+b) while examining some evidence, the evaluator spots a flaw in the
+specification of an interface, that reflects a potential vulnerability.
+
+
+1979 This may include becoming aware of a potential vulnerability in a TOE
+through reading about generic vulnerabilities in a particular product type in
+an IT security publication or on a security e-mail list to which the evaluator
+is subscribed.
+
+
+1980 Attack methods can be developed directly from these potential vulnerabilities.
+Therefore, the encountered potential vulnerabilities are collated at the time of
+producing penetration tests based on the evaluator's vulnerability analysis.
+There is no explicit action for the evaluator to encounter potential
+vulnerabilities. Therefore, the evaluator is directed through an implicit action
+specified in AVA_VAN.1.2E and AVA_VAN.*.4E.
+
+
+1981 Current information regarding public domain vulnerabilities and attacks may
+be provided to the evaluator by, for example, an evaluation authority. This
+information is to be taken into account by the evaluator when collating
+encountered vulnerabilities and attack methods when developing penetration
+tests.
+
+
+**B.2.2.2** Analysis
+
+
+1982 The following types of analysis are presented in terms of the evaluator
+actions.
+
+
+Page 414 of 430 Version 3.1 April 2017
+
+
+**Vulnerability Assessment (AVA)**
+
+
+**B.2.2.2.1** Unstructured Analysis
+
+
+1983 The unstructured analysis to be performed by the evaluator (for Evaluation of
+sub-activity (AVA_VAN.2)) permits the evaluator to consider the generic
+vulnerabilities (as discussed in B.2.1). The evaluator will also apply their
+experience and knowledge of flaws in similar technology types.
+
+
+**B.2.2.2.2** Focused
+
+
+1984 During the conduct of evaluation activities the evaluator may also identify
+areas of concern. These are specific portions of the TOE evidence that the
+evaluator has some reservation about, although the evidence meets the
+requirements for the activity with which the evidence is associated. For
+example, a particular interface specification looks particularly complex, and
+therefore may be prone to error either in the development of the TOE or in
+the operation of the TOE. There is no potential vulnerability apparent at this
+stage, further investigation is required. This is beyond the bounds of
+encountered, as further investigation is required.
+
+
+1985 Difference between potential vulnerability and area of concern:
+
+
+a) Potential vulnerability - The evaluator knows a method of attack that
+can be used to exploit the weakness or the evaluator knows of
+vulnerability information that is relevant to the TOE.
+
+
+b) Area of concern - The evaluator may be able to discount concern as a
+potential vulnerability based on information provided elsewhere.
+While reading interface specification, the evaluator identifies that due
+to the extreme (unnecessary) complexity of an interface a potential
+vulnerability may lay within that area, although it is not apparent
+through this initial examination.
+
+
+1986 The focused approach to the identification of vulnerabilities is an analysis of
+the evidence with the aim of identifying any potential vulnerabilities evident
+through the contained information. It is an unstructured analysis, as the
+approach is not predetermined. This approach to the identification of
+potential vulnerabilities can be used during the independent vulnerability
+analysis required by Evaluation of sub-activity (AVA_VAN.3).
+
+
+1987 This analysis can be achieved through different approaches, that will lead to
+commensurate levels of confidence. None of the approaches have a rigid
+format for the examination of evidence to be performed.
+
+
+1988 The approach taken is directed by the results of the evaluator's assessment of
+the evidence to determine it meets the requirements of the AVA/AGD subactivities. Therefore, the investigation of the evidence for the existence of
+potential vulnerabilities may be directed by any of the following:
+
+
+a) areas of concern identified during examination of the evidence during
+the conduct of evaluation activities;
+
+
+April 2017 Version 3.1 Page 415 of 430
+
+
+**Vulnerability Assessment (AVA)**
+
+
+b) reliance on particular functionality to provide separation, identified
+during the analysis of the architectural design (as in Evaluation of
+sub-activity (ADV_ARC.1)), requiring further analysis to determine
+it cannot be bypassed;
+
+
+c) representative examination of the evidence to hypothesise potential
+vulnerabilities in the TOE.
+
+
+1989 The evaluator will report what actions were taken to identify potential
+vulnerabilities in the evidence. However, the evaluator may not be able to
+describe the steps in identifying potential vulnerabilities before the outset of
+the examination. The approach will evolve as a result of the outcome of
+evaluation activities.
+
+
+1990 The areas of concern may arise from examination of any of the evidence
+provided to satisfy the SARs specified for the TOE evaluation. The
+information publicly accessible is also considered.
+
+
+1991 The activities performed by the evaluator can be repeated and the same
+conclusions, in terms of the level of assurance in the TOE, can be reached
+although the steps taken to achieve those conclusions may vary. As the
+evaluator is documenting the form the analysis took, the actual steps taken to
+achieve those conclusions are also reproducible.
+
+
+**B.2.2.2.3** Methodical
+
+
+1992 The methodical analysis approach takes the form of a structured examination
+of the evidence. This method requires the evaluator to specify the structure
+and form the analysis will take (i.e. the manner in which the analysis is
+performed is predetermined, unlike the focused identification method). The
+method is specified in terms of the information that will be considered and
+how/why it will be considered. This approach to the identification of
+potential vulnerabilities can be used during the independent vulnerability
+analysis required by Evaluation of sub-activity (AVA_VAN.4) and
+Evaluation of sub-activity (AVA_VAN.5).
+
+
+1993 This analysis of the evidence is deliberate and pre-planned in approach,
+considering all evidence identified as an input into the analysis.
+
+
+1994 All evidence provided to satisfy the (ADV) assurance requirements specified
+in the assurance package are used as input to the potential vulnerability
+identification activity.
+
+
+1995 The โmethodicalโ descriptor for this analysis has been used in an attempt to
+capture the characterisation that this identification of potential vulnerabilities
+is to take an ordered and planned approach. A โmethodโ or โsystemโ is to be
+applied in the examination. The evaluator is to describe the method to be
+used in terms of what evidence will be considered, the information within the
+evidence that is to be examined, the manner in which this information is to
+be considered; and the hypothesis that is to be generated.
+
+
+Page 416 of 430 Version 3.1 April 2017
+
+
+**Vulnerability Assessment (AVA)**
+
+
+1996 The following provide some examples that a hypothesis may take:
+
+
+a) consideration of malformed input for interfaces available to an
+attacker at the external interfaces;
+
+
+b) examination of a security mechanism, such as domain separation,
+hypothesising internal buffer overflows leading to degradation of
+separation;
+
+
+c) analysis to identify any objects created in the TOE implementation
+representation that are then not fully controlled by the TSF, and could
+be used by an attacker to undermine the SFRs.
+
+
+1997 For example, the evaluator may identify that interfaces are a potential area of
+weakness in the TOE and specify an approach to the analysis that โall
+interface specifications provided in the functional specification and TOE
+design will be analysed to hypothesise potential vulnerabilitiesโ and go on to
+explain the methods used in the hypothesis.
+
+
+1998 This identification method will provide a plan of attack of the TOE, that
+would be performed by an evaluator completing penetration testing of
+potential vulnerabilities in the TOE. The rationale for the method of
+identification would provide the evidence for the coverage and depth of
+exploitation determination that would be performed on the TOE.
+
+## **B.3 When attack potential is used**
+
+
+**B.3.1** **Developer**
+
+
+1999 Attack potential is used by a PP/ST author during the development of the
+PP/ST, in consideration of the threat environment and the selection of
+assurance components. This may simply be a determination that the attack
+potential possessed by the assumed attackers of the TOE is generically
+characterised as Basic, Enhanced-Basic, Moderate or High. Alternatively, the
+PP/ST may wish to specify particular levels of individual factors assumed to
+be possessed by attackers. (e.g. the attackers are assumed to be experts in the
+TOE technology type, with access to specialised equipment.)
+
+
+2000 The PP/ST author considers the threat profile developed during a risk
+assessment (outside the scope of the CC, but used as an input into the
+development of the PP/ST in terms of the Security Problem Definition or in
+the case of low assurance STs, the requirements statement). Consideration of
+this threat profile in terms of one of the approaches discussed in the
+following sections will permit the specification of the attack potential the
+TOE is to resist.
+
+
+**B.3.2** **Evaluator**
+
+
+2001 Attack potential is especially considered by the evaluator in two distinct
+ways during the ST evaluation and the vulnerability assessment activities.
+
+
+April 2017 Version 3.1 Page 417 of 430
+
+
+**Vulnerability Assessment (AVA)**
+
+
+2002 Attack potential is used by an evaluator during the conduct of the
+vulnerability analysis sub-activity to determine whether or not the TOE is
+resistant to attacks assuming a specific attack potential of an attacker. If the
+evaluator determines that a potential vulnerability is exploitable in the TOE,
+they have to confirm that it is exploitable considering all aspects of the
+intended environment, including the attack potential assumed by an attacker.
+
+
+2003 Therefore, using the information provided in the threat statement of the
+Security Target, the evaluator determines the minimum attack potential
+required by an attacker to effect an attack, and arrives at some conclusion
+about the TOE's resistance to attacks. Table 2 demonstrates the relationship
+between this analysis and attack potential.
+
+
+
+
+
+
+
+
+|Vulnerability
Component|TOE resistant to
attacker with attack
potential of:|Residual vulnerabilities only
exploitable by attacker with
attack potential of:|
+|---|---|---|
+|VAN.5|High|Beyond High|
+|VAN.4|Moderate|High|
+|VAN.3|Enhanced-Basic|Moderate|
+|VAN.2|Basic|Enhanced-Basic|
+|VAN.1|Basic|Enhanced-Basic|
+
+
+
+**Table 2 Vulnerability testing and attack potential**
+
+
+2004 The โbeyond highโ entry in the residual vulnerabilities column of the above
+table represents those potential vulnerabilities that would require an attacker
+to have an attack potential greater than that of โhighโ in order to exploit the
+potential vulnerability. A vulnerability classified as residual in this instance
+reflects the fact that a known weakness exists in the TOE, but in the current
+operational environment, with the assumed attack potential, the weakness
+cannot be exploited.
+
+
+2005 At any level of attack potential a potential vulnerability may be deemed
+โinfeasibleโ due to a countermeasure in the operational environment that
+prevents the vulnerability from being exploited.
+
+
+2006 A vulnerability analysis applies to all TSFI, including ones that access
+probabilistic or permutational mechanisms. No assumptions are made
+regarding the correctness of the design and implementation of the TSFI; nor
+are constraints placed on the attack method or the attacker's interaction with
+the TOE - if an attack is possible, then it is to be considered during the
+vulnerability analysis. As shown in Table 2, successful evaluation against a
+vulnerability assurance component reflects that the TSF is designed and
+implemented to protect against the required level of threat.
+
+
+2007 It is not necessary for an evaluator to perform an attack potential calculation
+for each potential vulnerability. In some cases it is apparent when developing
+the attack method whether or not the attack potential required to develop and
+run the attack method is commensurate with that assumed of the attacker in
+the operational environment. For any vulnerabilities for which an
+exploitation is determined, the evaluator performs an attack potential
+
+
+Page 418 of 430 Version 3.1 April 2017
+
+
+**Vulnerability Assessment (AVA)**
+
+
+calculation to determine that the exploitation is appropriate to the level of
+attack potential assumed for the attacker.
+
+
+2008 The approach described below is to be applied whenever it is necessary to
+calculate attack potential, unless the evaluation authority provides mandatory
+guidance that an alternative approach is to be applied. The values given in
+Tables 3 and 4 below are not mathematically proven. Therefore, the values
+given in these example tables may need to be adjusted according to the
+technology type and specific environments. The evaluator should seek
+guidance from the evaluation authority.
+
+## **B.4 Calculating attack potential**
+
+
+**B.4.1** **Application of attack potential**
+
+
+2009 Attack potential is a function of expertise, resources and motivation. There
+are multiple methods of representing and quantifying these factors. Also,
+there may be other factors that are applicable for particular TOE types.
+
+
+**B.4.1.1** Treatment of motivation
+
+
+2010 Motivation is an attack potential factor that can be used to describe several
+aspects related to the attacker and the assets the attacker desires. Firstly,
+motivation can imply the likelihood of an attack - one can infer from a threat
+described as highly motivated that an attack is imminent, or that no attack is
+anticipated from an un-motivated threat. However, except for the two
+extreme levels of motivation, it is difficult to derive a probability of an attack
+occurring from motivation.
+
+
+2011 Secondly, motivation can imply the value of the asset, monetarily or
+otherwise, to either the attacker or the asset holder. An asset of very high
+value is more likely to motivate an attack compared to an asset of little value.
+However, other than in a very general way, it is difficult to relate asset value
+to motivation because the value of an asset is subjective - it depends largely
+upon the value an asset holder places on it.
+
+
+2012 Thirdly, motivation can imply the expertise and resources with which an
+attacker is willing to effect an attack. One can infer that a highly motivated
+attacker is likely to acquire sufficient expertise and resources to defeat the
+measures protecting an asset. Conversely, one can infer that an attacker with
+significant expertise and resources is not willing to effect an attack using
+them if the attacker's motivation is low.
+
+
+2013 During the course of preparing for and conducting an evaluation, all three
+aspects of motivation are at some point considered. The first aspect,
+likelihood of attack, is what may inspire a developer to pursue an evaluation.
+If the developer believes that the attackers are sufficiently motivated to
+mount an attack, then an evaluation can provide assurance of the ability of
+the TOE to thwart the attacker's efforts. Where the operational environment
+is well defined, for example in a system evaluation, the level of motivation
+
+
+April 2017 Version 3.1 Page 419 of 430
+
+
+**Vulnerability Assessment (AVA)**
+
+
+for an attack may be known, and will influence the selection of
+countermeasures.
+
+
+2014 Considering the second aspect, an asset holder may believe that the value of
+the assets (however measured) is sufficient to motivate attack against them.
+Once an evaluation is deemed necessary, the attacker's motivation is
+considered to determine the methods of attack that may be attempted, as well
+as the expertise and resources used in those attacks. Once examined, the
+developer is able to choose the appropriate assurance level, in particular the
+AVA requirement components, commensurate with the attack potential for
+the threats. During the course of the evaluation, and in particular as a result
+of completing the vulnerability assessment activity, the evaluator determines
+whether or not the TOE, operating in its operational environment, is
+sufficient to thwart attackers with the identified expertise and resources.
+
+
+2015 It may be possible for a PP author to quantify the motivation of an attacker,
+as the PP author has greater knowledge of the operational environment in
+which the TOE (conforming to the requirements of the PP) is to be placed.
+Therefore, the motivation could form an explicit part of the expression of the
+attack potential in the PP, along with the necessary methods and measures to
+quantify the motivation.
+
+
+**B.4.2** **Characterising attack potential**
+
+
+2016 This section examines the factors that determine attack potential, and
+provides some guidelines to help remove some of the subjectivity from this
+aspect of the evaluation process.
+
+
+**B.4.2.1** Determining the attack potential
+
+
+2017 The determination of the attack potential for an attack corresponds to the
+identification of the effort required to create the attack, and to demonstrate
+that it can be successfully applied to the TOE (including setting up or
+building any necessary test equipment), thereby exploiting the vulnerability
+in the TOE. The demonstration that the attack can be successfully applied
+needs to consider any difficulties in expanding a result shown in the
+laboratory to create a useful attack. For example, where an experiment
+reveals some bits or bytes of a confidential data item (such as a key), it is
+necessary to consider how the remainder of the data item would be obtained
+(in this example some bits might be measured directly by further experiments,
+while others might be found by a different technique such as exhaustive
+search). It may not be necessary to carry out all of the experiments to identify
+the full attack, provided it is clear that the attack actually proves that access
+has been gained to a TOE asset, and that the complete attack could
+realistically be carried out in exploitation according to the AVA_VAN
+component targeted. In some cases the only way to prove that an attack can
+realistically be carried out in exploitation according to the AVA_VAN
+component targeted is to perform completely the attack and then rate it based
+upon the resources actually required. One of the outputs from the
+identification of a potential vulnerability is assumed to be a script that gives a
+
+
+Page 420 of 430 Version 3.1 April 2017
+
+
+**Vulnerability Assessment (AVA)**
+
+
+step-by-step description of how to carry out the attack that can be used in the
+exploitation of the vulnerability on another instance of the TOE.
+
+
+2018 In many cases, the evaluators will estimate the parameters for exploitation,
+rather than carry out the full exploitation. The estimates and their rationale
+will be documented in the ETR.
+
+
+**B.4.2.2** Factors to be considered
+
+
+2019 The following factors should be considered during analysis of the attack
+potential required to exploit a vulnerability:
+
+
+a) Time taken to identify and exploit ( _**Elapsed Time**_ );
+
+
+b) Specialist technical expertise required ( _**Specialist Expertise**_ );
+
+
+c) Knowledge of the TOE design and operation ( _**Knowledge of the**_
+_**TOE**_ );
+
+
+d) _**Window of opportunity**_ ;
+
+
+e) _**IT hardware/software or other equipment**_ required for exploitation.
+
+
+2020 In many cases these factors are not independent, but may be substituted for
+each other in varying degrees. For example, expertise or hardware/software
+may be a substitute for time. A discussion of these factors follows. (The
+levels of each factor are discussed in increasing order of magnitude.) When it
+is the case, the less โexpensiveโ combination is considered in the exploitation
+phase.
+
+
+2021 _**Elapsed time**_ is the total amount of time taken by an attacker to identify that
+a particular potential vulnerability may exist in the TOE, to develop an attack
+method and to sustain effort required to mount the attack against the TOE.
+When considering this factor, the worst case scenario is used to estimate the
+amount of time required. The identified amount of time is as follows:
+
+
+a) less than one day;
+
+
+b) between one day and one week;
+
+
+c) between one week and two weeks;
+
+
+d) between two weeks and one month;
+
+
+e) each additional month up to 6 months leads to an increased value;
+
+
+f) more than 6 months.
+
+
+2022 _**Specialist expertise**_ refers to the level of generic knowledge of the
+underlying principles, product type or attack methods (e.g. Internet protocols,
+Unix operating systems, buffer overflows). The identified levels are as
+follows:
+
+
+April 2017 Version 3.1 Page 421 of 430
+
+
+**Vulnerability Assessment (AVA)**
+
+
+a) Laymen are unknowledgeable compared to experts or proficient
+persons, with no particular expertise;
+
+
+b) Proficient persons are knowledgeable in that they are familiar with
+the security behaviour of the product or system type;
+
+
+c) Experts are familiar with the underlying algorithms, protocols,
+hardware, structures, security behaviour, principles and concepts of
+security employed, techniques and tools for the definition of new
+attacks, cryptography, classical attacks for the product type, attack
+methods, etc. implemented in the product or system type.
+
+
+d) The level โMultiple Expertโ is introduced to allow for a situation,
+where different fields of expertise are required at an Expert level for
+distinct steps of an attack.
+
+
+2023 It may occur that several types of expertise are required. By default, the
+higher of the different expertises factors is chosen. In very specific cases, the
+โmultiple expertโ level could be used but it should be noted that the expertise
+must concern fields that are strictly different like for example HW
+manipulation and cryptography.
+
+
+2024 _**Knowledge of the TOE**_ refers to specific expertise in relation to the TOE.
+This is distinct from generic expertise, but not unrelated to it. Identified
+levels are as follows:
+
+
+a) Public information concerning the TOE (e.g. as gained from the
+Internet);
+
+
+b) Restricted information concerning the TOE (e.g. knowledge that is
+controlled within the developer organisation and shared with other
+organisations under a non-disclosure agreement)
+
+
+c) Sensitive information about the TOE (e.g. knowledge that is shared
+between discreet teams within the developer organisation, access to
+which is constrained only to members of the specified teams);
+
+
+d) Critical information about the TOE (e.g. knowledge that is known by
+only a few individuals, access to which is very tightly controlled on a
+strict need to know basis and individual undertaking).
+
+
+2025 The knowledge of the TOE may graduate according to design abstraction,
+although this can only be done on a TOE by TOE basis. Some TOE designs
+may be public source (or heavily based on public source) and therefore even
+the design representation would be classified as public or at most restricted,
+while the implementation representation for other TOEs is very closely
+controlled as it would give an attacker information that would aid an attack
+and is therefore considered to be sensitive or even critical.
+
+
+2026 It may occur that several types of knowledge are required. In such cases, the
+higher of the different knowledge factors is chosen.
+
+
+Page 422 of 430 Version 3.1 April 2017
+
+
+**Vulnerability Assessment (AVA)**
+
+
+2027 _**Window of opportunity**_ (Opportunity) is also an important consideration, and
+has a relationship to the _**Elapsed Time**_ factor. Identification or exploitation
+of a vulnerability may require considerable amounts of access to a TOE that
+may increase the likelihood of detection. Some attack methods may require
+considerable effort off-line, and only brief access to the TOE to exploit.
+Access may also need to be continuous, or over a number of sessions.
+
+
+2028 For some TOEs the _**Window of opportunity**_ may equate to the number of
+samples of the TOE that the attacker can obtain. This is particularly relevant
+where attempts to penetrate the TOE and undermine the SFRs may result in
+the destruction of the TOE preventing use of that TOE sample for further
+testing, e.g. hardware devices. Often in these cases distribution of the TOE is
+controlled and so the attacker must apply effort to obtain further samples of
+the TOE.
+
+
+2029 For the purposes of this discussion:
+
+
+a) unnecessary/unlimited access means that the attack doesn't need any
+kind of opportunity to be realised because there is no risk of being
+detected during access to the TOE and it is no problem to access the
+number of TOE samples for the attack;
+
+
+b) easy means that access is required for less than a day and that the
+number of TOE samples required to perform the attack is less than
+ten;
+
+
+c) moderate means that access is required for less than a month and that
+the number of TOE samples required to perform the attack is less
+than one hundred;
+
+
+d) difficult means that access is required for at least a month or that the
+number of TOE samples required to perform the attack is at least one
+hundred;
+
+
+e) none means that the opportunity window is not sufficient to perform
+the attack (the length for which the asset to be exploited is available
+or is sensitive is less than the opportunity length needed to perform
+the attack - for example, if the asset key is changed each week and
+the attack needs two weeks); another case is, that a sufficient number
+of TOE samples needed to perform the attack is not accessible to the
+attacker - for example if the TOE is a hardware and the probability to
+destroy the TOE during the attack instead of being successful is very
+high and the attacker has only access to one sample of the TOE.
+
+
+2030 Consideration of this factor may result in determining that it is not possible
+to complete the exploit, due to requirements for time availability that are
+greater than the opportunity time.
+
+
+2031 _**IT hardware/software or other equipment**_ refers to the equipment required
+to identify or exploit a vulnerability.
+
+
+April 2017 Version 3.1 Page 423 of 430
+
+
+**Vulnerability Assessment (AVA)**
+
+
+a) Standard equipment is readily available to the attacker, either for the
+identification of a vulnerability or for an attack. This equipment may
+be a part of the TOE itself (e.g. a debugger in an operating system),
+or can be readily obtained (e.g. Internet downloads, protocol analyser
+or simple attack scripts).
+
+
+b) Specialised equipment is not readily available to the attacker, but
+could be acquired without undue effort. This could include purchase
+of moderate amounts of equipment (e.g. power analysis tools, use of
+hundreds of PCs linked across the Internet would fall into this
+category), or development of more extensive attack scripts or
+programs. If clearly different test benches consisting of specialised
+equipment are required for distinct steps of an attack this would be
+rated as bespoke.
+
+
+c) Bespoke equipment is not readily available to the public as it may
+need to be specially produced (e.g. very sophisticated software), or
+because the equipment is so specialised that its distribution is
+controlled, possibly even restricted. Alternatively, the equipment may
+be very expensive.
+
+
+d) The level โMultiple Bespokeโ is introduced to allow for a situation,
+where different types of bespoke equipment are required for distinct
+steps of an attack.
+
+
+2032 Specialist expertise and _**Knowledge of the TOE**_ are concerned with the
+information required for persons to be able to attack a TOE. There is an
+implicit relationship between an attacker's expertise (where the attacker may
+be one or more persons with complementary areas of knowledge) and the
+ability to effectively make use of equipment in an attack. The weaker the
+attacker's expertise, the lower the potential to use equipment (IT
+hardware/software or other equipment). Likewise, the greater the expertise,
+the greater the potential for equipment to be used in the attack. Although
+implicit, this relationship between expertise and the use of equipment does
+not always apply, for instance, when environmental measures prevent an
+expert attacker's use of equipment, or when, through the efforts of others,
+attack tools requiring little expertise to be effectively used are created and
+freely distributed (e.g. via the Internet).
+
+
+**B.4.2.3** Calculation of attack potential
+
+
+2033 Table 3 identifies the factors discussed in the previous section and associates
+numeric values with the total value of each factor.
+
+
+2034 Where a factor falls close to the boundary of a range the evaluator should
+consider use of an intermediate value to those in the table. For example, if
+twenty samples are required to perform the attack then a value between one
+and four may be selected for that factor, or if the design is based on a
+publicly available design but the developer has made some alterations then a
+value between zero and three should be selected according to the evaluator's
+view of the impact of those design changes. The table is intended as a guide.
+
+
+Page 424 of 430 Version 3.1 April 2017
+
+
+**Vulnerability Assessment (AVA)**
+
+
+2035 The โ**โ specification in the table in considering _**Window of Opportunity**_ is
+not to be seen as a natural progression from the timescales specified in the
+preceding ranges associated with this factor. This specification identifies that
+for a particular reason the potential vulnerability cannot be exploited in the
+TOE in its intended operational environment. For example, access to the
+TOE may be detected after a certain amount of time in a TOE with a known
+environment (i.e. in the case of a system) where regular patrols are
+completed, and the attacker could not gain access to the TOE for the required
+two weeks undetected. However, this would not be applicable to a TOE
+connected to the network where remote access is possible, or where the
+physical environment of the TOE is unknown.
+
+
+April 2017 Version 3.1 Page 425 of 430
+
+
+**Vulnerability Assessment (AVA)**
+
+|Factor|Value|
+|---|---|
+|**Elapsed Time**||
+|<= one day|0|
+|<= one week|1|
+|<= two weeks|2|
+|<= one month|4|
+|<= two months|7|
+|<= three months|10|
+|<= four months|13|
+|<= five months|15|
+|<= six months|17|
+|> six months|19|
+|**Expertise**||
+|Layman|0
|
+|Proficient|3*~~(1)~~|
+|Expert|6|
+|Multiple experts|8|
+|**Knowledge of TOE**||
+|Public|0|
+|Restricted|3|
+|Sensitive|7|
+|Critical|11|
+|**Window of Opportunity**||
+|Unnecessary / unlimited access|0|
+|Easy|1|
+|Moderate|4|
+|Difficult|10
|
+|None|**~~(2)~~|
+|**Equipment**||
+|Standard|0
|
+|Specialised|4~~(3)~~|
+|Bespoke|7|
+|Multiple bespoke|9|
+
+
+
+(1) When several proficient persons are required to complete the attack path, the resulting level of expertise still
+remains โproficientโ (which leads to a 3 rating).
+(2) Indicates that the attack path is not exploitable due to other measures in the intended operational
+environment of the TOE.
+(3) If clearly different test benches consisting of specialised equipment are required for distinct steps of an
+attack, this should be rated as bespoke.
+
+
+**Table 3 Calculation of attack potential**
+
+
+2036 To determine the resistance of the TOE to the potential vulnerabilities
+identified the following steps should be applied:
+
+
+a) Define the possible attack scenarios {AS1, AS2, ..., ASn} for the
+TOE in the operational environment.
+
+
+Page 426 of 430 Version 3.1 April 2017
+
+
+**Vulnerability Assessment (AVA)**
+
+
+b) For each attack scenario, perform a theoretical analysis and calculate
+the relevant attack potential using Table 3.
+
+
+c) For each attack scenario, if necessary, perform penetration tests in
+order to confirm or to disprove the theoretical analysis.
+
+
+d) Divide all attack scenarios {AS1, AS2, ..., ASn} into two groups:
+
+
+1) the attack scenarios having been successful (i.e. those that
+have been used to successfully undermine the SFRs), and
+
+
+2) the attack scenarios that have been demonstrated to be
+unsuccessful.
+
+
+e) For each successful attack scenario, apply Table 4 and determine,
+whether there is a contradiction between the resistance of the TOE
+and the chosen AVA_VAN assurance component, see the last column
+of Table 4.
+
+
+f) Should one contradiction be found, the vulnerability assessment will
+fail, e.g. the author of the ST chose the component AVA_VAN.5 and
+an attack scenario with an attack potential of 21 points (high) has
+broken the security of the TOE. In this case the TOE is resistant to
+attacker with attack potential 'Moderate', this contradicts to
+AVA_VAN.5, hence, the vulnerability assessment fails.
+
+
+2037 The โValuesโ column of Table 4 indicates the range of attack potential
+values (calculated using Table 3) of an attack scenario that results in the
+SFRs being undermined.
+
+
+April 2017 Version 3.1 Page 427 of 430
+
+
+**Vulnerability Assessment (AVA)**
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+|Values|Attack
potential
required to
exploit
scenario:|TOE
resistant to
attackers
with attack
potential
of:|Meets assurance
components::|Failure of
components:|
+|---|---|---|---|---|
+|0-9|Basic|No rating|-|AVA_VAN.1,
AVA_VAN.2,
AVA_VAN.3,
AVA_VAN.4,
AVA_VAN.5|
+|10-13|Enhanced-
Basic|Basic|AVA_VAN.1,
AVA_VAN.2|AVA_VAN.3,
AVA_VAN.4,
AVA_VAN.5|
+|14-19|Moderate|Enhanced-
Basic|AVA_VAN.1,
AVA_VAN.2,
AVA_VAN.3|AVA_VAN.4,
AVA_VAN.5|
+|20-24|High|Moderate|AVA_VAN.1,
AVA_VAN.2,
AVA_VAN.3,
AVA_VAN.4|AVA_VAN.5|
+|=>25|Beyond
High|High|AVA_VAN.1,
AVA_VAN.2,
AVA_VAN.3,
AVA_VAN.4,
AVA_VAN.5|-|
+
+
+
+**Table 4 Rating of vulnerabilities and TOE resistance**
+
+
+2038 An approach such as this cannot take account of every circumstance or factor,
+but should give a better indication of the level of resistance to attack required
+to achieve the standard ratings. Other factors, such as the reliance on unlikely
+chance occurrences are not included in the basic model, but can be used by
+an evaluator as justification for a rating other than those that the basic model
+might indicate.
+
+
+2039 It should be noted that whereas a number of vulnerabilities rated individually
+may indicate high resistance to attack, collectively the combination of
+vulnerabilities may indicate that overall a lower rating is applicable. The
+presence of one vulnerability may make another easier to exploit.
+
+
+2040 If a PP/ST author wants to use the attack potential table for the determination
+of the level of attack the TOE should withstand (selection of Vulnerability
+analysis (AVA_VAN) component), he should proceed as follows: For all
+different attack scenarios (i.e. for all different types of attacker and/or
+different types of attack the author has in mind) which must not violate the
+SFRs, several passes through Table 3 should be made to determine the
+different values of attack potential assumed for each such unsuccessful attack
+scenario. The PP/ST author then chooses the highest value of them in order
+
+
+Page 428 of 430 Version 3.1 April 2017
+
+
+**Vulnerability Assessment (AVA)**
+
+
+to determine the level of the TOE resistance to be claimed from Table 4: the
+TOE resistance must be at least equal to this highest value determined. For
+example, the highest value of attack potentials of all attack scenarios, which
+must not undermine the TOE security policy, determined in such a way is
+Moderate; hence, the TOE resistance shall be at least Moderate (i.e.
+Moderate or High); therefore, the PP/ST author can choose either
+AVA_VAN.4 (for Moderate) or AVA_VAN.5 (for High) as the appropriate
+assurance component.
+
+## **B.5 Example calculation for direct attack**
+
+
+2041 Mechanisms subject to direct attack are often vital for system security and
+developers often strengthen these mechanisms. As an example, a TOE might
+use a simple pass number authentication mechanism that can be overcome by
+an attacker who has the opportunity to repeatedly guess another user's pass
+number. The system can strengthen this mechanism by restricting pass
+numbers and their use in various ways. During the course of the evaluation
+an analysis of this direct attack could proceed as follows:
+
+
+2042 Information gleaned from the ST and design evidence reveals that
+identification and authentication provides the basis upon which to control
+access to network resources from widely distributed terminals. Physical
+access to the terminals is not controlled by any effective means. The duration
+of access to a terminal is not controlled by any effective means. Authorised
+users of the system choose their own pass numbers when initially authorised
+to use the system, and thereafter upon user request. The system places the
+following restrictions on the pass numbers selected by the user:
+
+
+a) the pass number must be at least four and no greater than six digits
+long;
+
+
+b) consecutive numerical sequences are disallowed (such as 7,6,5,4,3);
+
+
+c) repeating digits is disallowed (each digit must be unique).
+
+
+2043 Guidance provided to the users at the time of pass number selection is that
+pass numbers should be as random as possible and should not be affiliated
+with the user in some way - a date of birth, for instance.
+
+
+2044 The pass number space is calculated as follows:
+
+
+a) Patterns of human usage are important considerations that can
+influence the approach to searching a password space. Assuming the
+worst case scenario and the user chooses a number comprising only
+four digits, the number of pass number permutations assuming that
+each digit must be unique is:
+
+
+April 2017 Version 3.1 Page 429 of 430
+
+
+**Vulnerability Assessment (AVA)**
+
+
+b) The number of possible increasing sequences is seven, as is the
+number of decreasing sequences. The pass number space after
+disallowing sequences is:
+
+
+2045 Based on further information gleaned from the design evidence, the pass
+number mechanism is designed with a terminal locking feature. Upon the
+sixth failed authentication attempt the terminal is locked for one hour. The
+failed authentication count is reset after five minutes so that an attacker can
+at best attempt five pass number entries every five minutes, or 60 pass
+number entries every hour.
+
+
+2046 On average, an attacker would have to enter 2513 pass numbers, over 2513
+minutes, before entering the correct pass number. The average successful
+attack would, as a result, occur in slightly less than:
+
+
+2047 Using the approach to calculate the attack potential, described in the previous
+section, identifies that it is possible that a layman can defeat the mechanism
+within days (given easy access to the TOE), with the use of standard
+equipment, and with no knowledge of the TOE, giving a value of 1. Given
+the resulting sum, 1, the attack potential required to effect a successful attack
+is not rated, as it falls below that considered to be Basic.
+
+
+Page 430 of 430 Version 3.1 April 2017
+
+
+
diff --git a/niap-cc/sdp-file-encrypt/doc/knowledge_base/PP_MDF_V3.3.md b/niap-cc/sdp-file-encrypt/doc/knowledge_base/PP_MDF_V3.3.md
new file mode 100644
index 0000000..b7e3cb9
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/doc/knowledge_base/PP_MDF_V3.3.md
@@ -0,0 +1,14492 @@
+Consider using the pymupdf_layout package for a greatly improved page layout analysis.
+# **Mobile Device Fundamentals**
+
+Version: 3.3
+
+2022-09-12
+**National Information Assurance Partnership**
+
+
+**Revision History**
+
+
+**Version** **Date** **Comment**
+
+
+
+1.1 201401-12
+
+
+2.0 201509-14
+
+
+3.0 201509-17
+
+
+3.1 201704-05
+
+
+
+
+
+Typographical changes and additional clarifications in application notes. Removed
+assignment from FCS_TLS_EXT.1 and limited testing to those ciphersuites in both
+FCS_TLS_EXT.1 and FCS_TLS_EXT.2.
+
+
+Included changes based on Technical Rapid Response Team Decisions. Clarified many
+requirements and evaluation activities. Mandated objective requirements:
+
+Application Access Control (FDP_ACF_EXT.1.2)
+VPN Information Flow Control (FDP_IFC_EXT.1)
+
+Added new objective requirements:
+
+Suite B cryptography for IEEE 802.11
+Certificate enrollment
+Protection of additional key material types
+Heap overflow protection
+Bluetooth requirements
+Cryptographic operation services for applications
+Remote Attestation (FPT_NOT_EXT.1)
+
+Added transition dates for some objective requirements.
+Included hardware-isolated REK and key storage selections.
+Allowed key derivation by REK.
+Clarified FTP_ITC_EXT.1 and added FDP_UPC_EXT.1.
+Mandated HTTPS and TLS for application use. (FDP_UPC_EXT.1)
+Removed Dual_EC_DRBG as an approved DRBG.
+Adopted new TLS requirements.
+Mandated TSF Wipe upon authentication failure limit and required number of
+authentication failures be maintained across reboot.
+Clarified Management Class.
+Included more domain isolation discussion and tests.
+Updated Audit requirements and added Auditable Events table.
+Added SFR Category Mapping Table.
+Updated Use Case Templates.
+Moved Glossary to Introduction.
+
+
+Included changes based on Technical Rapid Response Team Decisions.
+Clarified many requirements and evaluation activities.
+Mandated objective requirements:
+
+Generation of Audit Records (FAU_GEN.1)
+Audit Storage Protection (FAU_STG.1)
+Audit Storage Overwrite (FAU_STG.4)
+Lock Screen DAR (FDP_DAR_EXT.2)
+Discard Bluetooth Connection Attempts from Bluetooth Addresses with Existing
+Connection (FIA_BLT_EXT.3)
+JTAG Disablement (FPT_JTA)
+
+Added new objective requirements:
+
+Application Backup
+Biometric Authentication Factor
+Access Control
+User Authentication
+Bluetooth Encryption
+
+WLAN client requirements moved to Extended Package for WLAN Client.
+Added SFRs to support BYOD Use Case
+BYOD Use Case
+Updated key destruction SFR
+
+
+Included changes based on Technical Rapid Response Team Decisions and incorporated
+Technical Decisions.
+Modified biometric requirements:
+
+FIA_UAU.5 - Added iris, face, voice and vein as supported modalities, in addition to
+fingerprint (allowed in version 3)
+FIA_BMG_EXT.1.1 - Clarified AA to specify that vendor evidence is acceptable and
+expectations of evidence provided.
+FIA_BMG_EXT.1.2 - SAFAR was changed to an assignment of a SAFAR no greater
+than 1:500.
+FIA_AFL_EXT.1 - Updated to allow each biometric modality to utilize an individual or
+shared counter.
+
+FCS_TLSC_EXT.1.1 - Removed TLS ciphersuites that utilized SHA1 and updated optional
+ciphersuites to be uniformed across PPs.
+FCS_STG_EXT.2.2 - Modified to require long term trusted channel key material be
+encrypted by an approved method.
+
+
+3.2 202104-15
+
+
+3.3 202209-12
+
+
+**Contents**
+
+
+
+FIA_UAU_EXT.1.1 - Modified to allow the long term trusted channel key material to be
+available prior to password being entered at start-up.
+
+
+Removed TLS SFRs and utilized TLS Functional Package
+Removed Bluetooth SFRs and utilized Bluetooth Module. Bluetooth SFR moved to
+Implementation Dependent.
+FPT_TUD_EXT.4.2 renumbered to FPT_TUD_EXT.5.1
+
+
+Integrated Biometrics cPP Module, Included changes based on Technical Rapid Response
+Team Decisions and open issues from GitHub.
+
+Removed biometric definitions from Tech Terms
+Removed FDP_PBA
+Removed FIA_BMG
+Updated FIA_UAU.5 to support bio cPP module
+Moved FTA_TAB.1 to mandatory
+Moved FAU_SAR.1 to mandatory
+Added ECD
+Updated WLAN Client reference from Extended Package to Module
+Removed Diffie-Hellman group 14 selection from FCS_CKM.1.1 and
+FCS_CKM.2.1/UNLOCKED
+
+
+
+1 Introduction
+1.1 Objectives of Document
+1.2 Terms
+1.2.1 Common Criteria Terms
+1.2.2 Technical Terms
+1.3 Scope of Document
+1.4 Intended Readership
+1.5 TOE Overview
+1.6 TOE Usage
+2 Conformance Claims
+3 Security Problem Description
+3.1 Threats
+3.2 Assumptions
+3.3 Organizational Security Policies
+4 Security Objectives
+4.1 Security Objectives for the TOE
+4.2 Security Objectives for the Operational Environment
+4.3 Security Objectives Rationale
+5 Security Requirements
+5.1 Security Functional Requirements
+5.1.1 Auditable Events for Mandatory SFRs
+5.1.2 Class: Security Audit (FAU)
+5.1.3 Class: Cryptographic Support (FCS)
+5.1.4 Cryptographic Storage (FCS_STG_EXT)
+5.1.5 Class: User Data Protection (FDP)
+5.1.6 Class: Identification and Authentication (FIA)
+5.1.7 Class: Security Management (FMT)
+5.1.8 Class: Protection of the TSF (FPT)
+5.1.9 Class: TOE Access (FTA)
+5.1.10 Class: Trusted Path/Channels (FTP)
+5.1.11 TOE Security Functional Requirements Rationale
+5.2 Security Assurance Requirements
+5.2.1 Class ASE: Security Target
+5.2.2 Class ADV: Development
+5.2.3 Class AGD: Guidance Documentation
+5.2.4 Class ALC: Life-cycle Support
+5.2.5 Class ATE: Tests
+5.2.6 Class AVA: Vulnerability Assessment
+Appendix A - Optional Requirements
+A.1 Strictly Optional Requirements
+A.1.1 Class: Identification and Authentication (FIA)
+A.2 Objective Requirements
+A.2.1 Class: Security Audit (FAU)
+A.2.2 Class: Cryptographic Support (FCS)
+A.2.3 Class: User Data Protection (FDP)
+A.2.4 Class: Identification and Authentication (FIA)
+A.2.5 Class: Security Management (FMT)
+A.2.6 Class: Protection of the TSF (FPT)
+A.3 Implementation-dependent Requirements
+A.3.1 Bluetooth
+A.3.1.1 Class: User Data Protection (FDP)
+Appendix B - Selection-based Requirements
+B.1 Class: Cryptographic Support (FCS)
+
+
+B.2 Class: User Data Protection (FDP)
+B.3 Class: Protection of the TSF (FPT)
+Appendix C - Extended Component Definitions
+C.1 Extended Components Table
+C.2 Extended Component Definitions
+C.2.1 Class: Cryptographic Support (FCS)
+C.2.1.1 FCS_CKM_EXT Cryptographic Key Management
+C.2.1.2 FCS_HTTPS_EXT HTTPS Protocol
+C.2.1.3 FCS_IV_EXT Initialization Vector Generation
+C.2.1.4 FCS_RBG_EXT Random Bit Generation
+C.2.1.5 FCS_SRV_EXT Cryptographic Algorithm Services
+C.2.1.6 FCS_STG_EXT Cryptographic Key Storage
+C.2.2 Class: Identification and Authentication (FIA)
+C.2.2.1 FIA_AFL_EXT Authentication Failures
+C.2.2.2 FIA_PMG_EXT Password Management
+C.2.2.3 FIA_TRT_EXT Authentication Throttling
+C.2.2.4 FIA_UAU_EXT User Authentication
+C.2.2.5 FIA_X509_EXT X.509 Certificates
+C.2.3 Class: Protection of the TSF (FPT)
+C.2.3.1 FPT_AEX_EXT Anti-Exploitation Capabilities
+C.2.3.2 FPT_BBD_EXT Baseband Processing
+C.2.3.3 FPT_BLT_EXT Limitation of Bluetooth Profile Support
+C.2.3.4 FPT_JTA_EXT JTAG Disablement
+C.2.3.5 FPT_KST_EXT Key Storage
+C.2.3.6 FPT_NOT_EXT Self-Test Notification
+C.2.3.7 FPT_TST_EXT TSF Self Test
+C.2.3.8 FPT_TUD_EXT TSF Updates
+C.2.4 Class: Security Management (FMT)
+C.2.4.1 FMT_MOF_EXT Management of Functions in TSF
+C.2.4.2 FMT_SMF_EXT Specification of Management Functions
+C.2.5 Class: TOE Access (FTA)
+C.2.5.1 FTA_SSL_EXT Session Locking and Termination
+C.2.6 Class: Trusted Path/Channels (FTP)
+C.2.6.1 FTP_ITC_EXT Inter-TSF Trusted Channel
+C.2.7 Class: User Data Protection (FDP)
+C.2.7.1 FDP_ACF_EXT Access Control Functions
+C.2.7.2 FDP_BCK_EXT Application Backup
+C.2.7.3 FDP_BLT_EXT Limitation of Bluetooth Device Access
+C.2.7.4 FDP_DAR_EXT Data-at-Rest Encryption
+C.2.7.5 FDP_IFC_EXT Subset Information Flow Control
+C.2.7.6 FDP_STG_EXT User Data Storage
+C.2.7.7 FDP_UPC_EXT Inter-TSF User Data Transfer Protection
+Appendix D - Validation Guidelines
+Appendix E - Implicitly Satisfied Requirements
+Appendix F - Entropy Documentation And Assessment
+F.1 Design Description
+F.2 Entropy Justification
+F.3 Operating Conditions
+F.4 Health Testing
+Appendix G - Initialization Vector Requirements for NIST-Approved Cipher Modes
+Appendix H - Use Case Templates
+H.1 Enterprise-owned device for general-purpose enterprise use and limited personal use
+H.2 Enterprise-owned device for specialized, high security use
+H.3 Personally-owned device for personal and enterprise use
+H.4 Personally-owned device for personal and limited enterprise use
+Appendix I - Acronyms
+Appendix J - Bibliography
+Appendix K - Acknowledgments
+
+
+# **1 Introduction**
+
+**1.1 Objectives of Document**
+
+
+The scope of this Protection Profile (PP) is to describe the security functionality of mobile devices in terms of
+
+[CC] and to define functional and assurance requirements for such devices.
+
+
+**1.2 Terms**
+
+
+The following sections list Common Criteria and technology terms used in this document.
+
+
+**1.2.1 Common Criteria Terms**
+
+
+Assurance Grounds for confidence that a TOE meets the SFRs [CC].
+
+
+
+Base
+Protection
+Profile (BasePP)
+
+
+Collaborative
+Protection
+Profile (cPP)
+
+
+Common
+Criteria (CC)
+
+
+Common
+Criteria
+Testing
+Laboratory
+
+
+Common
+Evaluation
+Methodology
+(CEM)
+
+
+Distributed
+TOE
+
+
+Extended
+Package (EP)
+
+
+Functional
+Package (FP)
+
+
+Operational
+Environment
+(OE)
+
+
+Protection
+Profile (PP)
+
+
+Protection
+Profile
+Configuration
+(PPConfiguration)
+
+
+Protection
+Profile Module
+(PP-Module)
+
+
+Security
+Assurance
+Requirement
+(SAR)
+
+
+Security
+Functional
+Requirement
+(SFR)
+
+
+Security
+Target (ST)
+
+
+
+Protection Profile used as a basis to build a PP-Configuration.
+
+
+A Protection Profile developed by international technical communities and approved by
+multiple schemes.
+
+
+Common Criteria for Information Technology Security Evaluation (International Standard
+ISO/IEC 15408).
+
+
+Within the context of the Common Criteria Evaluation and Validation Scheme (CCEVS), an
+IT security evaluation facility accredited by the National Voluntary Laboratory
+Accreditation Program (NVLAP) and approved by the NIAP Validation Body to conduct
+Common Criteria-based evaluations.
+
+
+Common Evaluation Methodology for Information Technology Security Evaluation.
+
+
+A TOE composed of multiple components operating as a logical whole.
+
+
+A deprecated document form for collecting SFRs that implement a particular protocol,
+technology, or functionality. See Functional Packages.
+
+
+A document that collects SFRs for a particular protocol, technology, or functionality.
+
+
+Hardware and software that are outside the TOE boundary that support the TOE
+functionality and security policy.
+
+
+An implementation-independent set of security requirements for a category of products.
+
+
+A comprehensive set of security requirements for a product type that consists of at least
+one Base-PP and at least one PP-Module.
+
+
+An implementation-independent statement of security needs for a TOE type complementary
+to one or more Base-PPs.
+
+
+A requirement to assure the security of the TOE.
+
+
+A requirement for security enforcement by the TOE.
+
+
+A set of implementation-dependent security requirements for a specific product.
+
+
+
+Target of The product under evaluation.
+
+
+Evaluation
+(TOE)
+
+
+TOE Security
+Functionality
+(TSF)
+
+
+TOE Summary
+Specification
+(TSS)
+
+
+
+The security functionality of the product under evaluation.
+
+
+A description of how a TOE satisfies the SFRs in an ST.
+
+
+
+**1.2.2 Technical Terms**
+
+
+
+Address Space
+Layout
+Randomization
+(ASLR)
+
+
+
+An anti-exploitation feature, which loads memory mappings into unpredictable locations.
+ASLR makes it more difficult for an attacker to redirect control to code that they have
+introduced into the address space of a process or the kernel.
+
+
+
+Administrator The Administrator is responsible for management activities, including setting the policy
+that is applied by the enterprise on the Mobile Device. This administrator is likely to be
+acting remotely and could be the Mobile Device Management (MDM) Administrator acting
+through an MDM Agent. If the device is unenrolled, the user is the administrator.
+
+
+
+Auxiliary Boot
+Modes
+
+
+Biometric
+Authentication
+Factor (BAF)
+
+
+Common
+Application
+Developer
+
+
+Critical
+Security
+Parameter
+(CSP)
+
+
+
+Auxiliary boot modes are states in which the device provides power to one or more
+components to provide an interface that enables an unauthenticated user to interact with
+either a specific component or several components that exist outside of the deviceโs fully
+authenticated, operational state.
+
+
+Authentication factor, which uses biometric sample, matched to a biometric authentication
+template to help establish identity.
+
+
+Application developers (or software companies) often produce many applications under the
+same name. Mobile devices often allow shared resources by such applications where
+otherwise resources would not be shared.
+
+
+Security-related information whose disclosure or modification can compromise the security
+of a cryptographic module or authentication system.
+
+
+
+Data Program/application or data files that are stored or transmitted by a server or Mobile
+Device (MD).
+
+
+
+Data
+Encryption
+Key (DEK)
+
+
+Developer
+Modes
+
+
+Encrypted
+Software Keys
+
+
+
+A key used to encrypt data-at-rest.
+
+
+Developer modes are states in which additional services are available to a user in order to
+provide enhanced system access for debugging of software.
+
+
+These keys are stored in the main file system encrypted by another key and can be
+changed and sanitized.
+
+
+
+Enrolled State The state in which the Mobile Device is managed with active policy settings from the
+administrator.
+
+
+
+Enterprise
+Data
+
+
+Ephemeral
+Keys
+
+
+File
+Encryption
+Key (FEK)
+
+
+HardwareIsolated Keys
+
+
+Hybrid
+Authentication
+
+
+Immutable
+Hardware Key
+
+
+
+Enterprise data is any data residing in the enterprise servers, or temporarily stored on
+Mobile Devices to which the Mobile Device user is allowed access according to security
+policy defined by the enterprise and implemented by the administrator.
+
+
+These keys are stored in volatile memory.
+
+
+A DEK used to encrypt a file or a director when File Encryption is used. FEKs are unique to
+each encrypted file or directory.
+
+
+The OS can only access these keys by reference, if at all, during runtime.
+
+
+A hybrid authentication factor is one where a user has to submit a combination of a
+biometric sample and a PIN or password and both must pass. If either factor fails, the
+entire attempt fails. The user shall not be made aware of which factor failed, if either fails.
+
+
+These keys are stored as hardware-protected raw key and cannot be changed or sanitized.
+
+
+
+Key Chaining The method of using multiple layers of encryption keys to protect data. A top layer key
+encrypts a lower layer key, which encrypts the data; this method can have any number of
+
+
+Key
+Encryption
+Key (KEK)
+
+
+
+layers.
+
+
+A key used to encrypt other keys, such as DEKs or storage that contains keys.
+
+
+
+Locked State Powered on but most functionality is unavailable for use. User authentication is required to
+access functionality.
+
+
+MDM Agent The MDM Agent is installed on a Mobile Device as an application or is part of the Mobile
+Deviceโs OS. The MDM Agent establishes a secure connection back to the MDM Server
+controlled by the administrator.
+
+
+Minutia Point Friction ridge characteristics that are used to individualize a fingerprint image. Minutia
+are the points where friction ridges begin, terminate, or split into two or more ridges. In
+many fingerprint systems, the minutia points are compared for recognition purposes.
+
+
+
+Mobile Device
+(MD)
+
+
+Mobile Device
+Management
+(MDM)
+
+
+Mobile Device
+User (User)
+
+
+Modality
+(Biometrics)
+
+
+Mutable
+Hardware Key
+
+
+Operating
+System (OS)
+
+
+PIN
+Authentication
+Factor
+
+
+Password
+Authentication
+Factor
+
+
+Powered Off
+State
+
+
+Protected
+Data (PD)
+
+
+Root
+Encryption
+Key (REK)
+
+
+
+A device which is composed of a hardware platform and its system software. The device
+typically provides wireless connectivity and may include software for functions like secure
+messaging, email, web, VPN (Virtual Private Network) connection, and VoIP (Voice over
+IP), for access to the protected enterprise network, enterprise data and applications, and
+for communicating to other Mobile Devices.
+
+
+Mobile device management (MDM) products allow enterprises to apply security policies to
+mobile devices. This system consists of two primary components: the MDM Server and the
+MDM Agent.
+
+
+The individual authorized to physically control and operate the Mobile Device. Depending
+on the use case, this can be the device owner or an individual authorized by the device
+owner.
+
+
+A type or class of biometric system, such as fingerprint recognition, facial recognition, iris
+recognition, voice recognition, signature/sign, and others.
+
+
+These keys are stored as hardware-protected raw key and can be changed or sanitized.
+
+
+Software that runs at the highest privilege level and can directly control hardware
+resources. Modern Mobile Devices typically have at least two primary operating systems:
+one, which runs on the application processor and one, which runs on the cellular baseband
+processor. The OS of the application processor handles most user interactions and provides
+the execution environment for apps. The OS of the cellular baseband processor handles
+communications with the cellular network and may control other peripherals. The term OS,
+without context, may be assumed to refer to the OS of the application processor.
+
+
+A PIN is a set of numeric or alphabetic characters that may be used in addition to a
+biometric factor to provide a hybrid authentication factor. At this time it is not considered
+as a stand-alone authentication mechanism. A PIN is distinct from a password in that the
+allowed character set and required length of a PIN is typically smaller than that of a
+password as it is designed to be input quickly.
+
+
+A type of authentication factor requiring the user to provide a secret set of characters to
+gain access.
+
+
+The device has been shut down such that no TOE function can be performed.
+
+
+Protected data is all non-TSF data, including all user or enterprise data. Some or all of this
+data may be considered sensitive data as well.
+
+
+A key tied to the device used to encrypt other keys.
+
+
+
+Sensitive data Sensitive data shall be identified in the TSS section of the Security Target (ST) by the ST
+author. Sensitive data is a subset or all of the Protected data. Sensitive data may include
+all user or enterprise data or may be specific application data such as emails, messaging,
+documents, calendar items, and contacts. Sensitive data is protected while in the locked
+state (FDP_DAR_EXT.2).
+
+
+Software Keys The OS access the raw bytes of these keys during runtime.
+
+
+TSF Data Data for the operation of the TSF upon which the enforcement of the requirements relies.
+
+
+
+Trust Anchor
+Database
+
+
+Unenrolled
+State
+
+
+
+A list of trusted root Certificate Authority certificates.
+
+
+The state in which the Mobile Device is not managed.
+
+
+Unlocked
+State
+
+
+Verification
+(Biometrics)
+
+
+
+Powered on and device functionality is available for use. Implies user authentication has
+occurred (when so configured).
+
+
+A task where the biometric system attempts to confirm an individualโs claimed identity by
+comparing a submitted sample to one or more previously enrolled authentication
+templates.
+
+
+
+**1.3 Scope of Document**
+
+
+The scope of the Protection Profile within the development and evaluation process is described in the
+Common Criteria for Information Technology Security Evaluation [CC]. In particular, a PP defines the IT
+security requirements of a generic type of TOE and specifies the functional and assurance security measures
+to be offered by that TOE to meet stated requirements [CC].
+
+
+**1.4 Intended Readership**
+
+
+The target audiences of this PP are Mobile Device developers, CC consumers, evaluators and schemes.
+
+
+**1.5 TOE Overview**
+
+
+This assurance standard specifies information security requirements for Mobile Devices for use in an
+enterprise. A Mobile Device in the context of this assurance standard is a device, which is composed of a
+hardware platform and its system software. The device typically provides wireless connectivity and may
+include software for functions like secure messaging, email, web, VPN connection, and VoIP (Voice over IP),
+for access to the protected enterprise network, enterprise data and applications, and for communicating to
+other Mobile Devices.
+
+
+Figure 1 illustrates the network operating environment of the Mobile Device.
+
+
+**Figure 1: Mobile Device Network Environment**
+
+
+Examples of a "Mobile Device" that should claim conformance to this Protection Profile include smartphones,
+tablet computers, and other Mobile Devices with similar capabilities.
+
+
+The Mobile Device provides essential services, such as cryptographic services, data-at-rest protection, and
+key storage services to support the secure operation of applications on the device. Additional security
+features such as security policy enforcement, application mandatory access control, anti-exploitation features,
+user authentication, and software integrity protection are implemented in order to address threats.
+
+
+This assurance standard describes these essential security services provided by the Mobile Device and serves
+[as a foundation for a secure mobile architecture. The wireless connectivity shall be validated against the PP-](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=386&id=386)
+Module for Wireless LAN Clients, version 1.0. If the mobile device contains Bluetooth functionality (i.e., has
+[Bluetooth hardware), the Bluetooth connectivity shall be evaluated against the PP-Module for Bluetooth,](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=425&id=425)
+version 1.0. As illustrated in Figure 2, it is expected that a typical deployment would also include either thirdparty or bundled components. Whether these components are bundled as part of the Mobile Device by the
+manufacturer or developed by a third-party, they must be separately validated against the related assurance
+standards such as the PP-Module for MDM Agent, PP-Module for VPN Client, PP-Module for VVoIP, and cPPModule for Biometrics. It is the responsibility of the architect of the overall secure mobile architecture to
+ensure validation of these components. Additional applications that may come pre-installed on the Mobile
+Device that are not validated are considered to be potentially flawed, but not malicious. Examples include
+email client and web browser.
+
+
+**Figure 2: Optional Additional Mobile Device Components**
+
+
+**1.6 TOE Usage**
+
+
+The Mobile Device may be operated in a number of use cases. use-case-appendix provides use case templates
+that list those selections, assignments, and objective requirements that best support the use cases identified
+by this Protection Profile. In addition to providing essential security services, the Mobile Device includes the
+necessary security functionality to support configurations for these various use cases. Each use case may
+require additional configuration and applications to achieve the desired security. A selection of these use
+cases is elaborated below.
+
+
+Several of the use case templates include objective requirements that are strongly desired for the indicated
+use cases. Readers can expect those requirements to be made mandatory in a future revision of this
+protection profile, and industry should aim to include that security functionality in products in the near-term.
+
+
+As of publication of this version of the Protection Profile, meeting the requirements in Section 5 Security
+Requirements is necessary for all use cases.
+
+
+**[USE CASE 1] Enterprise-owned device for general-purpose enterprise use and limited personal**
+**use**
+
+
+An enterprise-owned device for general-purpose business use is commonly called _Corporately Owned,_
+_Personally Enabled (COPE)_ . This use case entails a significant degree of enterprise control over
+configuration and, possibly, software inventory. The enterprise elects to provide users with Mobile
+Devices and additional applications (such as VPN or email clients) in order to maintain control of their
+Enterprise data and security of their networks. Users may use Internet connectivity to browse the web or
+access corporate mail or run enterprise applications, but this connectivity may be under significant
+control of the enterprise.
+For changes to included SFRs, selections, and assignments required for this use case, see H.1
+Enterprise-owned device for general-purpose enterprise use and limited personal use.
+
+
+**[USE CASE 2] Enterprise-owned device for specialized, high security use**
+
+
+An enterprise-owned device with intentionally limited network connectivity, tightly controlled
+configuration, and limited software inventory is appropriate for specialized, high-security use cases. For
+example, the device may not be permitted connectivity to any external peripherals. It may only be able to
+communicate via its Wi-Fi or cellular radios with the enterprise-run network, which may not even permit
+connectivity to the Internet. Use of the device may entail compliance with policies that are more
+restrictive than those in any general-purpose use case, yet may mitigate risks to highly sensitive
+information. As in the previous case, the enterprise will look for additional applications providing
+enterprise connectivity and services to have a similar level of assurance as the platform.
+For changes to included SFRs, selections, and assignments required for this use case, see H.2
+Enterprise-owned device for specialized, high security use.
+
+
+**[USE CASE 3] Personally-owned device for personal and enterprise use**
+
+
+A personally-owned device that is used for both personal activities and enterprise data is commonly
+called Bring Your Own Device (BYOD). The device may be provisioned for access to enterprise resources
+after significant personal usage has occurred. Unlike in the enterprise-owned cases, the enterprise is
+limited in what security policies it can enforce because the user purchased the device primarily for
+personal use and is unlikely to accept policies that limit the functionality of the device. However, because
+the enterprise allows the user full (or nearly full) access to the enterprise network, the enterprise will
+require their own security controls to ensure that enterprise resources are protected from potential
+threats posed by the personal activities on the device. These controls could potentially be enforced by a
+separation mechanism built-in to the device itself to distinguish between enterprise and personal
+activities, or by a third-party application that provides access to enterprise resources and leverages
+security capabilities provided by the mobile device. Based upon the operational environment and the
+acceptable risk level of the enterprise, those security functional requirements outlined in Section 5
+Security Requirements of this PP along with the selections in the Use Case 3 template defined in
+Appendix F - Use Case Templates are sufficient for the secure implementation of this BYOD use case.
+For changes to included SFRs, selections, and assignments required for this use case, see H.3
+
+
+Personally-owned device for personal and enterprise use.
+
+
+**[USE CASE 4] Personally-owned device for personal and limited enterprise use**
+
+
+A personally-owned device that is used for both personal activities and enterprise data is commonly
+called Bring Your Own Device (BYOD). This device may be provisioned for limited access to enterprise
+resources such as enterprise email. Because the user does not have full access to the enterprise or
+enterprise data, the enterprise may not need to enforce any security policies on the device. However, the
+enterprise may want secure email and web browsing with assurance that the services being provided to
+those clients by the Mobile Device are not compromised. Based upon the operational environment and
+the acceptable risk level of the enterprise, those security functional requirements outlined in Section 5
+Security Requirements of this PP are sufficient for the secure implementation of this BYOD use case.
+
+
+# **2 Conformance Claims**
+
+**Conformance Statement**
+
+An ST must claim exact conformance to this PP, as defined in the CC and CEM addenda for Exact
+Conformance, Selection-based SFRs, and Optional SFRs (dated May 2017).
+
+
+The following PP-Modules are allowed to be specified in a PP-Configuration with this PP.
+
+
+[PP-Module for Virtual Private Network (VPN) Clients, version 2.4](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=467&id=467)
+[PP-Module for Bluetooth, version 1.0](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=425&id=425)
+[PP-Module for Mobile Device Management Agent, version 1.0](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=441&id=441)
+[PP-Module for Wireless LAN Clients, version 1.0](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=386&id=386)
+[Biometric Enrollment and Verification, version 1.1](https://github.com/biometricITC/cPP-biometrics/blob/master/Protection%20Profile/BiocPP.adoc)
+
+
+**CC Conformance Claims**
+
+This PP is conformant to Parts 2 (extended) and 3 (conformant) of Common Criteria Version 3.1, Revision
+5.
+
+
+**PP Claim**
+
+This PP does not claim conformance to any Protection Profile.
+
+
+**Package Claim**
+
+This PP is Functional Package for Transport Layer Security (TLS), version 1.1 Conformant.
+
+
+# **3 Security Problem Description**
+
+**3.1 Threats**
+
+
+Mobile devices are subject to the threats of traditional computer systems along with those entailed by their
+mobile nature. The threats considered in this PP are those of network eavesdropping, network attacks,
+physical access, malicious or flawed applications, persistent presence, and backup as detailed in the following
+sections.
+
+
+**T.NETWORK_EAVESDROP**
+
+An attacker is positioned on a wireless communications channel or elsewhere on the network
+infrastructure. Attackers may monitor and gain access to data exchanged between the Mobile Device and
+other endpoints.
+
+
+**T.NETWORK_ATTACK**
+
+An attacker is positioned on a wireless communications channel or elsewhere on the network
+infrastructure. Attackers may initiate communications with the Mobile Device or alter communications
+between the Mobile Device and other endpoints in order to compromise the Mobile Device. These attacks
+include malicious software update of any applications or system software on the device. These attacks
+also include malicious web pages or email attachments, which are usually delivered to devices over the
+network.
+
+
+**T.PHYSICAL_ACCESS**
+
+An attacker, with physical access, may attempt to access user data on the Mobile Device including
+credentials. These physical access threats may involve attacks, which attempt to access the device
+through external hardware ports, impersonate the user authentication mechanisms, through its user
+interface, and also through direct and possibly destructive access to its storage media. Note: Defending
+against device re-use after physical compromise is out of scope for this Protection Profile.
+
+
+**T.MALICIOUS_APP**
+
+Applications loaded onto the Mobile Device may include malicious or exploitable code. This code could
+be included intentionally or unknowingly by the developer, perhaps as part of a software library.
+Malicious apps may attempt to exfiltrate data to which they have access. They may also conduct attacks
+against the platformโs system software, which will provide them with additional privileges and the ability
+to conduct further malicious activities. Malicious applications may be able to control the device's sensors
+(GPS, camera, microphone) to gather intelligence about the user's surroundings even when those
+activities do not involve data resident or transmitted from the device. Flawed applications may give an
+attacker access to perform network-based or physical attacks that otherwise would have been prevented
+
+
+**T.PERSISTENT_PRESENCE**
+
+Persistent presence on a device by an attacker implies that the device has lost integrity and cannot
+regain it. The device has likely lost this integrity due to some other threat vector, yet the continued
+access by an attacker constitutes an on-going threat in itself. In this case, the device and its data may be
+controlled by an adversary as well as by its legitimate owner.
+
+
+**3.2 Assumptions**
+
+
+The specific conditions listed below are assumed to exist in the TOEโs Operational Environment. These
+include both practical realities in the development of the TOE security requirements and the essential
+environmental conditions on the use of the TOE.
+
+
+**A.CONFIG**
+
+It is assumed that the TOEโs security functions are configured correctly in a manner to ensure that the
+TOE security policies will be enforced on all applicable network traffic flowing among the attached
+networks.
+
+
+**A.NOTIFY**
+
+It is assumed that the mobile user will immediately notify the administrator if the Mobile Device is lost or
+stolen.
+
+
+**A.PRECAUTION**
+
+It is assumed that the mobile user exercises precautions to reduce the risk of loss or theft of the Mobile
+Device.
+
+
+**A.PROPER_USER**
+
+Mobile Device users are not willfully negligent or hostile, and use the device within compliance of a
+reasonable Enterprise security policy.
+
+
+**3.3 Organizational Security Policies**
+
+
+This document does not define any additional OSPs.
+
+
+# **4 Security Objectives**
+
+**4.1 Security Objectives for the TOE**
+
+
+**O.PROTECTED_COMMS**
+
+To address the network eavesdropping (T.NETWORK_EAVESDROP) and network attack
+(T.NETWORK_ATTACK) threats described in Section 3.1 Threats, concerning wireless transmission of
+Enterprise and user data and configuration data between the TOE and remote network entities,
+conformant TOEs will use a trusted communication path. The TOE must be capable of communicating
+using mutually authenticated TLS, EAP-TLS, HTTPS, 802.1X, and 802.11-2012. The TOE may optionally
+communicate using these standard protocols: IPsec, mutually-authenticated DTLS, or Bluetooth. These
+protocols are specified by RFCs that offer a variety of implementation choices. Requirements have been
+imposed on some of these choices (particularly those for cryptographic primitives) to provide
+interoperability and resistance to cryptographic attack.
+
+
+While conformant TOEs must support all of the choices specified in the ST including any optional SFRs
+defined in this PP, they may support additional algorithms and protocols. If such additional mechanisms
+are not evaluated, guidance must be given to the administrator to make clear the fact that they were not
+evaluated.
+
+
+**O.STORAGE**
+
+To address the issue of loss of confidentiality of user data in the event of loss of a Mobile Device
+(T.PHYSICAL_ACCESS), conformant TOEs will use data-at-rest protection. The TOE will be capable of
+encrypting data and keys stored on the device and will prevent unauthorized access to encrypted data.
+
+
+**O.CONFIG**
+
+To ensure a Mobile Device protects user and enterprise data that it may store or process, conformant
+TOEs will provide the capability to configure and apply security policies defined by the user and the
+Enterprise Administrator. If Enterprise security policies are configured these must be applied in
+precedence of user specified security policies.
+
+
+**O.AUTH**
+
+To address the issue of loss of confidentiality of user data in the event of loss of a Mobile Device
+(T.PHYSICAL_ACCESS), users are required to enter an authentication factor to the device prior to
+accessing protected functionality and data. Some non-sensitive functionality (e.g., emergency calling,
+text notification) can be accessed prior to entering the authentication factor. The device will
+automatically lock following a configured period of inactivity in an attempt to ensure authorization will
+be required in the event of the device being lost or stolen.
+
+
+Authentication of the endpoints of a trusted communication path is required for network access to
+ensure attacks are unable to establish unauthorized network connections to undermine the integrity of
+the device.
+
+
+Repeated attempts by a user to authorize to the TSF will be limited or throttled to enforce a delay
+between unsuccessful attempts.
+
+
+**O.INTEGRITY**
+
+To ensure the integrity of the Mobile Device is maintained conformant TOEs will perform self-tests to
+ensure the integrity of critical functionality, software/firmware and data has been maintained. The user
+shall be notified of any failure of these self-tests. This will protect against the threat T.PERSISTENT.
+
+
+To address the issue of an application containing malicious or flawed code (T.MALICIOUS_APP), the
+integrity of downloaded updates to software/firmware will be verified prior to installation/execution of
+the object on the Mobile Device. In addition, the TOE will restrict applications to only have access to the
+system services and data they are permitted to interact with. The TOE will further protect against
+malicious applications from gaining access to data they are not authorized to access by randomizing the
+memory layout.
+
+
+**O.PRIVACY**
+
+In a BYOD environment (use cases 3 and 4), a personally-owned mobile device is used for both personal
+activities and enterprise data. Enterprise management solutions may have the technical capability to
+monitor and enforce security policies on the device. However, the privacy of the personal activities and
+data must be ensured. In addition, since there are limited controls that the enterprise can enforce on the
+personal side, separation of personal and enterprise data is needed. This will protect against the
+T.MALICIOUS_APP and T.PERSISTENT_PRESENCE threats.
+
+
+**4.2 Security Objectives for the Operational Environment**
+
+
+The following security objectives for the operational environment assist the OS in correctly providing its
+security functionality. These track with the assumptions about the environment.
+
+
+**OE.CONFIG**
+
+TOE administrators will configure the Mobile Device security functions correctly to create the intended
+security policy
+
+
+**OE.NOTIFY**
+
+The Mobile User will immediately notify the administrator if the Mobile Device is lost or stolen.
+
+
+**OE.PRECAUTION**
+
+The mobile device user exercises precautions to reduce the risk of loss or theft of the Mobile Device.
+
+
+**OE.DATA_PROPER_USER**
+
+Administrators take measures to ensure that mobile device users are adequately vetted against malicious
+intent and are made aware of the expectations for appropriate use of the device.
+
+
+**4.3 Security Objectives Rationale**
+
+
+This section describes how the assumptions, threats, and organizational security policies map to the security
+objectives.
+
+
+**Table 1: Security Objectives Rationale**
+
+
+
+**Threat,**
+**Assumption,**
+**or OSP**
+
+
+
+**Security**
+**Objectives**
+
+
+
+
+
+**Rationale**
+
+
+
+
+
+
+
+
+
+
+
+
+
+|T.NETWORK_โ
EAVESDROP|O.PROTECTED_โ The threat T.NETWORK_EAVESDROP is countered by
COMMS O.PROTECTED_COMMS as this provides the capability to
communicate using one (or more) standard protocols as a means to
maintain the confidentiality of data that are transmitted outside of
the TOE.
O.CONFIG The threat T.NETWORK_EAVESDROP is countered by O.CONFIG as
this provides a secure configuration of the mobile device to protect
data that it processes.
O.AUTH The threat T.NETWORK_EAVESDROP is countered by O.AUTH as
this provides authentication of the endpoints of a trusted
communication path.|
+|---|---|
+|T.NETWORK_
ATTACK|O.PROTECTED_
COMMS
The threatT.NETWORK_ATTACK is countered by
O.PROTECTED_COMMS as this provides the capability to
communicate using one (or more) standard protocols as a means to
maintain the confidentiality of data that are transmitted outside of
the TOE.
O.CONFIG
The threatT.NETWORK_ATTACK is countered byO.CONFIG as this
provides a secure configuration of the mobile device to protect data
that it processes.
O.AUTH
The threatT.NETWORK_ATTACK is countered byO.AUTH as this
provides authentication of the endpoints of a trusted communication
path.|
+|T.PHYSICAL_
ACCESS|O.STORAGE
The threatT.PHYSICAL_ACCESS is countered byO.STORAGE as this
provides the capability to encrypt all user and enterprise data and
authentication keys to ensure the confidentiality of data that it stores.
O.AUTH
The threatT.PHYSICAL_ACCESS is countered byO.AUTH as this
provides the capability to authenticate the user prior to accessing
protected functionality and data.|
+|T.MALICIOUS_
APP|O.PROTECTED_
COMMS
The threatT.MALICIOUS_APP is countered by
O.PROTECTED_COMMS as this provides the capability to
communicate using one (or more) standard protocols as a means to
maintain the confidentiality of data that are transmitted outside of
the TOE.
O.CONFIG
The threatT.MALICIOUS_APP is countered byO.CONFIG as this
provides the capability to configure and apply security policies to
ensure the Mobile Device can protect user and enterprise data that it
may store or process.
O.AUTH
The threatT.MALICIOUS_APP is countered byO.AUTH as this
provides the capability to authenticate the user and endpoints of a
trusted path to ensure they are communicating with an authorized
entity with appropriate privileges.
O.INTEGRITY
The threatT.MALICIOUS_APP is countered byO.INTEGRITY as this
provides the capability to perform self-tests to ensure the integrity of
critical functionality, software/firmware and data has been
maintained.
O.PRIVACY
The threatT.MALICIOUS_APP is countered byO.PRIVACY as this
provides separation and privacy between user activities.|
+
+
+T.PERSISTENT_โ O.INTEGRITY The threat T.PERSISTENT_PRESENCE is countered by O.INTEGRITY
+
+
+|PRESENCE|as this provides the capability to perform self-tests to ensure the
integrity of critical functionality, software/firmware and data has
been maintained.
O.PRIVACY The threat T.PERSISTENT_PRESENCE is countered by O.PRIVACY
as this provides separation and privacy between user activities.|
+|---|---|
+|A.CONFIG|OE.CONFIG
The operational environment objectiveOE.CONFIG is realized
throughA.CONFIG.|
+|A.NOTIFY|OE.NOTIFY
The operational environment objectiveOE.NOTIFY is realized
throughA.NOTIFY.|
+|A.PRECAUTION|OE.PRECAUTION
The operational environment objectiveOE.PRECAUTION is realized
throughA.PRECAUTION.|
+|A.PROPER_
USER|OE.DATA_
PROPER_USER
The operational environment objectiveOE.DATA_PROPER_USER is
realized throughA.PROPER_USER.|
+
+
+# **5 Security Requirements**
+
+This chapter describes the security requirements which have to be fulfilled by the product under evaluation.
+Those requirements comprise functional components from Part 2 and assurance components from Part 3 of
+
+[CC]. The following conventions are used for the completion of operations:
+
+**Refinement** operation (denoted by **bold text** or ~~strikethrough text)~~ : Is used to add details to a
+requirement (including replacing an assignment with a more restrictive selection) or to remove part of
+the requirement that is made irrelevant through the completion of another operation, and thus further
+restricts a requirement.
+**Selection** (denoted by _italicized text_ ): Is used to select one or more options provided by the [CC] in
+stating a requirement.
+**Assignment** operation (denoted by _italicized text_ ): Is used to assign a specific value to an unspecified
+parameter, such as the length of a password. Showing the value in square brackets indicates assignment.
+**Iteration** operation: Is indicated by appending the SFR name with a slash and unique identifier
+suggesting the purpose of the operation, e.g. "/EXAMPLE1."
+
+
+**5.1 Security Functional Requirements**
+
+
+**5.1.1 Auditable Events for Mandatory SFRs**
+
+
+**Table 2: Auditable Events for Mandatory Requirements**
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+|Requirement|Auditable Events|Additional Audit Record Contents|
+|---|---|---|
+|FAU_GEN.1|No events specified|N/A|
+|FAU_SAR.1|No events specified|N/A|
+|FAU_STG.1|No events specified|N/A|
+|FAU_STG.4|No events specified|N/A|
+|FCS_CKM.1|[**selection, choose one of**:
_Failure of key generation activity_
_for authentication keys_, _None_ ]|No additional information|
+|FCS_CKM.2/UNLOCKED|No events specified|N/A|
+|FCS_CKM.2/LOCKED|No events specified|N/A|
+|FCS_CKM_EXT.1|[**selection, choose one of**:
_generation of a REK_, _none_ ]|No additional information|
+|FCS_CKM_EXT.2|No events specified|N/A|
+|FCS_CKM_EXT.3|No events specified|N/A|
+|FCS_CKM_EXT.4|No events specified|N/A|
+|FCS_CKM_EXT.5|[**selection, choose one of**:
_Failure of the wipe_, _none_ ]|No additional information|
+|FCS_CKM_EXT.6|No events specified|N/A|
+|FCS_COP.1/ENCRYPT|No events specified|N/A|
+|FCS_COP.1/HASH|No events specified|N/A|
+|FCS_COP.1/SIGN|No events specified|N/A|
+|FCS_COP.1/KEYHMAC|No events specified|N/A|
+|FCS_COP.1/CONDITION|No events specified|N/A|
+|FCS_IV_EXT.1|No events specified|N/A|
+|FCS_SRV_EXT.1|No events specified|N/A|
+|FCS_STG_EXT.1|Import or destruction of key|Identity of key, role and identity of
requester|
+|FCS_STG_EXT.1|[**selection, choose one of**:
_Exceptions to use and destruction_
_rules_, _none_ ]|Identity of key, role and identity of
requester|
+|FCS_STG_EXT.2|No events specified|N/A|
+|FCS_STG_EXT.2|||
+
+
+|FCS_STG_EXT.3|Col2|Col3|
+|---|---|---|
+|FCS_STG_EXT.3|Failure to verify integrity of
stored key|Identity of key being verified|
+|FDP_ACF_EXT.1|No events specified|N/A|
+|FDP_DAR_EXT.1|[**selection, choose one of**:
_Failure to encrypt/decrypt data_,
_none_ ]|No additional information|
+|FDP_DAR_EXT.2|[**selection, choose one of**:
_Failure to encrypt/decrypt data_,
_none_ ]|No additional information|
+|FDP_IFC_EXT.1|No events specified|N/A|
+|FDP_STG_EXT.1|Addition or removal of certificate
from Trust Anchor Database|Subject name of certificate.|
+|FIA_PMG_EXT.1|No events specified|N/A|
+|FIA_TRT_EXT.1|No events specified|N/A|
+|FIA_UAU.5|No events specified|N/A|
+|FIA_UAU.7|No events specified|N/A|
+|FIA_UAU_EXT.1|No events specified|N/A|
+|FIA_X509_EXT.1|Failure to validate X.509v3
certificate|Reason for failure of validation|
+|FIA_X509_EXT.2|No events specified|N/A|
+|FMT_MOF_EXT.1|No events specified|N/A|
+|FPT_AEX_EXT.1|No events specified|N/A|
+|FPT_AEX_EXT.2|No events specified|N/A|
+|FPT_AEX_EXT.3|No events specified|N/A|
+|FPT_JTA_EXT.1|No events specified|N/A|
+|FPT_KST_EXT.1|No events specified|N/A|
+|FPT_KST_EXT.2|No events specified|N/A|
+|FPT_KST_EXT.3|No events specified|N/A|
+|FPT_NOT_EXT.1|[**selection, choose one of**:
_Measurement of TSF software_,
_none_ ]|[**selection, choose one of**: _Integrity_
_verification value_, _No additional_
_information_ ]|
+|FPT_STM.1|No events specified|N/A|
+|FPT_TST_EXT.1|Initiation of self-test|No additional information|
+|FPT_TST_EXT.1|Failure of self-test|[**selection, choose one of**: _Algorithm_
_that caused the failure_, _No additional_
_information_ ]|
+|FPT_TST_EXT.2/PREKERNEL|Start-up of TOE|No additional information|
+|FPT_TST_EXT.2/PREKERNEL|[**selection, choose one of**:
_Detected integrity violation_, _none_
]|[**selection, choose one of**: _The TSF_
_code file that caused the integrity_
_violation_, _No additional information_ ]|
+|FPT_TUD_EXT.1|No events specified|N/A|
+|FTA_SSL_EXT.1|No events specified|N/A|
+|FTA_TAB.1|No events specified|N/A|
+
+
+**Table 3: Additional Audit Events**
+
+
+**Requirement** **Auditable Events** **Additional Audit Record Contents**
+
+
+
+FAU_SEL.1 All modifications to the
+audit configuration that
+occur while the audit
+collection functions are
+
+
+
+No additional information
+
+
+|Col1|operating|Col3|
+|---|---|---|
+|FCS_CKM_EXT.7|No events specified|N/A|
+||||
+|FCS_HTTPS_EXT.1|Failure of the certificate
validity check.|Issuer Name and Subject Name of
certificate
[**selection, choose one of**: _Userโs_
_authorization decision_, _No additional_
_information_ ]|
+|FCS_RBG_EXT.1|Failure of the
randomization process|No additional information|
+|FCS_RBG_EXT.2|No events specified|N/A|
+|FCS_RBG_EXT.3|No events specified|N/A|
+|FCS_SRV_EXT.2|No events specified|N/A|
+|FDP_ACF_EXT.1|No events specified|N/A|
+|FDP_ACF_EXT.2|No events specified|N/A|
+|FDP_ACF_EXT.3|No events specified|N/A|
+|FDP_BCK_EXT.1|No events specified|N/A|
+|FDP_UPC_EXT.1/APPS|Application initiation of
trusted channel|Name of application. Trusted channel
protocol. Non-TOE endpoint of connection|
+|FDP_UPC_EXT.1/BLUETOOTH|Application initiation of
trusted channel|Name of application. Trusted channel
protocol. Non-TOE endpoint of connection|
+|FIA_AFL_EXT.1|Excess of authentication
failure limit|Authentication factor used|
+|FIA_UAU.6/LOCKED|User changes Password
Authentication Factor|No additional information|
+|FIA_UAU_EXT.2|Action performed before
authentication.|No additional information|
+|FIA_UAU_EXT.4|No events specified|N/A|
+|FIA_X509_EXT.2|Failure to establish
connection to determine
revocation status|No additional information|
+|FIA_X509_EXT.3|No events specified|N/A|
+|FIA_X509_EXT.4|Generation of Certificate
Enrollment Request|Issuer and Subject name of EST Server.
Method of authentication. Issuer and Subject
name of certificate used to authenticate.
Content of Certificate Request Message|
+|FIA_X509_EXT.4|Success or failure of
enrollment|Issuer and Subject name of added certificate
or reason for failure|
+|FIA_X509_EXT.4|Update of EST Trust
Anchor Database|Subject name of added Root CA|
+|FIA_X509_EXT.5|No events specified|N/A|
+|FMT_SMF.1|Initiation of policy update|Policy name|
+|FMT_SMF.1|Change of settings|Role of user that changed setting, Value of
new setting|
+|FMT_SMF.1|Success or failure of
function|Role of user that performed function,
Function performed, Reason for failure|
+|FMT_SMF.1|Initiation of software
update|Version of update|
+|FMT_SMF.1|Initiation of application
installation or update|Name and version of application|
+|FMT_SMF_EXT.2|Unenrollment, Initiation of
unenrollment|Identity of administrator Remediation action
performed, failure of accepting command to
unenroll|
+
+
+|FMT_SMF_EXT.3|No events specified|N/A|
+|---|---|---|
+|FPT_AEX_EXT.4|No events specified|N/A|
+|FPT_AEX_EXT.5|No events specified|N/A|
+|FPT_AEX_EXT.6|No events specified|N/A|
+|FPT_AEX_EXT.7|No events specified|N/A|
+|FPT_BBD_EXT.1|No events specified|N/A|
+|FPT_BLT_EXT.1|No events specified|N/A|
+|FPT_NOT_EXT.2|No events specified|N/A|
+|FPT_TST_EXT.2/POSTKERNEL|[**selection, choose one**
**of**: _Detected integrity_
_violation_, _None_ ]|[**selection, choose one of**: _The TSF code_
_file that cause the integrity violation_, _No_
_additional information_ ]|
+|FPT_TST_EXT.3|No events specified|N/A|
+|FPT_TUD_EXT.2|Success or failure of
signature verification for
software updates|No additional information|
+|FPT_TUD_EXT.3|Success or failure of
signature verification for
applications|No additional information|
+|FPT_TUD_EXT.4|No events specified|N/A|
+|FPT_TUD_EXT.5|No events specified|N/A|
+|FPT_TUD_EXT.6|No events specified|N/A|
+|FTP_ITC_EXT.1|Initiation and termination
of trusted channel|Trusted channel protocol, non-TOE endpoint
of connection|
+
+
+**5.1.2 Class: Security Audit (FAU)**
+
+
+**FAU_GEN.1 Audit Data Generation**
+
+
+FAU_GEN.1.1
+
+
+
+
+
+The TSF shall be able to generate an audit record of the following auditable
+events:
+
+
+1. Start-up and shutdown of the audit functions
+2. All auditable events for the [ **not selected** ] level of audit
+3. **All administrative actions**
+4. **Start-up and shutdown of the OS**
+5. **Insertion or removal of removable media**
+6. **Specifically defined auditable events in Table 2**
+7. **[selection:** _**Audit records reaching [assignment: integer value less**_
+
+_**than 100] percentage of audit capacity**_ **,** _**Specifically defined**_
+_**auditable events in Table 3**_ **,** _**[assignment: other auditable events**_
+_**derived from this Protection Profile]**_ **,** _**no additional auditable events**_
+**]**
+
+
+**Application Note:** Administrator actions are defined as functions labeled as
+mandatory for FMT_MOF_EXT.1.2 (i.e. โM-MMโ in Table 7). If the TSF does not
+support removable media, number 4 is implicitly met.
+
+
+The TSF must generate an audit record for all events contained in Table 2.
+Generating audit records for events in Table 3 is currently objective. It is
+acceptable to include individual SFRs from Table 3 in the ST, without including
+the entirety of Table 3.
+
+
+**Table 2 Application Note:**
+FPT_TST_EXT.1 โ Audit of self-tests is required only at initial start-up. Since the
+TOE "transitions to non-operational mode" upon failure of a self-test, per
+FPT_NOT_EXT.1, this is considered equivalent evidence to an audit record for
+the failure of a self-test.
+
+
+FDP_DAR_EXT.1 - "None" must be selected, if the TOE utilizes whole volume
+encryption for protected data, since it is not feasible to audit when the
+
+
+FAU_GEN.1.2
+
+
+
+encryption/decryption fails. If the TOE utilizes file-based encryption for
+protected data and audits when this encryption/decryption fails, then that
+auditable event should be selected.
+
+
+**Table 3 Application Note:**
+If the audit event for FMT_SMF.1 is included in the ST, it is acceptable for the
+initiation of the software update to be audited without indicating the outcome
+(success or failure) of the update.
+
+
+Validation Guidelines:
+
+
+**Rule #1**
+
+
+The TSF shall record within each audit record at least the following information:
+
+
+1. Date and time of the event
+2. Type of event
+3. Subject identity
+4. The outcome (success or failure) of the event
+**5. Additional information in Table 2**
+**6. [selection:** _**Additional information in Table 3**_ **,** _**no additional**_
+
+_**information**_ **]**
+
+
+**Application Note:** The subject identity is usually the process name/ID. The
+event type is often indicated by a severity level, for example, โinfoโ, โwarningโ, or
+โerrorโ.
+
+
+If no additional auditable events is selected in the second selection of
+FAU_GEN.1.1, then no additional information must be selected.
+
+
+For each audit event selected from Table 3 in FAU_GEN.1.1 if additional
+information is required to be recorded within the audit record, it should be
+included in this selection.
+
+
+Validation Guidelines:
+
+
+**Rule #1**
+
+
+
+**Evaluation Activities**
+
+
+**FAU_SAR.1 Audit Review**
+
+
+FAU_SAR.1.1
+
+The TSF shall provide [ _the administrator_ ] with the capability to read [ _all audited_
+_events and record contents_ ] from the audit records.
+
+
+**Application Note:** The administrator must have access to read the audit record,
+perhaps through an API or via an MDM Agent, which transfers the local records
+stored on the TOE to the MDM Server where the enterprise administrator may
+view them. If this requirement is included in the ST, function 32 must be
+included in the selection of FMT_SMF.1.
+
+
+FAU_SAR.1.2
+
+The TSF shall provide the audit records in a manner suitable for the user to
+interpret the information.
+
+
+**Evaluation Activities**
+
+
+
+
+
+**FAU_STG.1 Audit Storage Protection**
+
+
+FAU_STG.1.1
+
+The TSF shall protect the stored audit records in the audit trail from
+unauthorized deletion.
+
+
+FAU_STG.1.2
+
+The TSF shall be able to [ _prevent_ ] unauthorized modifications to the stored audit
+records in the audit trail.
+
+
+**Evaluation Activities**
+
+
+
+
+
+**FAU_STG.4 Prevention of Audit Data Loss**
+
+
+FAU_STG.4.1
+
+The TSF shall [ _overwrite the oldest stored audit records_ ] ~~and [assignment: other~~
+~~actions to be taken in case of audit storage failure]~~ if the audit trail is full.
+
+
+**Evaluation Activities**
+
+
+_FAU_STG.4_
+_**TSS**_
+_The evaluator shall examine the TSS to ensure that it describes the size limits on the audit_
+_records, the detection of a full audit trail, and the actions taken by the TSF when the audit trail_
+_is full. The evaluator shall ensure that the actions results in the deletion or overwrite of the_
+_oldest stored record._
+
+
+_**Guidance**_
+_There are no guidance evaluation activities for this component._
+
+
+_**Tests**_
+_There are no test evaluation activities for this component._
+
+
+**5.1.3 Class: Cryptographic Support (FCS)**
+This section describes how keys are generated, derived, combined, released and destroyed. There are two
+major types of keys: DEKs and KEKs. (A REK is considered a KEK.) DEKs are used to protect data (as in the
+DAR protection described in FDP_DAR_EXT.1 and FDP_DAR_EXT.2). KEKs are used to protect other keys โ
+DEKs, other KEKs, and other types of keys stored by the user or applications. The following diagram shows an
+example key hierarchy to illustrate the concepts of this profile. This example is not meant as an approved
+design, but ST authors will be expected to provide a diagram illustrating their key hierarchy in order to
+demonstrate that they meet the requirements of this profile. Please note if biometric in accordance with the
+[Biometric Enrollment and Verification, version 1.1 is selected in FIA_UAU.5.1, each BAF claimed in](https://github.com/biometricITC/cPP-biometrics/blob/master/Protection%20Profile/BiocPP.adoc)
+[FIA_MBV_EXT.1.1 in the Biometric Enrollment and Verification, version 1.1 shall be illustrated in the key](https://github.com/biometricITC/cPP-biometrics/blob/master/Protection%20Profile/BiocPP.adoc)
+hierarchy diagram, to include a description of when and how the BAF is used to release keys. If hybrid is
+selected in FIA_UAU.5.1, meaning that a PIN or password must be used in conjunction with the BAF, this
+interaction shall be included.
+
+
+**Figure 3: An Illustrative Key Hierarchy**
+
+
+**FCS_CKM.1 Cryptographic Key Generation**
+
+
+FCS_CKM.1.1
+
+The TSF shall generate **asymmetric** cryptographic keys in accordance with a
+specified cryptographic key generation algorithm [ **selection** :
+
+_**RSA schemes using**_ _cryptographic key sizes of [_ _**assignment**_ _: 2048-bit or_
+_greater] that meet [FIPS PUB 186-4, "Digital Signature Standard (DSS)",_
+_Appendix B.3]_
+_**ECC schemes using:**_ _[_ _**selection**_ _:_
+
+_**"NIST curves" P-384 and**_ _[_ _**selection**_ _:_ _**P-256**_ _,_ _**P-521**_ _,_ _**no other**_
+_**curves**_ _] that meet the following: [FIPS PUB 186-4, "Digital Signature_
+_Standard (DSS)", Appendix B.4]_
+_**Curve25519 schemes**_ _that meet the following: [RFC 7748]_
+
+_]_
+_**FFC schemes using:**_ _[_ _**selection**_ _:_
+
+_cryptographic key sizes of_ _**2048-bit or greater**_ _that meet the_
+_following [FIPS PUB 186-4, "Digital Signature Standard (DSS)",_
+_Appendix B.1]_
+_**"safe-prime" groups**_ _that meet the following: [NIST Special_
+_Publication 800-56A Revision 3, "Recommendation for Pair-Wise Key_
+_Establishment Schemes Using Discrete Logarithm Cryptography"]_
+
+_]_
+
+].
+
+
+**Application Note:** The ST author must select all key generation schemes used
+for key establishment and entity authentication. When key generation is used for
+
+
+key establishment, the schemes in FCS_CKM.2/UNLOCKED and selected
+cryptographic protocols must match the selection. When key generation is used
+for entity authentication, the public key may be associated with an X.509v3
+certificate.
+
+
+If the TOE acts as a receiver in the RSA key establishment scheme, the TOE does
+not need to implement RSA key generation.
+
+
+Curve25519 can only be used for ECDH and in conjunction with
+FDP_DAR_EXT.2.2.
+
+
+**Evaluation Activities**
+
+
+_FCS_CKM.1_
+_**TSS**_
+_The evaluator shall ensure that the TSS identifies the key sizes supported by the TOE. If the ST_
+_specifies more than one scheme, the evaluator shall examine the TSS to verify that it identifies_
+_the usage for each scheme._
+
+
+_**Guidance**_
+_The evaluator shall verify that the AGD guidance instructs the administrator how to configure_
+_the TOE to use the selected key generation schemes and key sizes for all uses defined in this PP._
+
+
+_**Tests**_
+_**Evaluation Activity Note:**_ _The following tests require the developer to provide access to a test_
+_platform that provides the evaluator with tools that are typically not found on factory products._
+
+
+_**Key Generation for FIPS PUB 186-4 RSA Schemes**_
+
+
+_The evaluator shall verify the implementation of RSA Key Generation by the TOE using the Key_
+_Generation test. This test verifies the ability of the TSF to correctly produce values for the key_
+_components including the public verification exponent e, the private prime factors p and q, the_
+_public modulus n and the calculation of the private signature exponent d._
+
+
+_Key Pair generation specifies 5 ways (or methods) to generate the primes p and q. These_
+_include:_
+
+
+_1. Random Primes:_
+
+_Provable primes_
+_Probable primes_
+
+_2. Primes with Conditions:_
+
+_Primes p1, p2, q1,q2, p and q shall all be provable primes_
+_Primes p1, p2, q1, and q2 shall be provable primes and p and q shall be probable_
+_primes_
+_Primes p1, p2, q1,q2, p and q shall all be probable primes_
+
+
+_To test the key generation method for the Random Provable primes method and for all the_
+_Primes with Conditions methods, the evaluator must seed the TSF key generation routine with_
+_sufficient data to deterministically generate the RSA key pair. This includes the random seeds,_
+_the public exponent of the RSA key, and the desired key length. For each key length supported,_
+_the evaluator shall have the TSF generate 25 key pairs. The evaluator shall verify the_
+_correctness of the TSFโs implementation by comparing values generated by the TSF with those_
+_generated from a known good implementation._
+
+
+_If possible, the Random Probable primes method should also be verified against a known good_
+_implementation as described above. Otherwise, the evaluator shall have the TSF generate 10_
+_keys pairs for each supported key length nlen and verify:_
+
+_n = p*q_
+_p and q are probably prime according to Miller-Rabin tests_
+_GCD(p-1,e) = 1_
+_GCD(q-1,e) = 1_
+_2^16 < e < 2^256 and e is an odd integer_
+_|p-q| > 2^(nlen/2 โ 100)_
+_p >= squareroot(2)*( 2^(nlen/2 -1) )_
+_q >= squareroot(2)*( 2^(nlen/2 -1) )_
+_2^(nlen/2) < d < LCM(p-1,q-1)_
+_e*d = 1 mod LCM(p-1,q-1)_
+
+
+_**Key Generation for FIPS 186-4 Elliptic Curve Cryptography (ECC)**_
+_FIPS 186-4 ECC Key Generation Test_
+
+
+_For each supported NIST curve, i.e. P-256, P-384 and P-521, the evaluator shall require the_
+_implementation under test (IUT) to generate 10 private/public key pairs. The private key shall be_
+_generated using an approved random bit generator (RBG). To determine correctness, the_
+
+
+_evaluator shall submit the generated key pairs to the public key verification (PKV) function of a_
+_known good implementation._
+
+
+_FIPS 186-4 Public Key Verification (PKV) Test_
+
+
+_For each supported NIST curve, i.e. P-256, P-384 and P-521, the evaluator shall generate 10_
+_private/public key pairs using the key generation function of a known good implementation and_
+_modify five of the public key values so that they are incorrect, leaving five values unchanged (i.e._
+_correct). The evaluator shall obtain in response a set of 10 PASS/FAIL values._
+
+
+_**Key Generation for Curve25519**_
+_The evaluator shall require the implementation under test (IUT) to generate 10 private/public_
+_key pairs. The private key shall be generated as specified in RFC 7748 using an approved_
+_random bit generator (RBG) and shall be written in little-endian order (least significant byte_
+_first). To determine correctness, the evaluator shall submit the generated key pairs to the public_
+_key verification (PKV) function of a known good implementation._
+
+
+_Note: Assuming the PKV function of the good implementation will (using little-endian order):_
+
+
+_a. Confirm the private and public keys are 32-byte values_
+_b. Confirm the three least significant bits of the first byte of the private key are zero_
+
+_c. Confirm the most significant bit of the last byte is zero_
+_d. Confirm the second most significant bit of the last byte is one_
+_e. Calculate the expected public key from the private key and confirm it matches the supplied_
+
+_public key_
+
+
+_The evaluator shall generate 10 private/public key pairs using the key generation function of a_
+_known good implementation and modify 5 of the public key values so that they are incorrect,_
+_leaving five values unchanged (i.e. correct). The evaluator shall obtain in response a set of 10_
+_PASS/FAIL values._
+
+
+_**Key Generation for Finite-Field Cryptography (FFC)**_
+_The evaluator shall verify the implementation of the Parameters Generation and the Key_
+_Generation for FFC by the TOE using the Parameter Generation and Key Generation test. This_
+_test verifies the ability of the TSF to correctly produce values for the field prime p, the_
+_cryptographic prime q (dividing p-1), the cryptographic group generator g, and the calculation of_
+_the private key x and public key y._
+_The Parameter generation specifies 2 ways (or methods) to generate the cryptographic prime q_
+_and the field prime p:_
+
+
+_Cryptographic and Field Primes:_
+
+
+_Primes q and p shall both be provable primes_
+_Primes q and field prime p shall both be probable primes_
+
+_and two ways to generate the cryptographic group generator g:_
+
+
+_Cryptographic Group Generator:_
+
+
+_Generator g constructed through a verifiable process_
+_Generator g constructed through an unverifiable process_
+
+_The Key generation specifies 2 ways to generate the private key x:_
+
+
+_Private Key:_
+
+
+_len(q) bit output of RBG where 1 <= x <= q-1_
+_len(q) + 64 bit output of RBG, followed by a mod q-1 operation where 1<= x<=q-1_
+
+_The security strength of the RBG must be at least that of the security offered by the FFC_
+_parameter set._
+
+
+_To test the cryptographic and field prime generation method for the provable primes method or_
+_the group generator g for a verifiable process, the evaluator must seed the TSF parameter_
+_generation routine with sufficient data to deterministically generate the parameter set._
+
+
+_For each key length supported, the evaluator shall have the TSF generate 25 parameter sets and_
+_key pairs. The evaluator shall verify the correctness of the TSFโs implementation by comparing_
+_values generated by the TSF with those generated from a known good implementation._
+_Verification must also confirm_
+
+_g != 0,1_
+_q divides p-1_
+_g^q mod p = 1_
+_g^x mod p = y_
+
+
+_for each FFC parameter set and key pair._
+
+
+**FCS_CKM.2/UNLOCKED Cryptographic Key Establishment**
+
+
+FCS_CKM.2.1/UNLOCKED
+
+The TSF shall **perform** cryptographic **key establishment** in accordance with a
+specified cryptographic key **establishment** method [ **selection** :
+
+_[RSA-based key establishment schemes] that meet the following [_ _**selection**_ _:_
+
+_NIST Special Publication 800-56B, โRecommendation for Pair-Wise Key_
+_Establishment Schemes Using Integer Factorization Cryptographyโ_
+_RSAES-PKCS1-v1_5 as specified in Section 7.2 of RFC 8017, "Public-_
+_Key Cryptography Standards (PKCS) #1:RSA Cryptography_
+_Specifications Version 2.2"_
+
+_]_
+
+_[Elliptic curve-based key establishment schemes] that meet the following:_
+
+_[NIST Special Publication 800-56A Revision 3, "Recommendation for Pair-_
+_Wise Key Establishment Schemes Using Discrete Logarithm Cryptography"]_
+
+_[Finite field-based key establishment schemes] that meet the following:_
+
+_[NIST Special Publication 800-56A Revision 3, "Recommendation for Pair-_
+_Wise Key Establishment Schemes Using Discrete Logarithm Cryptography"]_
+
+].
+
+
+**Application Note:** The ST author must select all key establishment schemes
+used for the selected cryptographic protocols and any RSA-based key
+establishment schemes that may be used to satisfy FDP_DAR or FCS_STG. Also,
+FCS_TLSC_EXT.1 requires ciphersuites that use RSA-based key establishment
+schemes.
+
+
+The RSA-based key establishment schemes are described in Section 9 of NIST
+SP 800-56B; however, Section 9 relies on implementation of other sections in SP
+800-56B. If the TOE only acts as a receiver in the RSA key establishment
+scheme, the TOE does not need to implement RSA key generation.
+
+
+The elliptic curves used for the key establishment scheme must correlate with
+the curves specified in FCS_CKM.1.1.
+
+
+The domain parameters used for the finite field-based key establishment scheme
+are specified by the key generation according to FCS_CKM.1.1. The finite fieldbased key establishment schemes that conform to NIST SP 800-56A Revision 3
+correspond to the "safe-prime" groups selection in FCS_CKM.1.1.
+
+
+**Evaluation Activities**
+
+
+_FCS_CKM.2/UNLOCKED_
+_**TSS**_
+_The evaluator shall ensure that the supported key establishment schemes correspond to the key_
+_generation schemes identified in FCS_CKM.1.1. If the ST specifies more than one scheme, the_
+_evaluator shall examine the TSS to verify that it identifies the usage for each scheme._
+
+
+_**Guidance**_
+_The evaluator shall verify that the AGD guidance instructs the administrator how to configure_
+_the TOE to use the selected key establishment schemes._
+
+
+_**Tests**_
+_**Evaluation Activity Note:**_ _The following tests require the developer to provide access to a test_
+_platform that provides the evaluator with tools that are typically not found on factory products._
+
+
+_The evaluator shall verify the implementation of the key establishment schemes supported by_
+_the TOE using the applicable tests below._
+
+
+_**SP800-56A Revision 3 Key Establishment Schemes**_
+
+_The evaluator shall verify a TOE's implementation of SP800-56A Revision 3 key establishment_
+_schemes using the following Function and Validity tests. These validation tests for each key_
+_agreement scheme verify that a TOE has implemented the components of the key agreement_
+_scheme according to the specifications in the Recommendation. These components include the_
+_calculation of the DLC primitives (the shared secret value Z) and the calculation of the derived_
+_keying material (DKM) via the Key Derivation Function (KDF). If key confirmation is supported,_
+_the evaluator shall also verify that the components of key confirmation have been implemented_
+_correctly, using the test procedures described below. This includes the parsing of the DKM, the_
+_generation of MACdata and the calculation of MacTag._
+
+
+_**Function Test**_
+
+
+_The Function test verifies the ability of the TOE to implement the key agreement schemes_
+
+
+_correctly. To conduct this test the evaluator shall generate or obtain test vectors from a known_
+_good implementation of the TOE supported schemes. For each supported key agreement_
+_scheme-key agreement role combination, KDF type, and, if supported, key confirmation role- key_
+_confirmation type combination, the tester shall generate 10 sets of test vectors. The data set_
+_consists of one set of domain parameter values (FFC) or the NIST approved curve (ECC) per 10_
+_sets of public keys. These keys are static, ephemeral or both depending on the scheme being_
+_tested._
+
+
+_The evaluator shall obtain the DKM, the corresponding TOEโs public keys (static or ephemeral),_
+_the MAC tags, and any inputs used in the KDF, such as the Other Information field OI and TOE_
+_id fields._
+
+
+_If the TOE does not use a KDF defined in SP 800-56A Revision 3, the evaluator shall obtain only_
+_the public keys and the hashed value of the shared secret._
+
+
+_The evaluator shall verify the correctness of the TSFโs implementation of a given scheme by_
+_using a known good implementation to calculate the shared secret value, derive the keying_
+_material DKM, and compare hashes or MAC tags generated from these values._
+
+
+_If key confirmation is supported, the TSF shall perform the above for each implemented_
+_approved MAC algorithm._
+
+
+_**Validity Test**_
+
+
+_The Validity test verifies the ability of the TOE to recognize another partyโs valid and invalid key_
+_agreement results with or without key confirmation. To conduct this test, the evaluator shall_
+_obtain a list of the supporting cryptographic functions included in the SP800-56A Revision 3 key_
+_agreement implementation to determine which errors the TOE should be able to recognize. The_
+_evaluator generates a set of 24 (FFC) or 30 (ECC) test vectors consisting of data sets including_
+_domain parameter values or NIST approved curves, the evaluatorโs public keys, the TOEโs_
+_public/private key pairs, MacTag, and any inputs used in the KDF, such as the other info and_
+_TOE id fields._
+
+
+_The evaluator shall inject an error in some of the test vectors to test that the TOE recognizes_
+_invalid key agreement results caused by the following fields being incorrect: the shared secret_
+_value Z, the DKM, the other information field OI, the data to be MACed, or the generated_
+_MacTag. If the TOE contains the full or partial (only ECC) public key validation, the evaluator_
+_will also individually inject errors in both partiesโ static public keys, both partiesโ ephemeral_
+_public keys and the TOEโs static private key to assure the TOE detects errors in the public key_
+_validation function or the partial key validation function (in ECC only). At least two of the test_
+_vectors shall remain unmodified and therefore should result in valid key agreement results (they_
+_should pass)._
+
+
+_The TOE shall use these modified test vectors to emulate the key agreement scheme using the_
+_corresponding parameters. The evaluator shall compare the TOEโs results with the results using_
+_a known good implementation verifying that the TOE detects these errors._
+
+
+_**SP800-56B Key Establishment Schemes**_
+
+_The evaluator shall verify that the TSS describes whether the TOE acts as a sender, a recipient,_
+_or both for RSA-based key establishment schemes._
+
+
+_If the TOE acts as a sender, the following evaluation activity shall be performed to ensure the_
+_proper operation of every TOE supported combination of RSA-based key establishment scheme:_
+_To conduct this test the evaluator shall generate or obtain test vectors from a known good_
+_implementation of the TOE supported schemes. For each combination of supported key_
+_establishment scheme and its options (with or without key confirmation if supported, for each_
+_supported key confirmation MAC function if key confirmation is supported, and for each_
+_supported mask generation function if KTS-OAEP is supported), the tester shall generate 10 sets_
+_of test vectors. Each test vector shall include the RSA public key, the plaintext keying material,_
+_any additional input parameters if applicable, the MacKey and MacTag if key confirmation is_
+_incorporated, and the outputted ciphertext. For each test vector, the evaluator shall perform a_
+_key establishment encryption operation on the TOE with the same inputs (in cases where key_
+_confirmation is incorporated, the test shall use the MacKey from the test vector instead of the_
+_randomly generated MacKey used in normal operation) and ensure that the outputted ciphertext_
+_is equivalent to the ciphertext in the test vector._
+
+
+_If the TOE acts as a receiver, the following evaluation activities shall be performed to ensure the_
+_proper operation of every TOE supported combination of RSA-based key establishment scheme:_
+_To conduct this test the evaluator shall generate or obtain test vectors FCS_CKM.2.1/LOCKED_
+_from a known good implementation of the TOE supported schemes. For each combination of_
+_supported key establishment scheme and its options (with our without key confirmation if_
+_supported, for each supported key confirmation MAC function if key confirmation is supported,_
+_and for each supported mask generation function if KTS-OAEP is supported), the tester shall_
+_generate 10 sets of test vectors. Each test vector shall include the RSA private key, the plaintext_
+_keying material (KeyData), any additional input parameters if applicable, the MacTag in cases_
+_where key confirmation is incorporated, and the outputted ciphertext. For each test vector, the_
+
+
+_evaluator shall perform the key establishment decryption operation on the TOE and ensure that_
+_the outputted plaintext keying material (KeyData) is equivalent to the plaintext keying material_
+_in the test vector. In cases where key confirmation is incorporated, the evaluator shall perform_
+_the key confirmation steps and ensure that the outputted MacTag is equivalent to the MacTag in_
+_the test vector._
+
+
+_The evaluator shall ensure that the TSS describes how the TOE handles decryption errors. In_
+_accordance with NIST Special Publication 800-56B, the TOE must not reveal the particular error_
+_that occurred, either through the contents of any outputted or logged error message or through_
+_timing variations. If KTS-OAEP is supported, the evaluator shall create separate contrived_
+_ciphertext values that trigger each of the three decryption error checks described in NIST_
+_Special Publication 800-56B section 7.2.2.3, ensure that each decryption attempt results in an_
+_error, and ensure that any outputted or logged error message is identical for each. If KTS-KEM-_
+_KWS is supported, the evaluator shall create separate contrived ciphertext values that trigger_
+_each of the three decryption error checks described in NIST Special Publication 800-56B section_
+_7.2.3.3, ensure that each decryption attempt results in an error, and ensure that any outputted_
+_or logged error message is identical for each._
+
+
+_**RSAES-PKCS1-v1_5 Key Establishment Schemes**_
+
+_The evaluator shall verify the correctness of the TSF's implementation of RSAES-PKCS1-v1_5 by_
+_using a known good implementation for each protocol selected in FTP_ITC_EXT.1 that uses_
+_RSAES-PKCS1-v1_5._
+
+
+_**FFC Schemes using "safe-prime" groups**_
+
+_The evaluator shall verify the correctness of the TSF's implementation of "safe-prime" groups by_
+_using a known good implementation for each protocol selected in FTP_ITC_EXT.1 that uses_
+_"safe-prime" groups. This test must be performed for each "safe-prime" group that each protocol_
+_uses._
+
+
+**FCS_CKM.2/LOCKED Cryptographic Key Establishment**
+
+
+FCS_CKM.2.1/LOCKED
+
+The TSF shall **perform** cryptographic **key establishment** in accordance with a
+specified cryptographic key **establishment** method: [ **selection** :
+
+_[RSA-based key establishment schemes] that meet the following: [NIST_
+_Special Publication 800-56B, โRecommendation for Pair-Wise Key_
+_Establishment Schemes Using Integer Factorization Cryptographyโ]_
+
+_[Elliptic curve-based key establishment schemes] that meet the following:_
+
+_[_ _**selection**_ _:_
+
+_**NIST Special Publication 800-56A Revision 3, "Recommendation**_
+_**for Pair-Wise Key Establishment Schemes Using Discrete**_
+_**Logarithm Cryptography"**_
+_**RFC 7748, "Elliptic Curves for Security"**_
+
+_]_
+
+_[Finite field-based key establishment schemes] that meet the following:_
+
+_[NIST Special Publication 800-56A Revision 3, "Recommendation for Pair-_
+_Wise Key Establishment Schemes Using Discrete Logarithm Cryptography"]_
+
+] **for the purposes of encrypting sensitive data received while the device**
+**is locked.**
+
+
+**Application Note:** The RSA-based key establishment schemes are described in
+Section 9 of NIST SP 800-56B; however, Section 9 relies on implementation of
+other sections in SP 800-56B. If the TOE acts as a receiver in the RSA key
+establishment scheme, the TOE does not need to implement RSA key generation.
+
+
+The elliptic curves used for the key establishment scheme must correlate with
+the curves specified in FCS_CKM.1.1.
+
+
+The domain parameters used for the finite field-based key establishment scheme
+are specified by the key generation according to FCS_CKM.1.1.
+
+
+**Evaluation Activities**
+
+
+_FCS_CKM.2/LOCKED_
+_**TSS**_
+_There are no TSS evaluation activities for this component._
+
+
+_**Guidance**_
+_There are no guidance evaluation activities for this component._
+
+
+_**Tests**_
+
+
+_The test for SP800-56A Revision 3 and SP800-56B key establishment schemes is performed in_
+_association with FCS_CKM.2/UNLOCKED._
+
+
+_**Curve25519 Key Establishment Schemes**_
+
+
+_The evaluator shall verify a TOE's implementation of the key agreement scheme using the_
+_following Function and Validity tests. These validation tests for each key agreement scheme_
+_verify that a TOE has implemented the components of the key agreement scheme according to_
+_the specification. These components include the calculation of the shared secret K and the hash_
+_of K._
+
+
+_**Function Test**_
+
+
+_The Function test verifies the ability of the TOE to implement the key agreement schemes_
+_correctly. To conduct this test the evaluator shall generate or obtain test vectors from a known_
+_good implementation of the TOE supported schemes. For each supported key agreement role_
+_and hash function combination, the tester shall generate 10 sets of public keys. These keys are_
+_static, ephemeral or both depending on the scheme being tested._
+
+
+_The evaluator shall obtain the shared secret value K, and the hash of K._
+
+
+_The evaluator shall verify the correctness of the TSFโs implementation of a given scheme by_
+_using a known good implementation to calculate the shared secret value K and compare the_
+_hash generated from this value._
+
+
+_**Validity Test**_
+
+
+_The Validity test verifies the ability of the TOE to recognize another partyโs valid and invalid key_
+_agreement results. To conduct this test, the evaluator generates a set of 30 test vectors_
+_consisting of data sets including the evaluatorโs public keys and the TOEโs public/private key_
+_pairs._
+
+
+_The evaluator shall inject an error in some of the test vectors to test that the TOE recognizes_
+_invalid key agreement results caused by the following fields being incorrect: the shared secret_
+_value K or the hash of K. At least two of the test vectors shall remain unmodified and therefore_
+_should result in valid key agreement results (they should pass)._
+
+
+_The TOE shall use these modified test vectors to emulate the key agreement scheme using the_
+_corresponding parameters. The evaluator shall compare the TOEโs results with the results using_
+_a known good implementation verifying that the TOE detects these errors._
+
+
+**FCS_CKM_EXT.1 Cryptographic Key Support**
+
+
+FCS_CKM_EXT.1.1
+
+The TSF shall support [ **selection** : _immutable hardware_, _mutable hardware_ ]
+REKs with a [ **selection** : _symmetric_, _asymmetric_ ] key of strength [ **selection** :
+_112 bits_, _128 bits_, _192 bits_, _256 bits_ ].
+
+
+FCS_CKM_EXT.1.2
+
+Each REK shall be hardware-isolated from the OS on the TSF in runtime.
+
+
+FCS_CKM_EXT.1.3
+
+Each REK shall be generated by an RBG in accordance with FCS_RBG_EXT.1.
+
+
+**Application Note:** Either asymmetric or symmetric keys are allowed; the ST
+author makes the selection appropriate for the device. Symmetric keys must be
+of size 128 or 256 bits in order to correspond with FCS_COP.1/ENCRYPT.
+Asymmetric keys may be of any strength corresponding to FCS_CKM.1.
+
+
+The raw key material of "immutable hardware" REKs is computationally
+processed by hardware and software cannot access the raw key material. Thus if
+immutable hardware is selected in FCS_CKM_EXT.1.1 it implicitly meets
+FCS_CKM_EXT.7. If mutable hardware is selected in FCS_CKM_EXT.1.1,
+FCS_CKM_EXT.7 must be included in the ST.
+
+
+The lack of a public/documented API for importing or exporting the REK, when a
+private/undocumented API exists, is not sufficient to meet this requirement.
+
+
+The RBG used to generate a REK may be an RBG native to the hardware key
+container or may be an off-device RBG. If performed by an off-device RBG, the
+device manufacturer must not be able to access a REK after the manufacturing
+process has been completed. The Evaluation Activities for these two cases differ.
+
+
+**Evaluation Activities**
+
+
+**FCS_CKM_EXT.2 Cryptographic Key Random Generation**
+
+
+FCS_CKM_EXT.2.1
+
+All DEKs shall be [ **selection** :
+
+_randomly generated_
+_from the combination of a randomly generated DEK with another DEK or_
+_salt in a way that preserves the effective entropy of each factor by_
+
+_[_ _**selection**_ _: using an XOR operation, concatenating the keys and using a_
+_KDF (as described in SP 800-108), concatenating the keys and using a KDF_
+_(as described in SP 800-56C) ]_
+
+] with entropy corresponding to the security strength of AES key sizes of
+
+[ **selection** : _128_, _256_ ] bits.
+
+
+**Application Note:** The intent of this requirement is to ensure that the DEK
+cannot be recovered with less work than a full exhaust of the key space for AES.
+The key generation capability of the TOE uses an RBG implemented on the TOE
+device (FCS_RBG_EXT.1). Either 128-bit or 256-bit (or both) are allowed; the ST
+author makes the selection appropriate for the device. A DEK is used in addition
+to the KEK so that authentication factors can be changed without having to reencrypt all of the user data on the device.
+
+
+The ST author selects all applicable DEK generation types implemented by the
+TOE.
+
+
+SP 800-56C specifies a two-step key derivation procedure that employs an
+extraction-then-expansion technique for deriving keying material from a shared
+secret generated during a key establishment scheme. The Randomness
+Extraction step as described in Section 5 of SP 800-56C is followed by Key
+Expansion using the key derivation functions defined in SP 800-108 (as
+described in Section 6 of SP 800-56C).
+
+
+**Evaluation Activities**
+
+
+_FCS_CKM_EXT.2_
+_**TSS**_
+_The evaluator shall ensure that the documentation of the product's encryption key management_
+_is detailed enough that, after reading, the product's key management hierarchy is clear and that_
+_it meets the requirements to ensure the keys are adequately protected. The evaluator shall_
+_ensure that the documentation includes both an essay and one or more diagrams. Note that this_
+_may also be documented as separate proprietary evidence rather than being included in the TSS._
+
+
+_The evaluator shall also examine the key hierarchy section of the TSS to ensure that the_
+_formation of all DEKs is described and that the key sizes match that described by the ST author._
+_The evaluator shall examine the key hierarchy section of the TSS to ensure that each DEK is_
+_generated or combined from keys of equal or greater security strength using one of the selected_
+_methods._
+
+_If the symmetric DEK is generated by an RBG, the evaluator shall review the TSS to_
+_determine that it describes how the functionality described by FCS_RBG_EXT.1 is invoked._
+_The evaluator uses the description of the RBG functionality in FCS_RBG_EXT.1 or_
+_documentation available for the operational environment to determine that the key size_
+_being requested is greater than or equal to the key size and mode to be used for the_
+_encryption/decryption of the data._
+_If the DEK is formed from a combination, the evaluator shall verify that the TSS describes_
+_the method of combination and that this method is either an XOR or a KDF to justify that_
+_the effective entropy of each factor is preserved. The evaluator shall also verify that each_
+_combined value was originally generated from an Approved DRBG described in_
+_FCS_RBG_EXT.1._
+_If concatenating the keys and using a KDF (as described in SP 800-56C) is selected, the_
+_evaluator shall ensure the TSS includes a description of the randomness extraction step._
+
+_The description must include how an approved untruncated MAC function is being used for the_
+_randomness extraction step and the evaluator must verify the TSS describes that the output_
+_length (in bits) of the MAC function is at least as large as the targeted security strength (in bits)_
+_of the parameter set employed by the key establishment scheme (see Tables 1-3 of SP 800-56C)._
+
+
+_The description must include how the MAC function being used for the randomness extraction_
+_step is related to the PRF used in the key expansion and verify the TSS description includes the_
+_correct MAC function:_
+
+_If an HMAC-hash is used in the randomness extraction step, then the same HMAC-hash_
+_(with the same hash function hash) is used as the PRF in the key expansion step._
+_If an AES-CMAC (with key length 128, 192, or 256 bits) is used in the randomness_
+_extraction step, then AES-CMAC with a 128-bit key is used as the PRF in the key expansion_
+_step._
+_The description must include the lengths of the salt values being used in the randomness_
+_extraction step and the evaluator shall verify the TSS description includes correct salt_
+_lengths:_
+_If an HMAC-hash is being used as the MAC, the salt length can be any value up to the_
+_maximum bit length permitted for input to the hash function hash._
+_If an AES-CMAC is being used as the MAC, the salt length shall be the same length as the_
+_AES key (i.e. 128, 192, or 256 bits)._
+
+_(conditional) If a KDF is used, the evaluator shall ensure that the TSS includes a description of_
+_the key derivation function and shall verify the key derivation uses an approved derivation mode_
+_and key expansion algorithm according to SP 800-108 or SP 800-56C._
+
+
+_**Guidance**_
+_The evaluator uses the description of the RBG functionality in FCS_RBG_EXT.1 or_
+_documentation available for the operational environment to determine that the key size being_
+_generated or combined is identical to the key size and mode to be used for the_
+_encryption/decryption of the data._
+
+
+_**Tests**_
+_If a KDF is used, the evaluator shall perform one or more of the following tests to verify the_
+_correctness of the key derivation function, depending on the modes that are supported. Table 4_
+_maps the data fields to the notations used in SP 800-108 and SP 800-56C._
+
+
+_**Table 4: Notations used in SP 800-108 and SP 800-56C**_
+
+
+_**Data Fields**_ _**Notations**_
+
+
+_Pseudorandom function_ _PRF_ _PRF_
+
+
+_Counter length_ _r_ _r_
+
+
+_Length of output of PRF_ _h_ _h_
+
+
+_Length of derived keying material_ _L_ _L_
+
+
+_Length of input values_ _l length_ _l length_
+
+
+_Pseudorandom input values I_ _K1 (key derivation key)_ _Z (shared secret)_
+
+
+_Pseudorandom salt values_ _n/a_ _s_
+
+
+_Randomness extraction MAC_ _n/a_ _MAC_
+
+
+_**Counter Mode Tests:**_
+
+
+_The evaluator shall determine the following characteristics of the key derivation function:_
+
+_One or more pseudorandom functions that are supported by the implementation (PRF)._
+_One or more of the values {8, 16, 24, 32} that equal the length of the binary representation_
+_of the counter (r)._
+_The length (in bits) of the output of the PRF (h)._
+_Minimum and maximum values for the length (in bits) of the derived keying material (L)._
+_These values can be equal if only one value of L is supported. These must be evenly divisible_
+_by h._
+_Up to two values of L that are NOT evenly divisible by h._
+_Location of the counter relative to fixed input data: before, after, or in the middle._
+
+_Counter before fixed input data: fixed input data string length (in bytes), fixed input_
+_data string value._
+_Counter after fixed input data: fixed input data string length (in bytes), fixed input data_
+_string value._
+_Counter in the middle of fixed input data: length of data before counter (in bytes),_
+_length of data after counter (in bytes), value of string input before counter, value of_
+_string input after counter._
+
+_The length (I_length) of the input values I._
+
+_For each supported combination of I_length, MAC, salt, PRF, counter location, value of r, and_
+_value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values_
+_I, and pseudorandom salt values. If there is only one value of L that is evenly divisible by h, the_
+_evaluator shall generate 20 test vectors for it. For each test vector, the evaluator shall supply_
+_this data to the TOE in order to produce the keying material output._
+
+
+_The results from each test may either be obtained by the evaluator directly or by supplying the_
+_inputs to the implementer and receiving the results in response. To determine correctness, the_
+_evaluator shall compare the resulting values to those obtained by submitting the same inputs to_
+_a known good implementation._
+
+
+_**Feedback Mode Tests:**_
+
+
+_The evaluator shall determine the following characteristics of the key derivation function:_
+
+_One or more pseudorandom functions that are supported by the implementation (PRF)._
+_The length (in bits) of the output of the PRF (h)._
+_Minimum and maximum values for the length (in bits) of the derived keying material (L)._
+_These values can be equal if only one value of L is supported. These must be evenly divisible_
+_by h._
+_Up to two values of L that are NOT evenly divisible by h._
+_Whether or not zero-length IVs are supported._
+_Whether or not a counter is used, and if so:_
+
+_One or more of the values {8, 16, 24, 32} that equal the length of the binary_
+_representation of the counter (r)._
+_Location of the counter relative to fixed input data: before, after, or in the middle._
+
+_Counter before fixed input data: fixed input data string length (in bytes), fixed_
+_input data string value._
+_Counter after fixed input data: fixed input data string length (in bytes), fixed input_
+_data string value._
+_Counter in the middle of fixed input data: length of data before counter (in bytes),_
+_length of data after counter (in bytes), value of string input before counter, value_
+_of string input after counter._
+
+_The length (I_length) of the input values I._
+
+_For each supported combination of I_length, MAC, salt, PRF, counter location (if a counter is_
+_used), value of r (if a counter is used), and value of L, the evaluator shall generate 10 test_
+_vectors that include pseudorandom input values I and pseudorandom salt values. If the KDF_
+_supports zero-length IVs, five of these test vectors will be accompanied by pseudorandom IVs_
+_and the other five will use zero-length IVs. If zero-length IVs are not supported, each test vector_
+_will be accompanied by an pseudorandom IV. If there is only one value of L that is evenly_
+_divisible by h, the evaluator shall generate 20 test vectors for it._
+
+
+_For each test vector, the evaluator shall supply this data to the TOE in order to produce the_
+_keying material output. The results from each test may either be obtained by the evaluator_
+_directly or by supplying the inputs to the implementer and receiving the results in response. To_
+_determine correctness, the evaluator shall compare the resulting values to those obtained by_
+_submitting the same inputs to a known good implementation._
+
+
+_**Double Pipeline Iteration Mode Tests:**_
+
+
+_The evaluator shall determine the following characteristics of the key derivation function:_
+
+_One or more pseudorandom functions that are supported by the implementation (PRF)._
+_The length (in bits) of the output of the PRF (h)._
+_Minimum and maximum values for the length (in bits) of the derived keying material (L)._
+_These values can be equal if only one value of L is supported. These must be evenly divisible_
+_by h._
+_Up to two values of L that are NOT evenly divisible by h._
+_Whether or not a counter is used, and if so:_
+
+_One or more of the values {8, 16, 24, 32} that equal the length of the binary_
+_representation of the counter (r)._
+_Location of the counter relative to fixed input data: before, after, or in the middle._
+
+_Counter before fixed input data: fixed input data string length (in bytes), fixed_
+_input data string value._
+_Counter after fixed input data: fixed input data string length (in bytes), fixed input_
+_data string value._
+_Counter in the middle of fixed input data: length of data before counter (in bytes),_
+_length of data after counter (in bytes), value of string input before counter, value_
+_of string input after counter._
+
+_The length (I_length) of the input values I._
+
+_For each supported combination of I_length, MAC, salt, PRF, counter location (if a counter is_
+_used), value of r (if a counter is used), and value of L, the evaluator shall generate 10 test_
+_vectors that include pseudorandom input values I, and pseudorandom salt values. If there is only_
+_one value of L that is evenly divisible by h, the evaluator shall generate 20 test vectors for it._
+
+
+_For each test vector, the evaluator shall supply this data to the TOE in order to produce the_
+_keying material output. The results from each test may either be obtained by the evaluator_
+_directly or by supplying the inputs to the implementer and receiving the results in response. To_
+_determine correctness, the evaluator shall compare the resulting values to those obtained by_
+_submitting the same inputs to a known good implementation._
+
+
+**FCS_CKM_EXT.3 Cryptographic Key Generation**
+
+
+FCS_CKM_EXT.3.1
+
+The TSF shall use [ **selection** :
+
+_asymmetric KEKs of [_ _**assignment**_ _: security strength greater than or equal_
+_to 112 bits] security strength_
+_symmetric KEKs of [_ _**selection**_ _: 128-bit, 256-bit ] security strength_
+_corresponding to at least the security strength of the keys encrypted by the_
+_KEK_
+
+].
+
+
+**Application Note:** The ST author selects all applicable KEK types implemented
+by the TOE.
+
+
+FCS_CKM_EXT.3.2
+
+The TSF shall generate all KEKs using one of the following methods:
+
+Derive the KEK from a Password Authentication Factor according to
+FCS_COP.1.1 **/CONDITION** and
+
+[ **selection** :
+
+_Generate the KEK using an RBG that meets this profile (as specified in_
+_FCS_RBG_EXT.1)_
+_Generate the KEK using a key generation scheme that meets this profile (as_
+_specified in FCS_CKM.1)_
+_Combine the KEK from other KEKs in a way that preserves the effective_
+_entropy of each factor by [_ _**selection**_ _: using an XOR operation,_
+_concatenating the keys and using a KDF (as described in SP 800-108),_
+_concatenating the keys and using a KDF (as described in SP 800-56C),_
+_encrypting one key with another ]_
+
+].
+
+
+**Application Note:** The conditioning of passwords is performed in accordance
+with FCS_COP.1/CONDITION.
+
+
+It is expected that key generation derived from conditioning, using an RBG or
+generation scheme, and through combination, will each be necessary to meet the
+requirements set out in this document. In particular, Figure 3 has KEKs of each
+type: KEK_3 is generated, KEK_1 is derived from a Password Authentication
+Factor, and KEK_2 is combined from two KEKs. In Figure 3, KEK_3 may either
+be a symmetric key generated from an RBG or an asymmetric key generated
+
+
+using a key generation scheme according to FCS_CKM.1.
+
+
+If combined, the ST author should describe which method of combination is used
+in order to justify that the effective entropy of each factor is preserved.
+
+
+SP 800-56C specifies a two-step key derivation procedure that employs an
+extraction-then-expansion technique for deriving keying material from a shared
+secret generated during a key establishment scheme. The Randomness
+Extraction step as described in Section 5 of SP 800-56C is followed by Key
+Expansion using the key derivation functions defined in SP 800-108 (as
+described in Section 6 of SP 800-56C).
+
+
+**Evaluation Activities**
+
+
+_FCS_CKM_EXT.3_
+_**TSS**_
+_The evaluator shall examine the key hierarchy section of the TSS to ensure that the formation of_
+_all KEKs are described and that the key sizes match that described by the ST author. The_
+_evaluator shall examine the key hierarchy section of the TSS to ensure that each key (DEKs,_
+_software-based key storage, and KEKs) is encrypted by keys of equal or greater security strength_
+_using one of the selected methods._
+
+
+_The evaluator shall review the TSS to verify that it contains a description of the conditioning_
+_used to derive KEKs. This description must include the size and storage location of salts. This_
+_activity may be performed in combination with that for FCS_COP.1/CONDITION._
+
+
+_(conditional) If the symmetric KEK is generated by an RBG, the evaluator shall review the TSS to_
+_determine that it describes how the functionality described by FCS_RBG_EXT.1 is invoked. The_
+_evaluator uses the description of the RBG functionality in FCS_RBG_EXT.1 or documentation_
+_available for the operational environment to determine that the key size being requested is_
+_greater than or equal to the key size and mode to be used for the encryption/decryption of the_
+_data._
+
+
+_(conditional) If the KEK is generated according to an asymmetric key scheme, the evaluator shall_
+_review the TSS to determine that it describes how the functionality described by FCS_CKM.1 is_
+_invoked. The evaluator uses the description of the key generation functionality in FCS_CKM.1 or_
+_documentation available for the operational environment to determine that the key strength_
+_being requested is greater than or equal to 112 bits._
+
+
+_(conditional) If the KEK is formed from a combination, the evaluator shall verify that the TSS_
+_describes the method of combination and that this method is either an XOR, a KDF, or_
+_encryption._
+
+
+_(conditional) If a KDF is used, the evaluator shall ensure that the TSS includes a description of_
+_the key derivation function and shall verify the key derivation uses an approved derivation mode_
+_and key expansion algorithm according to SP 800-108._
+
+
+_(conditional) If concatenating the keys and using a KDF (as described in SP 800-56C) is selected,_
+_the evaluator shall ensure the TSS includes a description of the randomness extraction step. The_
+_description must include_
+
+_How an approved untruncated MAC function is being used for the randomness extraction_
+_step and the evaluator must verify the TSS describes that the output length (in bits) of the_
+_MAC function is at least as large as the targeted security strength (in bits) of the parameter_
+_set employed by the key establishment scheme (see Tables 1-3 of SP 800-56C)._
+_How the MAC function being used for the randomness extraction step is related to the PRF_
+_used in the key expansion and verify the TSS description includes the correct MAC_
+_function:_
+
+_If an HMAC-hash is used in the randomness extraction step, then the same HMAC-_
+_hash (with the same hash function hash) is used as the PRF in the key expansion step._
+_If an AES-CMAC (with key length 128, 192, or 256 bits) is used in the randomness_
+_extraction step, then AES-CMAC with a 128-bit key is used as the PRF in the key_
+_expansion step._
+
+_The lengths of the salt values being used in the randomness extraction step and the_
+_evaluator shall verify the TSS description includes correct salt lengths:_
+
+_If an HMAC-hash is being used as the MAC, the salt length can be any value up to the_
+_maximum bit length permitted for input to the hash function hash._
+_If an AES-CMAC is being used as the MAC, the salt length shall be the same length as_
+_the AES key (i.e. 128, 192, or 256 bits)._
+
+
+_The evaluator shall also ensure that the documentation of the product's encryption key_
+_management is detailed enough that, after reading, the product's key management hierarchy is_
+_clear and that it meets the requirements to ensure the keys are adequately protected. The_
+_evaluator shall ensure that the documentation includes both an essay and one or more diagrams._
+_Note that this may also be documented as separate proprietary evidence rather than being_
+_included in the TSS._
+
+
+_**Guidance**_
+_There are no guidance evaluation activities for this component._
+
+
+_**Tests**_
+_If a KDF is used, the evaluator shall perform one or more of the following tests to verify the_
+_correctness of the key derivation function, depending on the modes that are supported. Table 5_
+_maps the data fields to the notations used in SP 800-108 and SP 800-56C._
+
+
+_**Table 5: Notations used in SP 800-108 and SP 800-56C**_
+
+
+_**Data Fields**_ _**Notations**_
+
+
+_Pseudorandom function_ _PRF_ _PRF_
+
+
+_Counter length_ _r_ _r_
+
+
+_Length of output of PRF_ _h_ _h_
+
+
+_Length of derived keying material_ _L_ _L_
+
+
+_Length of input values_ _I_length_ _I_length_
+
+
+_Pseudorandom input values I_ _K1 (key derivation key)_ _Z (shared secret)_
+
+
+_Pseudorandom salt values_ _n/a_ _s_
+
+
+_Randomness extraction MAC_ _n/a_ _MAC_
+
+
+_**Counter Mode Tests:**_
+
+
+_The evaluator shall determine the following characteristics of the key derivation function:_
+
+_One or more pseudorandom functions that are supported by the implementation (PRF)._
+_One or more of the values {8, 16, 24, 32} that equal the length of the binary representation_
+_of the counter (r)._
+_The length (in bits) of the output of the PRF (h)._
+_Minimum and maximum values for the length (in bits) of the derived keying material (L)._
+_These values can be equal if only one value of L is supported. These must be evenly divisible_
+_by h._
+_Up to two values of L that are NOT evenly divisible by h._
+_Location of the counter relative to fixed input data: before, after, or in the middle._
+
+_Counter before fixed input data: fixed input data string length (in bytes), fixed input_
+_data string value._
+_Counter after fixed input data: fixed input data string length (in bytes), fixed input data_
+_string value._
+_Counter in the middle of fixed input data: length of data before counter (in bytes),_
+_length of data after counter (in bytes), value of string input before counter, value of_
+_string input after counter._
+
+_The length (I_length) of the input values I._
+
+
+_For each supported combination of I_length, MAC, salt, PRF, counter location, value of r, and_
+_value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values_
+_I, and pseudorandom salt values. If there is only one value of L that is evenly divisible by h, the_
+_evaluator shall generate 20 test vectors for it. For each test vector, the evaluator shall supply_
+_this data to the TOE in order to produce the keying material output._
+
+
+_The results from each test may either be obtained by the evaluator directly or by supplying the_
+_inputs to the implementer and receiving the results in response. To determine correctness, the_
+_evaluator shall compare the resulting values to those obtained by submitting the same inputs to_
+_a known good implementation._
+
+
+_**Feedback Mode Tests:**_
+_The evaluator shall determine the following characteristics of the key derivation function:_
+
+_One or more pseudorandom functions that are supported by the implementation (PRF)._
+_The length (in bits) of the output of the PRF (h)._
+_Minimum and maximum values for the length (in bits) of the derived keying material (L)._
+_These values can be equal if only one value of L is supported. These must be evenly divisible_
+_by h._
+_Up to two values of L that are NOT evenly divisible by h._
+_Whether or not zero-length IVs are supported._
+_Whether or not a counter is used, and if so:_
+
+_One or more of the values {8, 16, 24, 32} that equal the length of the binary_
+
+
+_representation of the counter (r)._
+_Location of the counter relative to fixed input data: before, after, or in the middle._
+
+_Counter before fixed input data: fixed input data string length (in bytes), fixed_
+_input data string value._
+_Counter after fixed input data: fixed input data string length (in bytes), fixed input_
+_data string value._
+_Counter in the middle of fixed input data: length of data before counter (in bytes),_
+_length of data after counter (in bytes), value of string input before counter, value_
+_of string input after counter._
+
+_The length (I_length) of the input values I._
+
+
+_For each supported combination of I_length, MAC, salt, PRF, counter location (if a counter is_
+_used), value of r (if a counter is used), and value of L, the evaluator shall generate 10 test_
+_vectors that include pseudorandom input values I and pseudorandom salt values. If the KDF_
+_supports zero-length IVs, five of these test vectors will be accompanied by pseudorandom IVs_
+_and the other five will use zero-length IVs. If zero-length IVs are not supported, each test vector_
+_will be accompanied by an pseudorandom IV. If there is only one value of L that is evenly_
+_divisible by h, the evaluator shall generate 20 test vectors for it._
+
+
+_For each test vector, the evaluator shall supply this data to the TOE in order to produce the_
+_keying material output. The results from each test may either be obtained by the evaluator_
+_directly or by supplying the inputs to the implementer and receiving the results in response. To_
+_determine correctness, the evaluator shall compare the resulting values to those obtained by_
+_submitting the same inputs to a known good implementation._
+
+
+_**Double Pipeline Iteration Mode Tests:**_
+_The evaluator shall determine the following characteristics of the key derivation function:_
+
+_One or more pseudorandom functions that are supported by the implementation (PRF)._
+_The length (in bits) of the output of the PRF (h)._
+_Minimum and maximum values for the length (in bits) of the derived keying material (L)._
+_These values can be equal if only one value of L is supported. These must be evenly divisible_
+_by h._
+_Up to two values of L that are NOT evenly divisible by h._
+_Whether or not a counter is used, and if so:_
+
+_One or more of the values {8, 16, 24, 32} that equal the length of the binary_
+_representation of the counter (r)._
+_Location of the counter relative to fixed input data: before, after, or in the middle._
+
+_Counter before fixed input data: fixed input data string length (in bytes), fixed_
+_input data string value._
+_Counter after fixed input data: fixed input data string length (in bytes), fixed input_
+_data string value._
+_Counter in the middle of fixed input data: length of data before counter (in bytes),_
+_length of data after counter (in bytes), value of string input before counter, value_
+_of string input after counter._
+
+_The length (I_length) of the input values I._
+
+
+_For each supported combination of I_length, MAC, salt, PRF, counter location (if a counter is_
+_used), value of r (if a counter is used), and value of L, the evaluator shall generate 10 test_
+_vectors that include pseudorandom input values I, and pseudorandom salt values. If there is only_
+_one value of L that is evenly divisible by h, the evaluator shall generate 20 test vectors for it._
+
+
+_For each test vector, the evaluator shall supply this data to the TOE in order to produce the_
+_keying material output. The results from each test may either be obtained by the evaluator_
+_directly or by supplying the inputs to the implementer and receiving the results in response. To_
+_determine correctness, the evaluator shall compare the resulting values to those obtained by_
+_submitting the same inputs to a known good implementation._
+
+
+**FCS_CKM_EXT.4 Key Destruction**
+
+
+FCS_CKM_EXT.4.1
+
+The TSF shall destroy cryptographic keys in accordance with the specified
+cryptographic key destruction methods:
+
+By clearing the KEK encrypting the target key
+In accordance with the following rules
+
+For volatile memory, the destruction shall be executed by a single
+direct overwrite [ **selection** : _consisting of a pseudorandom pattern_
+_using the TSFโs RBG_, _consisting of zeros_ ].
+For non-volatile EEPROM, the destruction shall be executed by a single
+direct overwrite consisting of a pseudo random pattern using the TSFโs
+RBG (as specified in FCS_RBG_EXT.1), followed by a read-verify.
+For non-volatile flash memory, that is not wear-leveled, the destruction
+shall be executed [ **selection** : _by a single direct overwrite consisting of_
+_zeros followed by a read-verify_, _by a block erase that erases the_
+_reference to memory that stores data as well as the data itself_ ].
+
+
+FCS_CKM_EXT.4.2
+
+
+
+For non-volatile flash memory, that is wear-leveled, the destruction
+shall be executed [ **selection** : _by a single direct overwrite consisting of_
+_zeros_, _by a block erase_ ].
+For non-volatile memory other than EEPROM and flash, the
+destruction shall be executed by a single direct overwrite with a
+random pattern that is changed before each write.
+
+
+**Application Note:** The clearing indicated above applies to each intermediate
+storage area for plaintext key or cryptographic critical security parameter (i.e.
+any storage, such as memory buffers, that is included in the path of such data)
+upon the transfer of the key or cryptographic critical security parameter to
+another location.
+
+
+Because plaintext key material is not allowed to be written to non-volatile
+memory (FPT_KST_EXT.1), the second selection only applies to key material
+written to volatile memory.
+
+
+The TSF shall destroy all plaintext keying material and critical security
+parameters when no longer needed.
+
+
+**Application Note:** For the purposes of this requirement, plaintext keying
+material refers to authentication data, passwords, secret/private symmetric keys,
+private asymmetric keys, data used to derive keys, values derived from
+passwords, etc.
+
+
+Key destruction procedures are performed in accordance with
+FCS_CKM_EXT.4.1.
+
+
+There are multiple situations in which plaintext keying material is no longer
+necessary, including when the TOE is powered off, when the wipe function is
+performed, when trusted channels are disconnected, when keying material is no
+longer needed by the trusted channel per the protocol, and when transitioning to
+the locked state (for those values derived from the Password Authentication
+Factor or that key material which is protected by the password-derived or
+biometric-unlocked KEK according to FCS_STG_EXT.2 โ see Figure 3). For keys
+(or key material used to derive those keys) protecting sensitive data received in
+the locked state, "no longer needed" includes "while in the locked state."
+
+
+Trusted channels may include TLS, HTTPS, DTLS, IPsec VPNs, Bluetooth
+BR/EDR, and Bluetooth LE. The plaintext keying material for these channels
+includes (but is not limited to) master secrets, and Security Associations (SAs).
+
+
+If REKs are processed in a separate execution environment on the same
+Application Processor as the OS, REK key material must be cleared from RAM
+immediately after use, and at least, must be wiped when the device is locked, as
+the REK is part of the key hierarchy protecting sensitive data.
+
+
+
+**Evaluation Activities**
+
+
+_FCS_CKM_EXT.4_
+_**TSS**_
+_The evaluator shall check to ensure the TSS lists each type of plaintext key material (DEKs,_
+_software-based key storage, KEKs, trusted channel keys, passwords, etc.) and its generation and_
+_storage location._
+
+
+_The evaluator shall verify that the TSS describes when each type of key material is cleared (for_
+_example, on system power off, on wipe function, on disconnection of trusted channels, when no_
+_longer needed by the trusted channel per the protocol, when transitioning to the locked state,_
+_and possibly including immediately after use, while in the locked state, etc.)._
+
+
+_The evaluator shall also verify that, for each type of key, the type of clearing procedure that is_
+_performed (cryptographic erase, overwrite with zeros, overwrite with random pattern, or block_
+_erase) is listed. If different types of memory are used to store the materials to be protected, the_
+_evaluator shall check to ensure that the TSS describes the clearing procedure in terms of the_
+_memory in which the data are stored._
+
+
+_**Guidance**_
+_There are no guidance evaluation activities for this component._
+
+
+_**Tests**_
+_**Evaluation Activity Note:**_ _The following tests require the developer to provide access to a test_
+_platform that provides the evaluator with tools that are typically not found on factory products._
+
+
+_For each software and firmware key clearing situation (including on system power off, on wipe_
+_function, on disconnection of trusted channels, when no longer needed by the trusted channel_
+
+
+_per the protocol, when transitioning to the locked state, and possibly including immediately after_
+_use, while in the locked state) the evaluator shall repeat the following tests._
+
+
+_For these tests the evaluator shall utilize appropriate development environment (e.g. a Virtual_
+_Machine) and development tools (debuggers, simulators, etc.) to test that keys are cleared,_
+_including all copies of the key that may have been created internally by the TOE during normal_
+_cryptographic processing with that key._
+
+
+_Test 3: Applied to each key held as plaintext in volatile memory and subject to destruction_
+_by overwrite by the TOE (whether or not the plaintext value is subsequently encrypted for_
+_storage in volatile or non-volatile memory). In the case where the only selection made for_
+_the destruction method key was removal of power, then this test is unnecessary. The_
+_evaluator shall:_
+
+_1. Record the value of the key in the TOE subject to clearing._
+_2. Cause the TOE to perform a normal cryptographic processing with the key from Step_
+
+_#1._
+_3. Cause the TOE to clear the key._
+_4. Cause the TOE to stop the execution but not exit._
+_5. Cause the TOE to dump the entire memory of the TOE into a binary file._
+_6. Search the content of the binary file created in Step #5 for instances of the known key_
+
+_value from Step #1._
+_7. Break the key value from Step #1 into 3 similar sized pieces and perform a search_
+
+_using each piece._
+
+
+_Steps 1-6 ensure that the complete key does not exist anywhere in volatile memory. If a_
+_copy is found, then the test fails._
+
+
+_Step 7 ensures that partial key fragments do not remain in memory. If a fragment is found,_
+_there is a minuscule chance that it is not within the context of a key (e.g., some random bits_
+_that happen to match). If this is the case the test should be repeated with a different key in_
+_Step #1. If a fragment is found the test fails._
+
+
+_Test 4: Applied to each key held in non-volatile memory and subject to destruction by_
+_overwrite by the TOE. The evaluator shall use special tools (as needed), provided by the_
+_TOE developer if necessary, to view the key storage location:_
+
+_1. Record the value of the key in the TOE subject to clearing._
+_2. Cause the TOE to perform a normal cryptographic processing with the key from Step_
+
+_#1._
+_3. Cause the TOE to clear the key._
+_4. Search the non-volatile memory the key was stored in for instances of the known key_
+
+_value from Step #1. If a copy is found, then the test fails._
+_5. Break the key value from Step #1 into 3 similar sized pieces and perform a search_
+
+_using each piece. If a fragment is found then the test is repeated (as described for test_
+_1 above), and if a fragment is found in the repeated test then the test fails._
+
+
+_Test 5: Applied to each key held as non-volatile memory and subject to destruction by_
+_overwrite by the TOE. The evaluator shall use special tools (as needed), provided by the_
+_TOE developer if necessary, to view the key storage location:_
+
+_1. Record the storage location of the key in the TOE subject to clearing._
+_2. Cause the TOE to perform a normal cryptographic processing with the key from Step_
+
+_#1._
+_3. Cause the TOE to clear the key._
+_4. Read the storage location in Step #1 of non-volatile memory to ensure the appropriate_
+
+_pattern is utilized._
+
+
+_The test succeeds if correct pattern is used to overwrite the key in the memory location. If_
+_the pattern is not found the test fails._
+
+
+**FCS_CKM_EXT.5 TSF Wipe**
+
+
+FCS_CKM_EXT.5.1
+
+The TSF shall wipe all protected data by [ **selection** :
+
+_Cryptographically erasing the encrypted DEKs or the KEKs in non-volatile_
+_memory by following the requirements in FCS_CKM_EXT.4.1_
+_Overwriting all PD according to the following rules:_
+
+_For EEPROM, the destruction shall be executed by a single direct_
+_overwrite consisting of a pseudo random pattern using the TSFโs RBG_
+_(as specified in FCS_RBG_EXT.1, followed by a read-verify._
+_For flash memory, that is not wear-leveled, the destruction shall be_
+_executed [_ _**selection**_ _: by a single direct overwrite consisting of zeros_
+_followed by a read-verify, by a block erase that erases the reference to_
+_memory that stores data as well as the data itself ]._
+_For flash memory, that is wear-leveled, the destruction shall be_
+_executed [_ _**selection**_ _: by a single direct overwrite consisting of zeros,_
+
+
+FCS_CKM_EXT.5.2
+
+
+
+_by a block erase ]._
+_For non-volatile memory other than EEPROM and flash, the_
+_destruction shall be executed by a single direct overwrite with a_
+_random pattern that is changed before each write._
+
+].
+
+
+**Application Note:** Protected data is all non-TSF data, including all user or
+enterprise data. Some or all of this data may be considered sensitive data as
+well.
+
+
+The TSF shall perform a power cycle on conclusion of the wipe procedure.
+
+
+
+**Evaluation Activities**
+
+
+**FCS_CKM_EXT.6 Salt Generation**
+
+
+FCS_CKM_EXT.6.1
+
+The TSF shall generate all salts using an RBG that meets FCS_RBG_EXT.1.
+
+
+**Application Note:** This requirement refers only to salt generation. In the
+examples given, a salt may be used as part of the scheme/algorithm.
+Requirements on nonces or ephemeral keys are provided elsewhere, if needed.
+The list below is provided for clarity, in order to give examples of where the TSF
+
+
+may be generating cryptographic salts; it is not exhaustive nor is it intended to
+mandate implementation of all of these schemes/algorithms. Cryptographic salts
+are generated for various uses including:
+
+RSASSA-PSS signature generation
+DSA signature generation
+ECDSA signature generation
+DH static key agreement scheme
+PBKDF
+Key Agreement Scheme in NIST SP 800-56B
+AES GCM
+
+
+**Evaluation Activities**
+
+
+
+
+
+**FCS_COP.1/ENCRYPT Cryptographic Operation**
+
+
+FCS_COP.1.1/ENCRYPT
+
+The TSF shall perform [ _encryption/decryption_ ] in accordance with a specified
+cryptographic algorithm: [
+
+_AES-CBC (as defined in FIPS PUB 197, and NIST SP 800-38A) mode_
+_AES-CCMP (as defined in FIPS PUB 197, NIST SP 800-38C and IEEE_
+_802.11-2012), and_
+
+_[_ _**selection**_ _:_
+
+_AES Key Wrap (KW) (as defined in NIST SP 800-38F)_
+_AES Key Wrap with Padding (KWP) (as defined in NIST SP 800-38F)_
+_AES-GCM (as defined in NIST SP 800-38D)_
+_AES-CCM (as defined in NIST SP 800-38C)_
+_AES-XTS (as defined in NIST SP 800-38E) mode_
+_AES-CCMP-256 (as defined in NIST SP800-38C and IEEE 802.11ac-_
+_2013)_
+_AES-GCMP-256 (as defined in NIST SP800-38D and IEEE 802.11ac-_
+_2013)_
+_no other modes_
+
+_]_
+
+] and cryptographic key sizes [ _128-bit key sizes and [_ _**selection**_ _: 256-bit key_
+_sizes, no other key sizes ]_ ].
+
+
+**Application Note:** For the first selection, the ST author should choose the mode
+or modes in which AES operates. For the second selection, the ST author should
+choose the key sizes that are supported by this functionality. 128-bit CBC and
+[CCMP are required in order to comply with the PP-Module for Wireless LAN](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=386&id=386)
+Clients, version 1.0.
+
+
+[Note that to comply with the PP-Module for Wireless LAN Clients, version 1.0,](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=386&id=386)
+AES CCMP (which uses AES in CCM as specified in SP 800-38C) with
+cryptographic key size of 128 bits must be implemented. If CCM is only
+implemented to support CCMP for WLAN, AES-CCM does not need be selected.
+Optionally, AES-CCMP-256 or AES-GCMP-256 with cryptographic key size of 256
+bits may be implemented.
+
+
+**Evaluation Activities**
+
+
+_FCS_COP.1/ENCRYPT_
+_**TSS**_
+_There are no TSS evaluation activities for this component._
+
+
+_**Guidance**_
+_There are no guidance evaluation activities for this component._
+
+
+_**Tests**_
+_**Evaluation Activity Note:**_ _The following tests require the developer to provide access to a test_
+_platform that provides the evaluator with tools that are typically not found on factory products._
+
+
+_**AES-CBC Tests**_
+_Test 8: AES-CBC Known Answer Tests_
+
+
+_There are four Known Answer Tests (KATs), described below. In all KATs, the plaintext,_
+_ciphertext, and IV values shall be 128-bit blocks. The results from each test may either be_
+_obtained by the evaluator directly or by supplying the inputs to the implementer and_
+_receiving the results in response. To determine correctness, the evaluator shall compare_
+_the resulting values to those obtained by submitting the same inputs to a known good_
+_implementation._
+
+
+_Test 8.1: KAT-1. To test the encrypt functionality of AES-CBC, the evaluator shall_
+_supply a set of 10 plaintext values and obtain the ciphertext value that results from_
+_AES-CBC encryption of the given plaintext using a key value of all zeros and an IV of_
+_all zeros. Five plaintext values shall be encrypted with a 128-bit all-zeros key, and the_
+_other five shall be encrypted with a 256-bit all-zeros key._
+
+
+_To test the decrypt functionality of AES-CBC, the evaluator shall perform the same test_
+_as for encrypt, using 10 ciphertext values as input and AES-CBC decryption._
+
+
+_Test 8.2: KAT-2. To test the encrypt functionality of AES-CBC, the evaluator shall_
+_supply a set of 10 key values and obtain the ciphertext value that results from AES-_
+_CBC encryption of an all-zeros plaintext using the given key value and an IV of all_
+_zeros. Five of the keys shall be 128-bit keys, and the other five shall be 256-bit keys._
+
+
+_To test the decrypt functionality of AES-CBC, the evaluator shall perform the same test_
+_as for encrypt, using an all-zero ciphertext value as input and AES-CBC decryption._
+
+
+_Test 8.3: KAT-3. To test the encrypt functionality of AES-CBC, the evaluator shall_
+_supply the two sets of key values described below and obtain the ciphertext value that_
+_results from AES encryption of an all-zeros plaintext using the given key value and an_
+_IV of all zeros. The first set of keys shall have 128 128-bit keys, and the second set_
+_shall have 256 256-bit keys. Key i in each set shall have the leftmost i bits be ones and_
+_the rightmost N-i bits be zeros, for i in [1,N]._
+
+
+_To test the decrypt functionality of AES-CBC, the evaluator shall supply the two sets of_
+_key and ciphertext value pairs described below and obtain the plaintext value that_
+_results from AES-CBC decryption of the given ciphertext using the given key and an IV_
+_of all zeros. The first set of key or ciphertext pairs shall have 128 128-bit key or_
+_ciphertext pairs, and the second set of key or ciphertext pairs shall have 256 256-bit_
+_key or ciphertext pairs. Key i in each set shall have the leftmost i bits be ones and the_
+_rightmost N-i bits be zeros, for i in [1,N]. The ciphertext value in each pair shall be the_
+_value that results in an all-zeros plaintext when decrypted with its corresponding key._
+
+
+_Test 8.4: KAT-4. To test the encrypt functionality of AES-CBC, the evaluator shall_
+_supply the set of 128 plaintext values described below and obtain the two ciphertext_
+_values that result from AES-CBC encryption of the given plaintext using a 128-bit key_
+_value of all zeros with an IV of all zeros and using a 256-bit key value of all zeros with_
+_an IV of all zeros, respectively. Plaintext value i in each set shall have the leftmost i_
+_bits be ones and the rightmost 128-i bits be zeros, for i in [1,128]._
+
+
+_To test the decrypt functionality of AES-CBC, the evaluator shall perform the same test_
+_as for encrypt, using ciphertext values of the same form as the plaintext in the encrypt_
+_test as input and AES-CBC decryption._
+
+
+_Test 9: AES-CBC Multi-Block Message Test_
+
+
+_The evaluator shall test the encrypt functionality by encrypting an i-block message where 1_
+_< i <= 10. The evaluator shall choose a key, an IV and plaintext message of length i blocks_
+_and encrypt the message, using the mode to be tested, with the chosen key and IV. The_
+_ciphertext shall be compared to the result of encrypting the same plaintext message with_
+_the same key and IV using a known good implementation._
+
+
+_The evaluator shall also test the decrypt functionality for each mode by decrypting an i-_
+_block message where 1 < i <= 10. The evaluator shall choose a key, an IV and a ciphertext_
+_message of length i blocks and decrypt the message, using the mode to be tested, with the_
+_chosen key and IV. The plaintext shall be compared to the result of decrypting the same_
+_ciphertext message with the same key and IV using a known good implementation._
+
+
+_Test 10: AES-CBC Monte Carlo Tests_
+
+
+_The evaluator shall test the encrypt functionality using a set of 200 plaintext, IV, and key 3-_
+_tuples. 100 of these shall use 128 bit keys, and 100 shall use 256 bit keys. The plaintext and_
+_IV values shall be 128-bit blocks. For each 3-tuple, 1000 iterations shall be run as follows:_
+
+
+_# Input: PT, IV, Key for i = 1 to 1000: if i == 1: CT[1] =_
+_AES-CBC-Encrypt(Key, IV, PT) PT = IV else: CT[i] = AES-CBC-Encrypt(Key, PT) PT_
+_= CT[i-1]_
+
+
+_The ciphertext computed in the 1000_ _[th]_ _iteration (i.e. CT[1000]) is the result for that trial._
+_This result shall be compared to the result of running 1000 iterations with the same values_
+_using a known good implementation._
+
+
+_The evaluator shall test the decrypt functionality using the same test as for encrypt,_
+_exchanging CT and PT and replacing AES-CBC-Encrypt with AES-CBC-Decrypt._
+
+
+_**AES-CCM Tests**_
+_Test 11: The evaluator shall test the generation-encryption and decryption-verification_
+_functionality of AES-CCM for the following input parameter and tag lengths:_
+
+
+_**128 bit and 256 bit keys**_
+
+
+_**Two payload lengths.**_ _One payload length shall be the shortest supported payload_
+_length, greater than or equal to zero bytes. The other payload length shall be the_
+_longest supported payload length, less than or equal to 32 bytes (256 bits)._
+
+
+_**Two or three associated data lengths.**_ _One associated data length shall be 0, if_
+_supported. One associated data length shall be the shortest supported payload length,_
+_greater than or equal to zero bytes. One associated data length shall be the longest_
+_supported payload length, less than or equal to 32 bytes (256 bits). If the_
+_implementation supports an associated data length of 2_ _[16]_ _bytes, an associated data_
+_length of 2_ _[16]_ _bytes shall be tested._
+
+
+_**Nonce lengths.**_ _All supported nonce lengths between 7 and 13 bytes, inclusive, shall_
+_be tested._
+
+
+_**Tag lengths.**_ _All supported tag lengths of 4, 6, 8, 10, 12, 14 and 16 bytes shall be_
+_tested._
+
+_To test the generation-encryption functionality of AES-CCM, the evaluator shall perform the_
+_following four tests:_
+
+_Test 11.1: For EACH supported key and associated data length and ANY supported_
+_payload, nonce and tag length, the evaluator shall supply one key value, one nonce_
+_value and 10 pairs of associated data and payload values and obtain the resulting_
+_ciphertext._
+
+
+_Test 11.2: For EACH supported key and payload length and ANY supported associated_
+_data, nonce and tag length, the evaluator shall supply one key value, one nonce value_
+_and 10 pairs of associated data and payload values and obtain the resulting ciphertext._
+
+
+_Test 11.3: For EACH supported key and nonce length and ANY supported associated_
+_data, payload and tag length, the evaluator shall supply one key value and 10_
+_associated data, payload and nonce value 3-tuples and obtain the resulting ciphertext._
+
+
+_Test 11.4: For EACH supported key and tag length and ANY supported associated_
+_data, payload and nonce length, the evaluator shall supply one key value, one nonce_
+_value and 10 pairs of associated data and payload values and obtain the resulting_
+_ciphertext._
+
+_To determine correctness in each of the above tests, the evaluator shall compare the_
+_ciphertext with the result of generation-encryption of the same inputs with a known good_
+_implementation._
+
+
+_To test the decryption-verification functionality of AES-CCM, for EACH combination of_
+_supported associated data length, payload length, nonce length and tag length, the_
+_evaluator shall supply a key value and 15 nonce, associated data and ciphertext 3-tuples_
+_and obtain either a FAIL result or a PASS result with the decrypted payload. The evaluator_
+_shall supply 10 tuples that should FAIL and 5 that should PASS per set of 15._
+
+
+_**AES-GCM Test**_
+_The evaluator shall test the authenticated encrypt functionality of AES-GCM for each_
+_combination of the following input parameter lengths:_
+
+
+_**128 bit and 256 bit keys**_
+
+
+_**Two plaintext lengths.**_ _One of the plaintext lengths shall be a non-zero integer_
+_multiple of 128 bits, if supported. The other plaintext length shall not be an integer_
+_multiple of 128 bits, if supported._
+
+
+_**Three AAD lengths.**_ _One AAD length shall be 0, if supported. One AAD length shall be_
+
+
+_a non-zero integer multiple of 128 bits, if supported. One AAD length shall not be an_
+_integer multiple of 128 bits, if supported._
+
+
+_**Two IV lengths.**_ _If 96 bit IV is supported, 96 bits shall be one of the two IV lengths_
+_tested._
+
+_Test 12: The evaluator shall test the encrypt functionality using a set of 10 key, plaintext,_
+_AAD, and IV tuples for each combination of parameter lengths above and obtain the_
+_ciphertext value and tag that results from AES-GCM authenticated encrypt. Each supported_
+_tag length shall be tested at least once per set of 10. The IV value may be supplied by the_
+_evaluator or the implementation being tested, as long as it is known._
+
+
+_Test 13: The evaluator shall test the decrypt functionality using a set of 10 key, ciphertext,_
+_tag, AAD, and IV 5-tuples for each combination of parameter lengths above and obtain a_
+_Pass/Fail result on authentication and the decrypted plaintext if Pass. The set shall include_
+_five tuples that Pass and five that Fail._
+
+
+_The results from each test may either be obtained by the evaluator directly or by supplying_
+_the inputs to the implementer and receiving the results in response. To determine_
+_correctness, the evaluator shall compare the resulting values to those obtained by_
+_submitting the same inputs to a known good implementation._
+
+
+_**XTS-AES Test**_
+_Test 14: The evaluator shall test the encrypt functionality of XTS-AES for each combination_
+_of the following input parameter lengths:_
+
+
+_**256 bit (for AES-128) and 512 bit (for AES-256) keys**_
+
+
+_**Three data unit (i.e. plaintext) lengths.**_ _One of the data unit lengths shall be a non-_
+_zero integer multiple of 128 bits, if supported. One of the data unit lengths shall be an_
+_integer multiple of 128 bits, if supported. The third data unit length shall be either the_
+_longest supported data unit length or 216 bits, whichever is smaller._
+
+
+_using a set of 100 (key, plaintext and 128-bit random tweak value) 3-tuples and obtain the_
+_ciphertext that results from XTS-AES encrypt._
+
+
+_The evaluator may supply a data unit sequence number instead of the tweak value if the_
+_implementation supports it. The data unit sequence number is a base-10 number ranging_
+_between 0 and 255 that implementations convert to a tweak value internally._
+
+
+_Test 15: The evaluator shall test the decrypt functionality of XTS-AES using the same test as_
+_for encrypt, replacing plaintext values with ciphertext values and XTS-AES encrypt with_
+_XTS-AES decrypt._
+
+
+_**AES Key Wrap (AES-KW) and Key Wrap with Padding (AES-KWP) Test**_
+_Test 16: The evaluator shall test the authenticated encryption functionality of AES-KW for_
+_EACH combination of the following input parameter lengths:_
+
+
+_**128 and 256 bit key encryption keys (KEKs)**_
+
+
+_**Three plaintext lengths.**_ _One of the plaintext lengths shall be two semi-blocks (128_
+_bits). One of the plaintext lengths shall be three semi-blocks (192 bits). The third data_
+_unit length shall be the longest supported plaintext length less than or equal to 64_
+_semi-blocks (4096 bits)._
+
+_using a set of 100 key and plaintext pairs and obtain the ciphertext that results from AES-_
+_KW authenticated encryption. To determine correctness, the evaluator shall use the AES-_
+_KW authenticated-encryption function of a known good implementation._
+
+
+_Test 17: The evaluator shall test the authenticated-decryption functionality of AES-KW_
+_using the same test as for authenticated-encryption, replacing plaintext values with_
+_ciphertext values and AES-KW authenticated-encryption with AES-KW authenticated-_
+_decryption._
+
+
+_Test 18: The evaluator shall test the authenticated-encryption functionality of AES-KWP_
+_using the same test as for AES-KW authenticated-encryption with the following change in_
+_the three plaintext lengths:_
+
+_One plaintext length shall be one octet. One plaintext length shall be 20 octets (160_
+_bits)._
+
+
+_One plaintext length shall be the longest supported plaintext length less than or equal_
+_to 512 octets (4096 bits)._
+
+_Test 19: The evaluator shall test the authenticated-decryption functionality of AES-KWP_
+_using the same test as for AES-KWP authenticated-encryption, replacing plaintext values_
+_with ciphertext values and AES-KWP authenticated-encryption with AES-KWP_
+_authenticated-decryption._
+
+
+**FCS_COP.1/HASH Cryptographic Operation**
+
+
+FCS_COP.1.1/HASH
+
+The TSF shall perform [ _cryptographic hashing_ ] in accordance with a specified
+cryptographic algorithm [ _SHA-1 and [_ _**selection**_ _: SHA-256, SHA-384, SHA-512,_
+_no other algorithms ]_ ] and **message digest** sizes [ _160 and [_ _**selection**_ _: 256 bits,_
+_384 bits, 512 bits, no other message digest sizes ]_ ] that meet the following: [ _FIPS_
+_Pub 180-4_ ].
+
+
+**Application Note:** Per NIST SP 800-131A, SHA-1 for generating digital
+signatures is no longer allowed, and SHA-1 for verification of digital signatures
+is strongly discouraged as there may be risk in accepting these signatures. It is
+expected that vendors will implement SHA-2 algorithms in accordance with SP
+800-131A.
+
+
+[SHA-1 is currently required in order to comply with the PP-Module for Wireless](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=386&id=386)
+LAN Clients, version 1.0. Vendors are strongly encouraged to implement
+updated protocols that support the SHA-2 family; until updated protocols are
+supported, this PP allows support for SHA-1 implementations in compliance with
+SP 800-131A.
+
+
+The intent of this requirement is to specify the hashing function. The hash
+selection must support the message digest size selection. The hash selection
+should be consistent with the overall strength of the algorithm used (for
+example, SHA 256 for 128-bit keys).
+
+
+The TSF hashing functions can be implemented in one of two modes. The first
+mode is the byteโoriented mode. In this mode the TSF only hashes messages that
+are an integral number of bytes in length; i.e. the length (in bits) of the message
+to be hashed is divisible by 8. The second mode is the bitโoriented mode. In this
+mode the TSF hashes messages of arbitrary length. The TSF may implement
+either bit-oriented or byte-oriented; both implementations are not required.
+
+
+Validation Guidelines:
+
+
+**Rule #2**
+
+
+**Rule #3**
+
+
+**Rule #4**
+
+
+**Evaluation Activities**
+
+
+_FCS_COP.1/HASH_
+_**TSS**_
+_The evaluator shall check that the association of the hash function with other TSF cryptographic_
+_functions (for example, the digital signature verification function) is documented in the TSS. The_
+_evaluator shall check that the TSS indicates if the hashing function is implemented in bit-_
+_oriented or byte-oriented mode._
+
+
+_**Guidance**_
+_The evaluator checks the AGD documents to determine that any configuration that is required to_
+_be done to configure the functionality for the required hash sizes is present._
+
+
+_**Tests**_
+_**Evaluation Activity Note:**_ _The following tests require the developer to provide access to a test_
+_platform that provides the evaluator with tools that are typically not found on factory products._
+
+
+_The evaluator shall perform all of the following tests for each hash algorithm implemented by_
+_the TSF and used to satisfy the requirements of this PP. As there are different tests for each_
+_mode, an indication is given in the following sections for the bitโoriented vs. the byteโoriented_
+_tests._
+
+
+_Test 20: Short Messages Test: Bit-oriented Mode_
+_The evaluators devise an input set consisting of m+1 messages, where m is the block length_
+_of the hash algorithm. The length of the messages ranges sequentially from 0 to m bits. The_
+_message text shall be pseudorandomly generated. The evaluators compute the message_
+_digest for each of the messages and ensure that the correct result is produced when the_
+_messages are provided to the TSF._
+
+
+_Test 21: Short Messages Test: Byte-oriented Mode_
+_The evaluators devise an input set consisting of m/8+1 messages, where m is the block_
+_length of the hash algorithm. The length of the messages range sequentially from 0 to m/8_
+_bytes, with each message being an integral number of bytes. The message text shall be_
+_pseudorandomly generated. The evaluators compute the message digest for each of the_
+
+
+_messages and ensure that the correct result is produced when the messages are provided_
+_to the TSF._
+
+
+_Test 22: Selected Long Messages Test: Bit-oriented Mode_
+_The evaluators devise an input set consisting of m messages, where m is the block length of_
+_the hash algorithm. The length of the i_ _[th]_ _message is 512 + 99*i, where 1 โค i โค m. The_
+_message text shall be pseudorandomly generated. The evaluators compute the message_
+_digest for each of the messages and ensure that the correct result is produced when the_
+_messages are provided to the TSF._
+
+
+_Test 23: Selected Long Messages Test: Byte-oriented Mode_
+_The evaluators devise an input set consisting of m/8 messages, where m is the block length_
+_of the hash algorithm. The length of the i_ _[th]_ _message is 512 + 8*99*i, where 1 โค i โค m/8. The_
+_message text shall be pseudorandomly generated. The evaluators compute the message_
+_digest for each of the messages and ensure that the correct result is produced when the_
+_messages are provided to the TSF._
+
+
+_Test 24: Pseudorandomly Generated Messages Test: Byte-oriented Mode_
+_This test is for byteโoriented implementations only. The evaluators randomly generate a seed_
+_that is n bits long, where n is the length of the message digest produced by the hash_
+_function to be tested. The evaluators then formulate a set of 100 messages and associated_
+_digests by following the algorithm provided in Figure 1 of SHAVS. The evaluators then_
+_ensure that the correct result is produced when the messages are provided to the TSF._
+
+
+**FCS_COP.1/SIGN Cryptographic Operation**
+
+
+FCS_COP.1.1/SIGN
+
+The TSF shall perform [ _cryptographic signature services (generation and_
+_verification)_ ] in accordance with a specified cryptographic algorithm [ **selection** :
+
+_[RSA schemes]_ _**using**_ _cryptographic key sizes of [2048-bit or greater] that_
+_meet the following: [FIPS PUB 186-4, "Digital Signature Standard (DSS)",_
+_Section 4]_
+
+_[ECDSA schemes]_ _**using**_ _["NIST curves" P-384 and [_ _**selection**_ _: P-256, P-_
+_521, no other curves ]] that meet the following: [FIPS PUB 186-4, "Digital_
+_Signature Standard (DSS)", Section 5]_
+
+].
+
+
+**Application Note:** The ST author should choose the algorithm implemented to
+perform digital signatures; if more than one algorithm is available, this
+requirement should be iterated to specify the functionality. For the algorithm
+chosen, the ST author should make the appropriate assignments/selections to
+specify the parameters that are implemented for that algorithm.
+
+
+**Evaluation Activities**
+
+
+_FCS_COP.1/SIGN_
+_**TSS**_
+_There are no TSS evaluation activities for this component._
+
+
+_**Guidance**_
+_There are no guidance evaluation activities for this component._
+
+
+_**Tests**_
+_**Evaluation Activity Note:**_ _The following tests require the developer to provide access to a test_
+_platform that provides the evaluator with tools that are typically not found on factory products._
+
+
+_Test 25:_ _**[conditional] If ECDSA schemes is selected in FCS_COP.1.1/SIGN**_
+
+_Test 25.1:_ _**ECDSA FIPS 186-4 Signature Generation Test**_
+_For each supported NIST curve (i.e. P-256, P-384 and P-521) and SHA function pair,_
+_the evaluator shall generate 10 1024-bit long messages and obtain for each message a_
+_public key and the resulting signature values R and S. To determine correctness, the_
+_evaluator shall use the signature verification function of a known good_
+_implementation._
+
+
+_Test 25.2:_ _**ECDSA FIPS 186-4 Signature Verification Test**_
+_For each supported NIST curve (i.e. P-256, P-384 and P-521) and SHA function pair,_
+_the evaluator shall generate a set of 10 1024-bit message, public key and signature_
+_tuples and modify one of the values (message, public key or signature) in five of the 10_
+_tuples. The evaluator shall obtain in response a set of 10 PASS/FAIL values._
+
+_Test 26:_ _**[conditional] If RSA schemes is selected in FCS_COP.1.1/SIGN**_
+
+_Test 26.1:_ _**Signature Generation Test**_
+
+
+_The evaluator shall verify the implementation of RSA Signature Generation by the TOE_
+_using the Signature Generation Test. To conduct this test the evaluator must generate_
+_or obtain 10 messages from a trusted reference implementation for each modulus_
+_size/SHA combination supported by the TSF. The evaluator shall have the TOE use_
+_their private key and modulus value to sign these messages._
+
+
+_The evaluator shall verify the correctness of the TSFโs signature using a known good_
+_implementation and the associated public keys to verify the signatures._
+
+
+_Test 26.2:_ _**Signature Verification Test**_
+_The evaluator shall perform the Signature Verification test to verify the ability of the_
+_TOE to recognize another partyโs valid and invalid signatures. The evaluator shall_
+_inject errors into the test vectors produced during the Signature Verification Test by_
+_introducing errors in some of the public keys e, messages, IR format, or signatures._
+_The TOE attempts to verify the signatures and returns success or failure._
+
+
+_The evaluator shall use these test vectors to emulate the signature verification test_
+_using the corresponding parameters and verify that the TOE detects these errors._
+
+
+**FCS_COP.1/KEYHMAC Cryptographic Operation**
+
+
+FCS_COP.1.1/KEYHMAC
+
+The TSF shall perform [ _keyed-hash message authentication_ ] in accordance with
+a specified cryptographic algorithm [ _HMAC-SHA-1 and [_ _**selection**_ _: HMAC-SHA-_
+_256, HMAC-SHA-384, HMAC-SHA-512, no other algorithms ]_ ] and cryptographic
+key sizes [ **assignment** : _key size (in bits) used in HMAC_ ] **and message digest**
+**sizes 160 and [selection:** _**256**_ **,** _**384**_ **,** _**512**_ **,** _**no other**_ **] bits** that meet the
+following: [ _FIPS Pub 198-1, "The Keyed-Hash Message Authentication Code",_
+_and FIPS Pub 180-4, "Secure Hash Standard"_ ].
+
+
+**Application Note:** The selection in this requirement must be consistent with
+the key size specified for the size of the keys used in conjunction with the keyedhash message authentication. HMAC-SHA-1 is currently required in order to
+[comply with the PP-Module for Wireless LAN Clients, version 1.0.](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=386&id=386)
+
+
+**Evaluation Activities**
+
+
+
+
+
+**FCS_COP.1/CONDITION Cryptographic Operation**
+
+
+FCS_COP.1.1/CONDITION
+
+The TSF shall perform **conditioning** in accordance with a specified
+cryptographic algorithm **HMAC-[selection:** _**SHA-256**_ **,** _**SHA-384**_ **,** _**SHA-512**_ **]**
+**using a salt, and [selection:** _**PBKDF2 with [assignment: number of**_
+_**iterations] iterations**_ **,** _**[assignment: key stretching function]**_ **,** _**no other**_
+_**function**_ **] and output** cryptographic key sizes **[selection:** _**128**_ **,** _**256**_ **]** that
+meet the following: **[selection:** _**NIST SP 800-132**_ **,** _**no standard**_ **].**
+
+
+**Application Note:** The key cryptographic key sizes in the third selection should
+be made to correspond to the KEK key sizes selected in FCS_CKM_EXT.3.
+
+
+This password must be conditioned into a string of bits that forms the submask
+to be used as input into the KEK. Conditioning can be performed using one of the
+identified hash functions and may include a key stretching function; the method
+used is selected by the ST author. If selected, NIST SP 800-132 requires the use
+of a pseudorandom function (PRF) consisting of HMAC with an approved hash
+
+
+function. The ST author selects the hash function used, also includes the
+appropriate requirements for HMAC and the hash function.
+
+
+Appendix A of NIST SP 800-132 recommends setting the iteration count in order
+to increase the computation needed to derive a key from a password and,
+therefore, increase the workload of performing a dictionary attack.
+
+
+**Evaluation Activities**
+
+
+
+
+
+**FCS_HTTPS_EXT.1 HTTPS Protocol**
+
+
+FCS_HTTPS_EXT.1.1
+
+The TSF shall implement the HTTPS protocol that complies with RFC 2818.
+
+
+FCS_HTTPS_EXT.1.2
+
+[The TSF shall implement HTTPS using TLS as defined in [](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=439&id=439) _the Functional_
+_Package for Transport Layer Security (TLS), version 1.1_ ].
+
+
+**Application Note:** The Functional Package for Transport Layer Security (TLS),
+[version 1.1 must be included in the ST, with the following selections made:](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=439&id=439)
+
+FCS_TLS_EXT.1:
+
+TLS must be selected
+Client must be selected
+
+
+FCS_HTTPS_EXT.1.3
+
+The TSF shall notify the application and [ **selection** : _not establish the connection_,
+_request application authorization to establish the connection_, _no other action_ ] if
+the peer certificate is deemed invalid.
+
+
+**Application Note:** Validity is determined by the certificate path, the expiration
+date, and the revocation status in accordance with RFC 5280.
+
+
+If not establish the connection is selected then "with no exceptions" must be
+[selected for FCS_TLSC_EXT.1.3 in the Functional Package for Transport Layer](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=439&id=439)
+Security (TLS), version 1.1. If request application authorization to establish the
+connection is selected then "except when override is authorized" must be
+selected for FCS_TLSC_EXT.1.3 in the Package for Transport Layer Security. If
+no other action is selected either selection can be made in FCS_TLSC_EXT.1.3.
+
+
+FMT_SMF.1 Function 23 configures whether to allow or disallow the
+establishment of a trusted channel if the peer certificate is deemed invalid.
+
+
+Validation Guidelines:
+
+
+**Rule #5**
+
+
+**Rule #6**
+
+
+**Evaluation Activities**
+
+
+_FCS_HTTPS_EXT.1_
+_**TSS**_
+_There are no TSS evaluation activities for this component._
+
+
+_**Guidance**_
+_There are no guidance evaluation activities for this component._
+
+
+_**Tests**_
+
+_Test 27: The evaluator shall attempt to establish an HTTPS connection with a webserver,_
+_observe the traffic with a packet analyzer, and verify that the connection succeeds and that_
+_the traffic is identified as TLS or HTTPS._
+
+
+_Other tests are performed in conjunction with testing in the Functional Package for_
+_Transport Layer Security (TLS), version 1.1._
+
+
+_Certificate validity shall be tested in accordance with testing performed for_
+_FIA_X509_EXT.1, and the evaluator shall perform the following test:_
+
+
+_Test 28: The evaluator shall demonstrate that using a certificate without a valid_
+_certification path results in an application notification. Using the administrative guidance,_
+_the evaluator shall then load a certificate or certificates to the Trust Anchor Database_
+_needed to validate the certificate to be used in the function, and demonstrate that the_
+_function succeeds. The evaluator then shall delete one of the certificates, and show that the_
+_application is notified of the validation failure._
+
+
+**FCS_IV_EXT.1 Initialization Vector Generation**
+
+
+FCS_IV_EXT.1.1
+
+The TSF shall generate IVs in accordance with [ _Table 11: References and IV_
+_Requirements for NIST-approved Cipher Modes_ ].
+
+
+**Application Note:** Table 11 lists the requirements for composition of IVs
+according to the NIST Special Publications for each cipher mode. The
+composition of IVs generated for encryption according to a cryptographic
+protocol is addressed by the protocol. Thus, this requirement addresses only IVs
+generated for key storage and data storage encryption.
+
+
+**Evaluation Activities**
+
+
+**FCS_RBG_EXT.1 Random Bit Generation**
+
+
+FCS_RBG_EXT.1.1
+
+The TSF shall perform all deterministic random bit generation services in
+accordance with NIST Special Publication 800-90A using [ **selection** :
+_Hash_DRBG (any)_, _HMAC_DRBG (any)_, _CTR_DRBG (AES)_ ].
+
+
+FCS_RBG_EXT.1.2
+
+The deterministic RBG shall be seeded by an entropy source that accumulates
+entropy from [ **selection** : _a software-based noise source_, _TSF-hardware-based_
+_noise source_ ] with a minimum of [ **selection** : _128 bits_, _256 bits_ ] of entropy at
+least equal to the greatest security strength (according to NIST SP 800-57) of
+the keys and hashes that it will generate.
+
+
+FCS_RBG_EXT.1.3
+
+The TSF shall be capable of providing output of the RBG to applications running
+on the TSF that request random bits.
+
+
+**Application Note:** SP 800-90A contains three different methods of generating
+random numbers; each of these, in turn, depends on underlying cryptographic
+primitives (hash functions/ciphers). The ST author will select the function used,
+and include the specific underlying cryptographic primitives used in the
+requirement or in the TSS. While any of the identified hash functions (SHA-224,
+SHA-256, SHA-384, SHA-512) are allowed for Hash_DRBG or HMAC_DRBG, only
+
+
+AES-based implementations for CTR_DRBG are allowed.
+
+
+The ST author must also ensure that any underlying functions are included in the
+baseline requirements for the TOE.
+
+
+Health testing of the DRBGs is performed in conjunction with the self-tests
+required in FPT_TST_EXT.1.1.
+
+
+For the selection in FCS_RBG_EXT.1.2, the ST author selects the appropriate
+number of bits of entropy that corresponds to the greatest security strength of
+the algorithms included in the ST. Security strength is defined in Tables 2 and 3
+of NIST SP 800-57A. For example, if the implementation includes 2048-bit RSA
+(security strength of 112 bits), AES 128 (security strength 128 bits), and HMACSHA-256 (security strength 256 bits), then the ST author would select 256 bits.
+
+
+The ST author may select either software or hardware noise sources. A hardware
+noise source is a component that produces data that cannot be explained by a
+deterministic rule, due to its physical nature. In other words, a hardware based
+noise source generates sequences of random numbers from a physical process
+that cannot be predicted. For example, a sampled ring oscillator consists of an
+odd number of inverter gates chained into a loop, with an electrical pulse
+traveling from inverter to inverter around the loop. The inverters are not
+clocked, so the precise time required for a complete circuit around the loop
+varies slightly as various physical effects modify the small delay time at each
+inverter on the line to the next inverter. This variance results in an approximate
+natural frequency that contains drift and jitter over time. The output of the ring
+oscillator consists of the oscillating binary value sampled at a constant rate from
+one of the inverters โ a rate that is significantly slower than the oscillatorโs
+natural frequency.
+
+
+**Evaluation Activities**
+
+
+_FCS_RBG_EXT.1_
+_**Entropy Documentation**_
+_Documentation shall be produced and the evaluator shall perform the activities in accordance_
+_with Appendix F - Entropy Documentation And Assessment, the "Clarification to the Entropy_
+_Documentation and Assessment"._
+
+
+_**API Documentation**_
+_The evaluator shall verify that the API documentation provided according to Section 5.2.2 Class_
+_ADV: Development, includes the security functions described in FCS_RBG_EXT.1.3._
+
+
+_**TSS**_
+_There are no TSS evaluation activities for this component._
+
+
+_**Guidance**_
+_The evaluator shall also confirm that the operational guidance contains appropriate instructions_
+_for configuring the RNG functionality._
+
+
+_**Tests**_
+_**Evaluation Activity Note:**_ _The following tests require the developer to provide access to a test_
+_platform that provides the evaluator with tools that are typically not found on factory products._
+
+
+_The evaluator shall perform 15 trials for the RNG implementation. If the RNG is configurable,_
+_the evaluator shall perform 15 trials for each configuration._
+
+
+_If the RNG has prediction resistance enabled, each trial consists of (1) instantiate DRBG, (2)_
+_generate the first block of random bits (3) generate a second block of random bits (4)_
+_uninstantiate. The evaluator verifies that the second block of random bits is the expected value._
+_The evaluator shall generate eight input values for each trial. The first is a count (0 โ 14). The_
+_next three are entropy input, nonce, and personalization string for the instantiate operation. The_
+_next two are additional input and entropy input for the first call to generate. The final two are_
+_additional input and entropy input for the second call to generate. These values are randomly_
+_generated. "generate one block of random bits" means to generate random bits with number of_
+_returned bits equal to the Output Block Length (as defined in NIST SP800-90A)._
+
+
+_If the RNG does not have prediction resistance, each trial consists of (1) instantiate DRBG, (2)_
+_generate the first block of random bits (3) reseed, (4) generate a second block of random bits (5)_
+_uninstantiate. The evaluator verifies that the second block of random bits is the expected value._
+_The evaluator shall generate eight input values for each trial. The first is a count (0 โ 14). The_
+_next three are entropy input, nonce, and personalization string for the instantiate operation. The_
+_fifth value is additional input to the first call to generate. The sixth and seventh are additional_
+_input and entropy input to the call to reseed. The final value is additional input to the second_
+_generate call._
+
+
+_The following paragraphs contain more information on some of the input values to be_
+
+
+_generated/selected by the evaluator._
+
+
+_**Entropy input:**_ _the length of the entropy input value must equal the seed length._
+_**Nonce:**_ _If a nonce is supported (CTR_DRBG with no Derivation Function does not use a_
+_nonce), the nonce bit length is one-half the seed length._
+_**Personalization string:**_ _The length of the personalization string must be ๏ฟฝ seed length. If_
+_the implementation only supports one personalization string length, then the same length_
+_can be used for both values. If more than one string length is support, the evaluator shall_
+_use personalization strings of two different lengths. If the implementation does not use a_
+_personalization string, no value needs to be supplied._
+_**Additional input:**_ _the additional input bit lengths have the same defaults and restrictions_
+_as the personalization string lengths._
+
+
+**FCS_SRV_EXT.1 Cryptographic Algorithm Services**
+
+
+FCS_SRV_EXT.1.1
+
+The TSF shall provide a mechanism for applications to request the TSF to
+perform the following cryptographic operations: [
+
+_All mandatory and [_ _**selection**_ _: selected algorithms, selected algorithms_
+_with the exception of ECC over curve 25519-based algorithms ] in_
+_FCS_CKM.2/LOCKED_
+_The following algorithms in FCS_COP.1/ENCRYPT: AES-CBC, [_ _**selection**_ _:_
+_AES Key Wrap, AES Key Wrap with Padding, AES-GCM, AES-CCM, no other_
+_modes ]_
+_All selected algorithms in FCS_COP.1/SIGN_
+_All mandatory and selected algorithms in FCS_COP.1/HASH_
+_All mandatory and selected algorithms in FCS_COP.1/KEYHMAC_
+
+_[_ _**selection**_ _:_
+
+_All mandatory and [_ _**selection**_ _: selected algorithms, selected algorithms_
+_with the exception of ECC over curve 25519-based algorithms ] in_
+_FCS_CKM.1_
+_The selected algorithms in FCS_COP.1_ _**/CONDITION**_
+_No other cryptographic operations_
+
+_]_
+
+].
+
+
+**Application Note:** For each of the listed FCS components in the bulleted list,
+the intent is that the TOE will make available all algorithms specified for that
+component in the ST. For example, if for FCS_COP.1/HASH the ST author selects
+SHA-256, then the TOE would have to make available an interface to perform
+SHA-1 (the "mandatory" portion of FCS_COP.1/HASH) and SHA-256 (the
+"selected" portion of FCS_COP.1/HASH).
+
+
+The exception is for FCS_COP.1/ENCRYPT. The TOE is not required to make
+available AES_CCMP, AES_XTS, AES_GCMP-256, or AES_CCMP_256 even
+though they may be implemented to perform TSF-related functions. It is
+acceptable for the platform to not provide AES Key Wrap (KW) and AES Key
+Wrap with Padding (KWP) to applications even if selected in
+FCS_COP.1/ENCRYPT. However, the ST author is expected to select AES-GCM
+or AES-CCM if it is selected in the ST for the FCS_COP.1/ENCRYPT component.
+
+
+**Evaluation Activities**
+
+
+
+
+**5.1.4 Cryptographic Storage (FCS_STG_EXT)**
+
+The following requirements describe how keys are protected. All keys must ultimately be protected by a REK,
+and may optionally be protected by the userโs authentication factor. Each keyโs confidentiality and integrity
+must be protected. This section also describes the secure key storage services to be provided by the Mobile
+Device for use by applications and users, applying the same level of protection for these keys as keys internal
+to the OS.
+
+
+**FCS_STG_EXT.1 Cryptographic Key Storage**
+
+
+FCS_STG_EXT.1.1
+
+The TSF shall provide [ **selection** : _mutable hardware_, _software-based_ ] secure
+key storage for asymmetric private keys and [ **selection** : _symmetric keys_,
+_persistent secrets_, _no other keys_ ].
+
+
+**Application Note:** A hardware keystore can be exposed to the TSF through a
+variety of interfaces, including embedded on the motherboard, USB, microSD,
+and Bluetooth.
+
+
+Immutable hardware is considered outside of this requirement and will be
+covered elsewhere.
+
+
+If the secure key storage is implemented in software that is protected as
+required by FCS_STG_EXT.2, the ST author must select software-based. If
+software-based is selected, the ST author must select all software-based key
+storage in FCS_STG_EXT.2.1.
+
+
+Support for secure key storage for all symmetric keys and persistent secrets will
+be required in future revisions.
+
+
+Validation Guidelines:
+
+
+**Rule #7**
+
+
+FCS_STG_EXT.1.2
+
+The TSF shall be capable of importing keys or secrets into the secure key
+storage upon request of [ **selection** : _the user_, _the administrator_ ] and [ **selection** :
+_applications running on the TSF_, _no other subjects_ ].
+
+
+**Application Note:** If the ST selects only the user, the ST author must select
+function 9 in FMT_MOF_EXT.1.1.
+
+
+FCS_STG_EXT.1.3
+
+The TSF shall be capable of destroying keys or secrets in the secure key storage
+upon request of [ **selection** : _the user_, _the administrator_ ].
+
+
+**Application Note:** If the ST selects the user, the ST author must select function
+10 in FMT_MOF_EXT.1.1.
+
+
+FCS_STG_EXT.1.4
+
+The TSF shall have the capability to allow only the application that imported the
+key or secret the use of the key or secret. Exceptions may only be explicitly
+authorized by [ **selection** : _the user_, _the administrator_, _a common application_
+_developer_ ].
+
+
+**Application Note:** If the ST selects the user or the administrator, the ST author
+must also select 34 in FMT_SMF.1.1. If the ST selects the user, the ST author
+must select function 34 in FMT_MOF_EXT.1.1.
+
+
+FCS_STG_EXT.1.5
+
+The TSF shall allow only the application that imported the key or secret to
+request that the key or secret be destroyed. Exceptions may only be explicitly
+authorized by [ **selection** : _the user_, _the administrator_, _a common application_
+_developer_ ].
+
+
+**Application Note:** If the ST selects the user or the administrator, the ST author
+must also select function 35 in FMT_SMF.1.1. If the ST selects only the user, the
+ST author must select function 35 in FMT_MOF_EXT.1.1.
+
+
+Validation Guidelines:
+
+
+**Rule #10**
+
+
+**Rule #11**
+
+
+**Evaluation Activities**
+
+
+_FCS_STG_EXT.1_
+_The evaluator shall verify that the API documentation provided according to Section 5.2.2 Class_
+_ADV: Development includes the security functions (import, use, and destruction) described in_
+_these requirements. The API documentation shall include the method by which applications_
+
+
+_restrict access to their keys or secrets in order to meet FCS_STG_EXT.1.4._
+
+
+_**TSS**_
+_The evaluator shall review the TSS to determine that the TOE implements the required secure_
+_key storage. The evaluator shall ensure that the TSS contains a description of the key storage_
+_mechanism that justifies the selection of "mutable hardware" or "software-based"._
+
+
+_**Guidance**_
+_The evaluator shall review the AGD guidance to determine that it describes the steps needed to_
+_import or destroy keys or secrets._
+
+
+_**Tests**_
+_The evaluator shall test the functionality of each security function:_
+
+_Test 29: The evaluator shall import keys or secrets of each supported type according to the_
+_AGD guidance. The evaluator shall write, or the developer shall provide access to, an_
+_application that generates a key or secret of each supported type and calls the import_
+_functions. The evaluator shall verify that no errors occur during import._
+
+
+_Test 30: The evaluator shall write, or the developer shall provide access to, an application_
+_that uses an imported key or secret:_
+
+_For RSA, the secret shall be used to sign data._
+_For ECDSA, the secret shall be used to sign data_
+
+
+_In the future additional types will be required to be tested:_
+
+_For symmetric algorithms, the secret shall be used to encrypt data._
+_For persistent secrets, the secret shall be compared to the imported secret._
+
+
+_The evaluator shall repeat this test with the application-imported keys or secrets and a_
+_different applicationโs imported keys or secrets. The evaluator shall verify that the TOE_
+_requires approval before allowing the application to use the key or secret imported by the_
+_user or by a different application:_
+
+_The evaluator shall deny the approvals to verify that the application is not able to use_
+_the key or secret as described._
+_The evaluator shall repeat the test, allowing the approvals to verify that the application_
+_is able to use the key or secret as described._
+
+
+_If the ST author has selected "common application developer", this test is performed by_
+_either using applications from different developers or appropriately (according to API_
+_documentation) not authorizing sharing._
+
+
+_Test 31: The evaluator shall destroy keys or secrets of each supported type according to the_
+_AGD guidance. The evaluator shall write, or the developer shall provide access to, an_
+_application that destroys an imported key or secret._
+
+
+_The evaluator shall repeat this test with the application-imported keys or secrets and a_
+_different applicationโs imported keys or secrets. The evaluator shall verify that the TOE_
+_requires approval before allowing the application to destroy the key or secret imported by_
+_the administrator or by a different application:_
+
+
+_The evaluator shall deny the approvals and verify that the application is still able to_
+_use the key or secret as described._
+_The evaluator shall repeat the test, allowing the approvals and verifying that the_
+_application is no longer able to use the key or secret as described._
+
+
+_If the ST author has selected "common application developer", this test is performed by_
+_either using applications from different developers or appropriately (according to API_
+_documentation) not authorizing sharing._
+
+
+**FCS_STG_EXT.2 Encrypted Cryptographic Key Storage**
+
+
+FCS_STG_EXT.2.1
+
+The TSF shall encrypt all DEKs, KEKs, [ **assignment** : _any long-term trusted_
+_channel key material_ ] and [ **selection** : _all software-based key storage_, _no other_
+_keys_ ] by KEKs that are [ **selection** :
+
+_Protected by the REK with [_ _**selection**_ _:_
+
+_encryption by a REK_
+_encryption by a KEK chaining from a REK_
+_encryption by a KEK that is derived from a REK_
+
+_]_
+_Protected by the REK and the password with [_ _**selection**_ _:_
+
+_encryption by a REK and the password-derived KEK_
+
+
+FCS_STG_EXT.2.2
+
+
+
+_encryption by a KEK chaining to a REK and the password-derived or_
+_biometric-unlocked KEK_
+_encryption by a KEK that is derived from a REK and the password-_
+_derived or biometric-unlocked KEK_
+
+_]_
+
+].
+
+
+**Application Note:** The ST author must select all software-based key storage if
+software-based is selected in FCS_STG_EXT.1.1. If the ST author selects mutable
+hardware in FCS_STG_EXT.1.1, the secure key storage is not subject to this
+requirement. REKs are not subject to this requirement.
+
+
+A REK and the password-derived KEK may be combined to form a combined KEK
+(as described in FCS_CKM_EXT.3) in order to meet this requirement.
+
+
+Software-based key storage must be protected by the password or biometric and
+REK.
+
+
+All keys must ultimately be protected by a REK. In particular, Figure 3 has KEKs
+protected according to these requirements: DEK_1 meets the "encryption by a
+REK and the password-derived KEK" case and would be appropriate for sensitive
+data, DEK_2 meets the "encryption by a KEK chaining from a REK" case and
+would not be appropriate for sensitive data, K_1 meets the "encryption by a
+REK" case and is not considered a sensitive key, and K_2 meets the "encryption
+by a KEK chaining to a REK and the password-derived or biometric-unlocked
+KEK" case and is considered a sensitive key.
+
+
+Long-term trusted channel key material includes Wi-Fi (PSKs), IPsec (PSKs and
+client certificates) and Bluetooth keys. These keys must not be protected by the
+password, as they may be necessary in the locked state. For clarity, the ST
+author must assign any Long-term trusted channel key material supported by the
+TOE . At a minimum, a TOE must support at least Wi-Fi and Bluetooth keys.
+
+
+Validation Guidelines:
+
+
+**Rule #7**
+
+
+DEKs, KEKs, [ **assignment** : _any long-term trusted channel key material_ ] and
+
+[ **selection** : _all software-based key storage_, _no other keys_ ] shall be encrypted
+using one of the following methods: [ **selection** :
+
+_using a SP800-56B key establishment scheme_
+_using AES in the [_ _**selection**_ _: Key Wrap (KW) mode, Key Wrap with Padding_
+_(KWP) mode, GCM, CCM, CBC mode ]_
+
+].
+
+
+**Application Note:** The ST author selects which key encryption schemes are
+used by the TOE. This requirement refers only to KEKs as defined this PP and
+does not refer to those KEKs specified in other standards. The ST author must
+assign the same Long-term trusted channel key material assigned in
+FCS_STG_EXT.2.1.
+
+
+
+**Evaluation Activities**
+
+
+_FCS_STG_EXT.2_
+_**TSS**_
+_The evaluator shall review the TSS to determine that the TSS includes key hierarchy description_
+_of the protection of each DEK for data-at-rest, of software-based key storage, of long-term_
+_trusted channel keys, and of KEK related to the protection of the DEKs, long-term trusted_
+_channel keys, and software-based key storage. This description must include a diagram_
+_illustrating the key hierarchy implemented by the TOE in order to demonstrate that the_
+_implementation meets FCS_STG_EXT.2. The description shall indicate how the functionality_
+_described by FCS_RBG_EXT.1 is invoked to generate DEKs (FCS_CKM_EXT.2), the key size_
+_(FCS_CKM_EXT.2 and FCS_CKM_EXT.3) for each key, how each KEK is formed (generated,_
+_derived, or combined according to FCS_CKM_EXT.3), the integrity protection method for each_
+_encrypted key (FCS_STG_EXT.3), and the IV generation for each key encrypted by the same KEK_
+_(FCS_IV_EXT.1). More detail for each task follows the corresponding requirement._
+
+
+_The evaluator shall also ensure that the documentation of the product's encryption key_
+_management is detailed enough that, after reading, the product's key management hierarchy is_
+_clear and that it meets the requirements to ensure the keys are adequately protected. The_
+_evaluator shall ensure that the documentation includes both an essay and one or more diagrams._
+_Note that this may also be documented as separate proprietary evidence rather than being_
+_included in the TSS._
+
+
+_The evaluator shall examine the key hierarchy description in the TSS section to verify that each_
+
+
+_DEK and software-stored key is encrypted according to FCS_STG_EXT.2._
+
+
+_**Guidance**_
+_There are no guidance evaluation activities for this component._
+
+
+_**Tests**_
+_There are no test evaluation activities for this component._
+
+
+**FCS_STG_EXT.3 Integrity of Encrypted Key Storage**
+
+
+FCS_STG_EXT.3.1
+
+The TSF shall protect the integrity of any encrypted DEKs and KEKs and
+
+[ **selection** : _long-term trusted channel key material_, _all software-based key_
+_storage_, _no other keys_ ] by [ **selection** :
+
+_[_ _**selection**_ _: GCM, CCM, Key Wrap, Key Wrap with Padding ] cipher mode_
+_for encryption according to FCS_STG_EXT.2_
+_a hash (FCS_COP.1_ _**/HASH**_ _) of the stored key that is encrypted by a key_
+_protected by FCS_STG_EXT.2_
+_a keyed hash (FCS_COP.1_ _**/KEYHMAC**_ _) using a key protected by a key_
+_protected by FCS_STG_EXT.2_
+_a digital signature of the stored key using an asymmetric key protected_
+_according to FCS_STG_EXT.2_
+_an immediate application of the key for decrypting the protected data_
+_followed by a successful verification of the decrypted data with previously_
+_known information_
+
+].
+
+
+**Application Note:** The ST author must assign the same Long-term trusted
+channel key material assigned in FCS_STG_EXT.2.1.
+
+
+FCS_STG_EXT.3.2
+
+The TSF shall verify the integrity of the [ **selection** : _hash_, _digital signature_, _MAC_
+] of the stored key prior to use of the key.
+
+
+**Application Note:** This requirement is not applicable to derived keys that are
+not stored. It is not expected that a single key will be protected from corruption
+by multiple of these methods; however, a product may use one integrityprotection method for one type of key and a different method for other types of
+keys. The explicit Evaluation Activities for each of the options will be addressed
+in each of the requirements (FCS_COP.1.1/HASH, FCS_COP.1.1/KEYHMAC).
+
+
+Key Wrapping must be implemented per SP800-38F.
+
+
+**Evaluation Activities**
+
+
+
+**5.1.5 Class: User Data Protection (FDP)**
+A subset of the User Data Protection focuses on protecting Data-At-Rest, namely FDP_DAR_EXT.1 and
+FDP_DAR_EXT.2. Three levels of data-at-rest protection are addressed: TSF data, Protected Data (and keys),
+and sensitive data. Table 6 addresses the level of protection required for each level of data-at-rest.
+
+
+**Table 6: Protection of Data Levels**
+
+
+**Data Level** **Protection Required**
+
+
+
+Protected
+Data
+
+
+Sensitive
+Data
+
+
+
+Protected data is encrypted while powered off. (FDP_DAR_EXT.1)
+
+
+Sensitive data is encrypted while in the locked state, in addition to while powered off.
+(FDP_DAR_EXT.2)
+
+
+
+All keys, protected data, and sensitive data must ultimately be protected by the REK. Sensitive data must be
+protected by the password in addition to the REK. In particular, Figure 3 has KEKs protected according to
+these requirements: DEK_1 would be appropriate for sensitive data, DEK_2 would not be appropriate for
+sensitive data, K_1 is not considered a sensitive key, and K_2 is considered a sensitive key.
+
+
+These requirements include a capability for encrypting sensitive data received while in the locked state,
+which may be considered a separate sub-category of sensitive data. This capability may be met by a key
+transport scheme (RSA) by using a public key to encrypt the DEK while protecting the corresponding private
+key with a password-derived or biometric-unlocked KEK.
+
+
+This capability may also be met by a key agreement scheme. To do so, the device generates a device-wide
+sensitive data asymmetric pair (the private key of which is protected by a password-derived or biometricunlocked KEK) and an asymmetric pair for the received sensitive data to be stored. In order to store the
+sensitive data, the device-wide public key and data private key are used to generate a shared secret, which
+can be used as a KEK or a DEK. The data private key and shared secret are cleared after the data is encrypted
+and the data public key stored. Thus, no key material is available in the locked state to decrypt the newly
+stored data. Upon unlock, the device-wide private key is decrypted and is used with each data public key to
+regenerate the shared secret and decrypt the stored data. Figure 4, below, illustrates this scheme.
+
+
+**Figure 4: Key Agreement Scheme for Encrypting Received Sensitive Data in the Locked State**
+
+
+**FDP_ACF_EXT.1 Access Control for System Services**
+
+
+FDP_ACF_EXT.1.1
+
+The TSF shall provide a mechanism to restrict the system services that are
+accessible to an application.
+
+
+**Application Note:** Examples of system services to which this requirement
+applies include:
+
+
+Obtain data from camera and microphone input devices
+Obtain current device location
+Retrieve credentials from system-wide credential store
+Retrieve contacts list / address book
+
+
+FDP_ACF_EXT.1.2
+
+
+
+Retrieve stored pictures
+Retrieve text messages
+Retrieve emails
+Retrieve device identifier information
+Obtain network access
+
+
+The TSF shall provide an access control policy that prevents [ **selection** :
+_application_, _groups of applications_ ] from accessing [ **selection** : _all_, _private_ ] data
+stored by other [ **selection** : _application_, _groups of applications_ ]. Exceptions may
+only be explicitly authorized for such sharing by [ **selection** : _the user_, _the_
+_administrator_, _a common application developer_, _no one_ ].
+
+
+**Application Note:** Application groups may be designated Enterprise or
+Personal. Applications installed by the user default to being in the Personal
+application group unless otherwise designated by the administrator in function
+43 of FMT_SMF.1.1. Applications installed by the administrator default to being
+in the Enterprise application group (this category includes applications that the
+user requests the administrator install, for instance by selecting the application
+for installation through an enterprise application catalog) unless otherwise
+designated by the administrator in function 43 of FMT_SMF.1.1. It is acceptable
+for the same application to have multiple instances installed, each in different
+application groups. Private data is defined as data that is accessible only by the
+application that wrote it. Private data is distinguished from data that an
+application may, by design, write to shared storage areas.
+
+
+If groups of applications is selected, FDP_ACF_EXT.2 must be included in the ST.
+
+
+
+**Evaluation Activities**
+
+
+_FDP_ACF_EXT.1.1_
+_**TSS**_
+_The evaluator shall ensure the TSS lists all system services available for use by an application._
+_The evaluator shall also ensure that the TSS describes how applications interface with these_
+_system services, and means by which these system services are protected by the TSF._
+
+
+_The TSS shall describe which of the following categories each system service falls in:_
+
+
+_1. No applications are allowed access_
+_2. Privileged applications are allowed access_
+_3. Applications are allowed access by user authorization_
+_4. All applications are allowed access_
+
+
+_Privileged applications include any applications developed by the TSF developer. The TSS shall_
+_describe how privileges are granted to third-party applications. For both types of privileged_
+_applications, the TSS shall describe how and when the privileges are verified and how the TSF_
+_prevents unprivileged applications from accessing those services._
+
+
+_For any services for which the user may grant access, the evaluator shall ensure that the TSS_
+_identifies whether the user is prompted for authorization when the application is installed, or_
+_during runtime. The evaluator shall ensure that the operational user guidance contains_
+_instructions for restricting application access to system services._
+
+
+_**Guidance**_
+_There are no guidance evaluation activities for this element._
+
+
+_**Tests**_
+_**Evaluation Activity Note:**_ _The following tests require the vendor to provide access to a test_
+_platform that provides the evaluator with tools that are typically not found on consumer Mobile_
+_Device products._
+
+
+_The evaluator shall write, or the developer shall provide, applications for the purposes of the_
+_following tests._
+
+
+_Test 32: For each system service to which no applications are allowed access, the evaluator_
+_shall attempt to access the system service with a test application and verify that the_
+_application is not able to access that system service._
+_Test 33: For each system service to which only privileged applications are allowed access,_
+_the evaluator shall attempt to access the system service with an unprivileged application_
+_and verify that the application is not able to access that system service. The evaluator shall_
+_attempt to access the system service with a privileged application and verify that the_
+_application can access the service._
+_Test 34: For each system service to which the user may grant access, the evaluator shall_
+_attempt to access the system service with a test application. The evaluator shall ensure that_
+_either the system blocks such accesses or prompts for user authorization. The prompt for_
+_user authorization may occur at runtime or at installation time, and should be consistent_
+
+
+_with the behavior described in the TSS._
+_Test 35: For each system service listed in the TSS that is accessible by all applications, the_
+_evaluator shall test that an application can access that system service._
+
+
+_FDP_ACF_EXT.1.2_
+_**TSS**_
+_The evaluator shall examine the TSS to verify that it describes which data sharing is permitted_
+_between applications, which data sharing is not permitted, and how disallowed sharing is_
+_prevented. It is possible to select both "applications" and "groups of applications", in which case_
+_the TSS is expected to describe the data sharing policies that would be applied in each case._
+
+
+_**Guidance**_
+_There are no guidance evaluation activities for this element._
+
+
+_**Tests**_
+
+_Test 36: The evaluator shall write, or the developer shall provide, two applications, one that_
+_saves data containing a unique string and the other, which attempts to access that data. If_
+_groups of applications is selected, the applications shall be placed into different groups. If_
+_application is selected, the evaluator shall install the two applications. If private is selected,_
+_the application shall not write to a designated shared storage area. The evaluator shall_
+_verify that the second application is unable to access the stored unique string._
+
+
+_If the user is selected, the evaluator shall grant access as the user and verify that the_
+_second application is able to access the stored unique string._
+
+
+_If the administrator is selected, the evaluator shall grant access as the administrator and_
+_verify that the second application is able to access the stored unique string._
+
+
+_If a common application developer is selected, the evaluator shall grant access to an,_
+_application with a common application developer to the first, and verify that the application_
+_is able to access the stored unique string._
+
+
+**FDP_DAR_EXT.1 Protected Data Encryption**
+
+
+FDP_DAR_EXT.1.1
+
+Encryption shall cover all protected data.
+
+
+**Application Note:** Protected data is all non-TSF data, including all user or
+enterprise data. Some or all of this data may be considered sensitive data as
+well.
+
+
+FDP_DAR_EXT.1.2
+
+Encryption shall be performed using DEKs with AES in the [ **selection** : _XTS_,
+_CBC_, _GCM_ ] mode with key size [ **selection** : _128_, _256_ ] bits.
+
+
+**Application Note:** IVs must be generated in accordance with FCS_IV_EXT.1.1.
+
+
+**Evaluation Activities**
+
+
+**FDP_DAR_EXT.2 Sensitive Data Encryption**
+
+
+FDP_DAR_EXT.2.1
+
+The TSF shall provide a mechanism for applications to mark data and keys as
+sensitive.
+
+
+**Application Note:** Data and keys that have been marked as sensitive will be
+subject to certain restrictions (through other requirements) in both the locked
+and unlocked states of the Mobile Device. This mechanism allows an application
+to choose those data and keys under its control to be subject to those
+requirements.
+
+
+In the future, this PP may require that all data and key created by applications
+will default to the "sensitive" marking, requiring an explicit "non-sensitive"
+marking rather than an explicit "sensitive" marking.
+
+
+FDP_DAR_EXT.2.2
+
+The TSF shall use an asymmetric key scheme to encrypt and store sensitive data
+received while the product is locked.
+
+
+**Application Note:** Sensitive data is encrypted according to FDP_DAR_EXT.1.2.
+The asymmetric key scheme must be performed in accordance with
+FCS_CKM.2/LOCKED.
+
+
+The intent of this requirement is to allow the device to receive sensitive data
+while locked and to store the received data in such a way as to prevent
+unauthorized parties from decrypting it while in the locked state. If only a subset
+of sensitive data may be received in the locked state, this subset must be
+described in the TSS.
+
+
+Key material must be cleared when no longer needed according to
+FCS_CKM_EXT.4. For keys (or key material used to derive those keys) protecting
+sensitive data received in the locked state, "no longer needed" includes "while in
+the locked state." For example, in the first key scheme, this includes the DEK
+protecting the received data as soon as the data is encrypted. In the second key
+scheme this includes the private key for the data asymmetric pair, the generated
+shared secret, and any generated DEKs. Of course, both schemes require that a
+private key of an asymmetric pair (the RSA private key and the device-wide
+private key, respectively) be cleared when transitioning to the locked state.
+
+
+FDP_DAR_EXT.2.3
+
+The TSF shall encrypt any stored symmetric key and any stored private key of
+the asymmetric keys used for the protection of sensitive data according to
+
+[ _FCS_STG_EXT.2.1 selection 2_ ].
+
+
+**Application Note:** Symmetric keys used to encrypt sensitive data while the TSF
+is in the unlocked state must be encrypted with (or chain to a KEK encrypted
+with) the REK and password-derived or biometric-unlocked KEK. A stored
+private key of the asymmetric key scheme for encrypting data in the locked state
+must be encrypted with (or chain to a KEK encrypted with) the REK and
+password-derived or biometric-unlocked KEK.
+
+
+FDP_DAR_EXT.2.4
+
+The TSF shall decrypt the sensitive data that was received while in the locked
+state upon transitioning to the unlocked state using the asymmetric key scheme
+and shall re-encrypt that sensitive data using the symmetric key scheme.
+
+
+**Evaluation Activities**
+
+
+_FDP_DAR_EXT.2.1_
+_**TSS**_
+_The evaluator shall verify that the TSS includes a description of which data stored by the TSF_
+_(such as by native applications) is treated as sensitive. This data may include all or some user or_
+_enterprise data and must be specific regarding the level of protection of email, contacts,_
+_calendar appointments, messages, and documents._
+
+
+_The evaluator shall examine the TSS to determine that it describes the mechanism that is_
+_provided for applications to use to mark data and keys as sensitive. This description shall also_
+_contain information reflecting how data and keys marked in this manner are distinguished from_
+_data and keys that are not (for instance, tagging, segregation in a "special" area of memory or_
+_container, etc.)._
+
+
+_**Guidance**_
+_There are no guidance evaluation activities for this element._
+
+
+_**Tests**_
+_The evaluator shall enable encryption of sensitive data and require user authentication_
+_according to the AGD guidance. The evaluator shall try to access and create sensitive data (as_
+_defined in the ST and either by creating a file or using an application to generate sensitive data)_
+_in order to verify that no other user interaction is required._
+
+
+_FDP_DAR_EXT.2.2_
+_**TSS**_
+_The evaluator shall review the TSS section of the ST to determine that the TSS includes a_
+_description of the process of receiving sensitive data while the device is in a locked state. The_
+_evaluator shall also verify that the description indicates if sensitive data that may be received in_
+_the locked state is treated differently than sensitive data that cannot be received in the locked_
+_state. The description shall include the key scheme for encrypting and storing the received data,_
+_which must involve an asymmetric key and must prevent the sensitive data-at-rest from being_
+_decrypted by wiping all key material used to derive or encrypt the data (as described in the_
+_application note). The introduction to this section provides two different schemes that meet the_
+_requirements, but other solutions may address this requirement._
+
+
+_**Guidance**_
+_There are no guidance evaluation activities for this element._
+
+
+_**Tests**_
+_The evaluator shall perform the tests in FCS_CKM_EXT.4 for all key material no longer needed_
+_while in the locked state and shall ensure that keys for the asymmetric scheme are addressed in_
+_the tests performed when transitioning to the locked state._
+
+
+_FDP_DAR_EXT.2.3_
+_**TSS**_
+_The evaluator shall verify that the key hierarchy section of the TSS required for_
+_FCS_STG_EXT.2.1 includes the symmetric encryption keys (DEKs) used to encrypt sensitive_
+_data. The evaluator shall ensure that these DEKs are encrypted by a key encrypted with (or_
+_chain to a KEK encrypted with) the REK and password-derived or biometric-unlocked KEK._
+
+
+_The evaluator shall verify that the TSS section of the ST that describes the asymmetric key_
+_scheme includes the protection of any private keys of the asymmetric pairs. The evaluator shall_
+_ensure that any private keys that are not wiped and are stored by the TSF are stored encrypted_
+_by a key encrypted with (or chain to a KEK encrypted with) the REK and password-derived or_
+_biometric-unlocked KEK._
+
+
+_The evaluator shall also ensure that the documentation of the product's encryption key_
+_management is detailed enough that, after reading, the product's key management hierarchy is_
+_clear and that it meets the requirements to ensure the keys are adequately protected. The_
+_evaluator shall ensure that the documentation includes both an essay and one or more diagrams._
+_Note that this may also be documented as separate proprietary evidence rather than being_
+_included in the TSS._
+
+
+_**Guidance**_
+_There are no guidance evaluation activities for this element._
+
+
+_**Tests**_
+_There are no test evaluation activities for this element._
+
+
+_FDP_DAR_EXT.2.4_
+_**TSS**_
+_The evaluator shall verify that the TSS section of the ST that describes the asymmetric key_
+_scheme includes a description of the actions taken by the TSF for the purposes of DAR upon_
+_transitioning to the unlocked state. These actions shall minimally include decrypting all received_
+_data using the asymmetric key scheme and re-encrypting with the symmetric key scheme used_
+_to store data while the device is unlocked._
+
+
+_**Guidance**_
+_There are no guidance evaluation activities for this element._
+
+
+_**Tests**_
+_There are no test evaluation activities for this element._
+
+
+**FDP_IFC_EXT.1 Subset Information Flow Control**
+
+
+FDP_IFC_EXT.1.1
+
+The TSF shall [ **selection** :
+
+
+_provide an interface which allows a VPN client to protect all IP traffic using_
+_IPsec_
+_provide a VPN client which can protect all IP traffic using IPsec_ _**as defined**_
+_**in the PP-Module for Virtual Private Network (VPN) Clients, version**_
+_**2.4**_
+
+] with the exception of IP traffic needed to manage the VPN connection, and
+
+[ **selection** : _[_ _**assignment**_ _: traffic needed for correct functioning of the TOE]_, _no_
+_other traffic_ ], when the VPN is enabled.
+
+
+**Application Note:** Typically, the traffic needed to manage the VPN connection
+is referred to as "Control Plane" traffic; whereas, the IP traffic protected by the
+IPsec VPN is referred to as "Data Plane" traffic. All "Data Plane" traffic must flow
+through the VPN connection and the VPN must not split-tunnel. โIP traffic
+needed for correct functioning of the TOEโ comprises traffic that would prevent
+the TOE from proper operation if it was either blocked by or routed through the
+VPN. Enabling the VPN means that the VPN client has been activated by the
+user. If the VPN tunnel gets interrupted, then no โData Planeโ traffic should be
+sent without the VPN tunnel being re-established or the user disabling the VPN
+client.
+
+
+If no native IPsec client is validated or third-party VPN clients may also
+implement the required Information Flow Control, the first option must be
+selected. In these cases, the TOE provides an API to third-party VPN clients that
+allow them to configure the TOEโs network stack to perform the required
+Information Flow Control.
+
+
+The ST author must select the second option if the TSF implements a native VPN
+client (IPsec is selected in FTP_ITC_EXT.1.1). Thus the TSF must be validated
+[against the PP-Module for Virtual Private Network (VPN) Clients, version 2.4 and](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=467&id=467)
+[the ST author must also include FDP_IFC_EXT.1 from the PP-Module for Virtual](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=467&id=467)
+Private Network (VPN) Clients, version 2.4.
+
+
+It is optional for the VPN client to be configured to be always-on per FMT_SMF.1
+Function 45. Always-on means the establishment of an IPsec trusted channel to
+allow any communication by the TSF.
+
+
+**Evaluation Activities**
+
+
+_FDP_IFC_EXT.1_
+_**TSS**_
+_The evaluator shall verify that the TSS section of the ST describes the routing of IP traffic_
+_through processes on the TSF when a VPN client is enabled. The evaluator shall ensure that the_
+_description indicates which traffic does not go through the VPN and which traffic does. The_
+_evaluator shall verify that a configuration exists for each baseband protocol in which only the_
+_traffic identified by the ST author as necessary for establishing the VPN connection (IKE traffic_
+_and perhaps HTTPS or DNS traffic) or needed for the correct functioning of the TOE is not_
+_encapsulated by the VPN protocol (IPsec). The evaluator shall verify that the TSS section_
+_describes any differences in the routing of IP traffic when using any supported baseband_
+_protocols (e.g. Wi-Fi or, LTE)._
+
+
+_**Guidance**_
+_The evaluator shall verify that one (or more) of the following options is addressed by the_
+_documentation:_
+
+_The description above indicates that if a VPN client is enabled, all configurations route all_
+_Data Plane traffic through the tunnel interface established by the VPN client._
+_The AGD guidance describes how the user or administrator can configure the TSF to meet_
+_this requirement._
+_The API documentation includes a security function that allows a VPN client to specify this_
+_routing._
+
+
+_**Tests**_
+
+_Test 38: If the ST author identifies any differences in the routing between Wi-Fi and cellular_
+_protocols, the evaluator shall repeat this test with a base station implementing one of the_
+_identified cellular protocols._
+
+
+_Step 1: The evaluator shall enable a Wi-Fi configuration as described in the AGD guidance_
+_(as required by FTP_ITC_EXT.1). The evaluator shall use a packet sniffing tool between the_
+_wireless access point and an Internet-connected network. The evaluator shall turn on the_
+_sniffing tool and perform actions with the device such as navigating to websites, using_
+_provided applications, and accessing other Internet resources. The evaluator shall verify_
+_that the sniffing tool captures the traffic generated by these actions, turn off the sniffing_
+_tool, and save the session data._
+
+
+_Step 2: The evaluator shall configure an IPsec VPN client that supports the routing_
+
+
+_specified in this requirement, and if necessary, configure the device to perform the routing_
+_specified as described in the AGD guidance. The evaluator shall ensure the test network is_
+_capable of sending any traffic identified as exceptions. The evaluator shall turn on the_
+_sniffing tool, establish the VPN connection, and perform the same actions with the device as_
+_performed in the first step, as well as ensuring that all exception traffic is generated. The_
+_evaluator shall verify that the sniffing tool captures traffic generated by these actions, turn_
+_off the sniffing tool, and save the session data._
+
+
+_Step 3: The evaluator shall examine the traffic from both step one and step two to verify_
+_that all Data Plane traffic is encapsulated by IPsec, modulo the exceptions identified in the_
+_SFR (if applicable). For each exception listed in the SFR, the evaluator shall verify that that_
+_traffic is allowed outside of the VPN tunnel. The evaluator shall examine the Security_
+_Parameter Index (SPI) value present in the encapsulated packets captured in Step two from_
+_the TOE to the Gateway and shall verify this value is the same for all actions used to_
+_generate traffic through the VPN. Note that it is expected that the SPI value for packets_
+_from the Gateway to the TOE is different than the SPI value for packets from the TOE to the_
+_Gateway. The evaluator shall be aware that IP traffic on the cellular baseband outside of_
+_the IPsec tunnel may be emanating from the baseband processor and shall verify with the_
+_manufacturer that any identified traffic is not emanating from the application processor._
+
+
+_Step 4: (Conditional: If ICMP is not listed as part of the IP traffic needed for the correct_
+_functioning of the TOE) The evaluator shall perform an ICMP echo from the TOE to the IP_
+_address of another device on the local wireless network and shall verify that no packets are_
+_sent using the sniffing tool. The evaluator shall attempt to send packets to the TOE outside_
+_the VPN tunnel (i.e. not through the VPN gateway), including from the local wireless_
+_network, and shall verify that the TOE discards them._
+
+
+**FDP_STG_EXT.1 User Data Storage**
+
+
+FDP_STG_EXT.1.1
+
+The TSF shall provide protected storage for the Trust Anchor Database.
+
+
+**Evaluation Activities**
+
+
+
+
+
+**FDP_UPC_EXT.1/APPS Inter-TSF User Data Transfer Protection (Applications)**
+
+
+FDP_UPC_EXT.1.1/APPS
+
+The TSF shall provide a means for non-TSF applications executing on the TOE to
+use [
+
+_Mutually authenticated TLS as defined in the Functional Package for_
+_Transport Layer Security (TLS), version 1.1,_
+_HTTPS,_
+
+_and [_ _**selection**_ _:_
+
+_[mutually authenticated DTLS as defined in the Functional Package for](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=439&id=439)_
+_Transport Layer Security (TLS), version 1.1_
+_[IPsec as defined in the PP-Module for Virtual Private Network (VPN)](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=467&id=467)_
+_Clients, version 2.4_
+_no other protocol_
+
+_]_ ] to provide a protected communication channel between the non-TSF
+application and another IT product that is logically distinct from other
+communication channels, provides assured identification of its end points,
+protects channel data from disclosure, and detects modification of the channel
+data.
+
+
+**Application Note:** The intent of this requirement is that one of the selected
+protocols is available for use by user applications running on the device for use
+in connecting to distant-end services that are not necessarily part of the
+
+
+FDP_UPC_EXT.1.2/APPS
+
+
+
+enterprise infrastructure. It should be noted that the FTP_ITC_EXT.1 requires
+that all TSF communications be protected using the protocols indicated in that
+requirement, so the protocols required by this component ride "on top of" those
+listed in FTP_ITC_EXT.1.
+
+
+It should also be noted that some applications are part of the TSF, and
+FTP_ITC_EXT.1 requires that TSF applications be protected by at least one of
+the protocols in first selection in FTP_ITC_EXT.1. It is not required to have two
+different implementations of a protocol, or two different protocols, to satisfy
+both this requirement (for non-TSF apps) and FTP_ITC_EXT.1 (for TSF apps), as
+long as the services specified are provided.
+
+
+The ST author must list which trusted channel protocols are implemented by the
+Mobile Device for use by non-TSF apps.
+
+
+The TSF must be validated against requirements from the Functional Package
+for Transport Layer Security (TLS), version 1.1, with the following selections
+made:
+
+FCS_TLS_EXT.1:
+
+TLS is selected
+Client is selected
+
+FCS_TLSC_EXT.1.1:
+
+The cipher suites selected must correspond with the algorithms and
+hash functions allowed in FCS_COP.1.
+Mutual authentication must be selected
+
+FCS_TLSC_EXT.1.3
+
+With no exceptions is selected.
+
+
+[If mutually authenticated DTLS as defined in the Functional Package for](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=439&id=439)
+Transport Layer Security (TLS), version 1.1 is selected, the TSF must be
+[validated against requirements from the Functional Package for Transport Layer](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=439&id=439)
+Security (TLS), version 1.1, with the following selections made:
+
+FCS_TLS_EXT.1:
+
+DTLS is selected
+Client is selected
+
+FCS_DTLSC_EXT.1.1:
+
+The cipher suites selected must correspond with the algorithms and
+hash functions allowed in FCS_COP.1.
+Mutual authentication must be selected
+
+FCS_DTLSC_EXT.1.3
+
+With no exceptions is selected.
+
+
+If the ST author selects IPsec as defined in the PP-Module for Virtual Private
+[Network (VPN) Clients, version 2.4, the TSF must be validated against the PP-](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=467&id=467)
+Module for Virtual Private Network (VPN) Clients.
+
+
+The TSF shall permit the non-TSF applications to initiate communication via the
+trusted channel.
+
+
+
+**Evaluation Activities**
+
+
+_FDP_UPC_EXT.1/APPS_
+_The evaluator shall verify that the API documentation provided according to Section 5.2.2 Class_
+_ADV: Development includes the security functions (protection channel) described in these_
+_requirements, and verify that the APIs implemented to support this requirement include the_
+_appropriate settings/parameters so that the application can both provide and obtain the_
+_information needed to assure mutual identification of the endpoints of the communication as_
+_required by this component._
+
+
+_**TSS**_
+_The evaluator shall examine the TSS to determine that it describes that all protocols listed in the_
+_TSS are specified and included in the requirements in the ST._
+
+
+_**Guidance**_
+_The evaluator shall confirm that the operational guidance contains instructions necessary for_
+_configuring the protocols selected for use by the applications._
+
+
+_**Tests**_
+_**Evaluation Activity Note:**_ _The following test requires the developer to provide access to a test_
+_platform that provides the evaluator with tools that are typically not found on consumer Mobile_
+
+
+_Device products._
+
+
+_The evaluator shall write, or the developer shall provide access to, an application that requests_
+_protected channel services by the TSF. The evaluator shall verify that the results from the_
+_protected channel match the expected results according to the API documentation. This_
+_application may be used to assist in verifying the protected channel Evaluation Activities for the_
+_protocol requirements. The evaluator shall also perform the following tests:_
+
+_Test 39: The evaluators shall ensure that the application is able to initiate communications_
+_with an external IT entity using each protocol specified in the requirement, setting up the_
+_connections as described in the operational guidance and ensuring that communication is_
+_successful._
+_Test 40: The evaluator shall ensure, for each communication channel with an authorized IT_
+_entity, the channel data are not sent in plaintext._
+
+
+**5.1.6 Class: Identification and Authentication (FIA)**
+
+
+**FIA_AFL_EXT.1 Authentication Failure Handling**
+
+
+FIA_AFL_EXT.1.1
+
+The TSF shall consider password and [ **selection** : _biometric in accordance with_
+_[the Biometric Enrollment and Verification, version 1.1](https://github.com/biometricITC/cPP-biometrics/blob/master/Protection%20Profile/BiocPP.adoc)_, _hybrid_, _no other_
+_mechanism_ ] as critical authentication mechanisms.
+
+
+**Application Note:** A critical authentication mechanism is one in which
+countermeasures are triggered (i.e. wipe of the device) when the maximum
+number of unsuccessful authentication attempts is exceeded, rendering the
+other factors unavailable.
+
+
+If no additional authentication mechanisms are selected in FIA_UAU.5.1, then no
+other mechanism must be selected. If an additional authentication mechanism is
+selected in FIA_UAU.5.1, then it must only be selected in FIA_AFL_EXT.1.1 if
+surpassing the authentication failure threshold for biometric data causes a
+countermeasure to be triggered regardless of the failure status of the other
+authentication mechanisms.
+
+
+If the TOE implements multiple Authentication Factor interfaces (for example, a
+DAR decryption interface, a lock screen interface, an auxiliary boot mode
+interface), this component applies to all available interfaces. For example, a
+password is a critical authentication mechanism regardless of if it is being
+entered at the DAR decryption interface or at a lock screen interface.
+
+
+FIA_AFL_EXT.1.2
+
+The TSF shall detect when a configurable positive integer within [ **assignment** :
+_range of acceptable values for each authentication mechanism_ ] of [ **selection** :
+_unique_, _non-unique_ ] unsuccessful authentication attempts occur related to last
+successful authentication for each authentication mechanism.
+
+
+**Application Note:** The positive integers is configured according to
+FMT_SMF.1.1 function 2.
+
+
+An unique authentication attempt is defined as any attempt to verify a password
+or biometric sample, in which the input is different from a previous attempt.
+"unique" must be selected if the authentication system increments the counter
+only for unique unsuccessful authentication attempts. For example, if the same
+incorrect password is attempted twice the authentication system increments the
+counter once. "non-unique" must be selected if the authentication system
+increments the counter for each unsuccessful authentication attempt, regardless
+of if the input is unique. For example, if the same incorrect password is
+attempted twice the authentication system increments the counter twice.
+
+
+If hybrid authentication (i.e. a combination of biometric and pin/password) is
+supported, a failed authentication attempt can be counted as a single attempt,
+even if both the biometric and pin/password were incorrect.
+
+
+If the TOE supports multiple authentication mechanisms per FIA_UAU.5.1, this
+component applies to all authentication mechanisms. It is acceptable for each
+authentication mechanism to utilize an independent counter or for multiple
+authentication mechanisms to utilize a shared counter. The interaction between
+the authentication factors in regards to the authentication counter must be in
+accordance with FIA_UAU.5.2.
+
+
+If the TOE implements multiple Authentication Factor interfaces (for example, a
+DAR decryption interface, a lock screen interface, an auxiliary boot mode
+interface), this component applies to all available interfaces. However, it is
+acceptable for each Authentication Factor interface to be configurable with a
+different number of unsuccessful authentication attempts.
+
+
+FIA_AFL_EXT.1.3
+
+
+FIA_AFL_EXT.1.4
+
+
+FIA_AFL_EXT.1.5
+
+
+FIA_AFL_EXT.1.6
+
+
+
+The TSF shall maintain the number of unsuccessful authentication attempts that
+have occurred upon power off.
+
+
+**Application Note:** The TOE may implement an Authentication Factor interface
+that precedes another Authentication Factor interface in the boot sequence (for
+example, a volume DAR decryption interface which precedes the lock screen
+interface) before the user can access the device. In this situation, because the
+user must successfully authenticate to the first interface to access the second,
+the number of unsuccessful authentication attempts need not be maintained for
+the second interface.
+
+
+When the defined number of unsuccessful authentication attempts has exceeded
+the maximum allowed for a given authentication mechanism, all future
+authentication attempts will be limited to other available authentication
+mechanisms, unless the given mechanism is designated as a critical
+authentication mechanism.
+
+
+**Application Note:** In accordance with FIA_AFL_EXT.1.3, this requirement also
+applies after the TOE is powered off and powered back on.
+
+
+When the defined number of unsuccessful authentication attempts for the last
+available authentication mechanism or single critical authentication mechanism
+has been surpassed, the TSF shall perform a wipe of all protected data.
+
+
+**Application Note:** Wipe is performed in accordance with FCS_CKM_EXT.5.
+Protected data is all non-TSF data, including all user or enterprise data. Some or
+all of this data may be considered sensitive data as well.
+
+
+If the TOE implements multiple Authentication Factor interfaces (for example, a
+DAR decryption interface, a lock screen interface, an auxiliary boot mode
+interface), this component applies to all available interfaces.
+
+
+The TSF shall increment the number of unsuccessful authentication attempts
+prior to notifying the user that the authentication was unsuccessful.
+
+
+**Application Note:** This requirement is to ensure that if power is cut to the
+device directly after an authentication attempt, the counter will be incremented
+to reflect that attempt.
+
+
+
+**Evaluation Activities**
+
+
+_FIA_AFL_EXT.1_
+_**TSS**_
+_The evaluator shall ensure that the TSS describes that a value corresponding to the number of_
+_unsuccessful authentication attempts since the last successful authentication is kept for each_
+_Authentication Factor interface. The evaluator shall ensure that this description also includes if_
+_and how this value is maintained when the TOE loses power, either through a graceful powered_
+_off or an ungraceful loss of power. The evaluator shall ensure that if the value is not maintained,_
+_the interface is after another interface in the boot sequence for which the value is maintained._
+
+
+_If the TOE supports multiple authentication mechanisms, the evaluator shall ensure that this_
+_description also includes how the unsuccessful authentication attempts for each mechanism_
+_selected in FIA_UAU.5.1 is handled. The evaluator shall verify that the TSS describes if each_
+_authentication mechanism utilizes its own counter or if multiple authentication mechanisms_
+_utilize a shared counter. If multiple authentication mechanisms utilize a shared counter, the_
+_evaluator shall verify that the TSS describes this interaction._
+
+
+_The evaluator shall confirm that the TSS describes how the process used to determine if the_
+_authentication attempt was successful. The evaluator shall ensure that the counter would be_
+_updated even if power to the device is cut immediately following notifying the TOE user if the_
+_authentication attempt was successful or not._
+
+
+_**Guidance**_
+_The evaluator shall verify that the AGD guidance describes how the administrator configures the_
+_maximum number of unique unsuccessful authentication attempts._
+
+
+_**Tests**_
+
+_Test 41: The evaluator shall configure the device with all authentication mechanisms_
+_selected in FIA_UAU.5.1. The evaluator shall perform the following tests for each available_
+_authentication interface:_
+
+
+_Test 1a: The evaluator shall configure the TOE, according to the AGD guidance, with a_
+
+
+_maximum number of unsuccessful authentication attempts. The evaluator shall enter the_
+_locked state and enter incorrect passwords until the wipe occurs. The evaluator shall verify_
+_that the number of password entries corresponds to the configured maximum and that the_
+_wipe is implemented._
+
+
+_Test 1b: [conditional] If the TOE supports multiple authentication mechanisms the previous_
+_test shall be repeated using a combination of authentication mechanisms confirming that_
+_the critical authentication mechanisms will cause the device to wipe and that when the_
+_maximum number of unsuccessful authentication attempts for a non-critical authentication_
+_mechanism is exceeded, the device limits authentication attempts to other available_
+_authentication mechanisms. If multiple authentication mechanisms utilize a shared counter,_
+_then the evaluator shall verify that the maximum number of unsuccessful authentication_
+_attempts can be reached by using each individual authentication mechanism and a_
+_combination of all authentication mechanisms that share the counter._
+
+
+_Test 42: The evaluator shall repeat test one, but shall power off (by removing the battery, if_
+_possible) the TOE between unsuccessful authentication attempts. The evaluator shall verify_
+_that the total number of unsuccessful authentication attempts for each authentication_
+_mechanism corresponds to the configured maximum and that the critical authentication_
+_mechanisms cause the device to wipe. Alternatively, if the number of authentication failures_
+_is not maintained for the interface under test, the evaluator shall verify that upon booting_
+_the TOE between unsuccessful authentication attempts another authentication factor_
+_interface is presented before the interface under test._
+
+
+**FIA_PMG_EXT.1 Password Management**
+
+
+FIA_PMG_EXT.1.1
+
+The TSF shall support the following for the Password Authentication Factor:
+
+
+1. Passwords shall be able to be composed of any combination of [ **selection** :
+
+_upper and lower case letters_, _[_ _**assignment**_ _: a character set of at least 52_
+_characters]_ ], numbers, and special characters: [ **selection** : _"!"_, _"@"_, _"#"_,
+_"$"_, _"%"_, _"^"_, _"&"_, _"*"_, _"("_, _")"_, _[_ _**assignment**_ _: other characters]_ ];
+2. Password length up to [ **assignment** : _an integer greater than or equal to 14_ ]
+
+characters shall be supported.
+
+
+**Application Note:** While some corporate policies require passwords of 14
+characters or better, the use of a REK for DAR protection and key storage
+protection and the anti-hammer requirement (FIA_TRT_EXT.1) addresses the
+threat of attackers with physical access using much smaller and less complex
+passwords.
+
+
+The ST author selects the character set: either the upper and lower case Basic
+Latin letters or another assigned character set containing at least 52 characters.
+The assigned character set must be well defined: either according to an
+international encoding standard (such as Unicode) or defined in the assignment
+by the ST author. The ST author also selects the special characters that are
+supported by the TOE; they may optionally list additional special characters
+supported using the assignment.
+
+
+**Evaluation Activities**
+
+
+
+
+
+**FIA_TRT_EXT.1 Authentication Throttling**
+
+
+FIA_TRT_EXT.1.1
+
+The TSF shall limit automated user authentication attempts by [ **selection** :
+_preventing authentication via an external port_, _enforcing a delay between_
+_incorrect authentication attempts_ ] for all authentication mechanisms selected in
+FIA_UAU.5.1. The minimum delay shall be such that no more than 10 attempts
+can be attempted per 500 milliseconds.
+
+
+**Application Note:** The authentication throttling applies to all authentication
+mechanisms selected in FIA_UAU.5.1. The user authentication attempts in this
+requirement are attempts to guess the Authentication Factor. The developer can
+implement the timing of the delays in the requirements using unequal or equal
+timing of delays. The minimum delay specified in this requirement provides
+defense against brute forcing.
+
+
+**Evaluation Activities**
+
+
+
+
+
+**FIA_UAU.5 Multiple Authentication Mechanisms**
+
+
+FIA_UAU.5.1
+
+The TSF shall provide **password and [selection:** _**biometric in accordance**_
+_**[with the Biometric Enrollment and Verification, version 1.1](https://github.com/biometricITC/cPP-biometrics/blob/master/Protection%20Profile/BiocPP.adoc)**_ **,** _**hybrid**_ **,** _**no**_
+_**other mechanism**_ **]** to support user authentication.
+
+
+**Application Note:** The TSF must support a Password Authentication Factor and
+may optionally implement a BAF. A hybrid authentication factor is where a user
+has to submit a combination of PIN/password and biometric sample where both
+have to pass and if either fails the user is not made aware of which factor failed.
+
+
+[If biometric in accordance with the Biometric Enrollment and Verification,](https://github.com/biometricITC/cPP-biometrics/blob/master/Protection%20Profile/BiocPP.adoc)
+version 1.1 or hybrid is selected, then the TSF must be validated against
+[requirements from the Biometric Enrollment and Verification, version 1.1.](https://github.com/biometricITC/cPP-biometrics/blob/master/Protection%20Profile/BiocPP.adoc)
+
+
+[If hybrid is selected, biometric in accordance with the Biometric Enrollment and](https://github.com/biometricITC/cPP-biometrics/blob/master/Protection%20Profile/BiocPP.adoc)
+Verification, version 1.1 does not need to be selected, but should be selected if
+the biometric authentication can be used independent of the hybrid
+authentication, i.e. without having to enter a PIN/password.
+
+
+The Password Authentication Factor is configured according to FIA_PMG_EXT.1.
+
+
+FIA_UAU.5.2
+
+The TSF shall authenticate any user's claimed identity according to the
+
+[ **assignment** : _rules describing how each authentication mechanism selected in_
+_FIA_UAU.5.1 provides authentication_ ].
+
+
+**Application Note:** Rules regarding how the authentication factors interact in
+terms of unsuccessful authentication are covered in FIA_AFL_EXT.1.
+
+
+**Evaluation Activities**
+
+
+_FIA_UAU.5_
+_**TSS**_
+_The evaluator shall ensure that the TSS describes each mechanism provided to support user_
+_authentication and the rules describing how the authentication mechanisms provide_
+_authentication._
+
+
+_Specifically, for all authentication mechanisms specified in FIA_UAU.5.1, the evaluator shall_
+_ensure that the TSS describes the rules as to how each authentication mechanism is used._
+_Example rules are how the authentication mechanism authenticates the user (i.e. how does the_
+
+
+_TSF verify that the correct password or biometric sample was entered), the result of a successful_
+_authentication (i.e. is the user input used to derive or unlock a key) and which authentication_
+_mechanism can be used at which authentication factor interfaces (i.e. if there are times, for_
+_example, after a reboot, that only specific authentication mechanisms can be used). If multiple_
+_[BAFs are claimed in FIA_MBV_EXT.1.1 in the Biometric Enrollment and Verification, version 1.1,](https://github.com/biometricITC/cPP-biometrics/blob/master/Protection%20Profile/BiocPP.adoc)_
+_the interaction between the BAFs must be described. For example, whether the multiple BAFs_
+_can be enabled at the same time._
+
+
+_**Guidance**_
+_The evaluator shall verify that configuration guidance for each authentication mechanism is_
+_addressed in the AGD guidance._
+
+
+_**Tests**_
+
+_Test 44: For each authentication mechanism selected in FIA_UAU.5.1, the evaluator shall_
+_enable that mechanism and verify that it can be used to authenticate the user at the_
+_specified authentication factor interfaces._
+_Test 45: For each authentication mechanism rule, the evaluator shall ensure that the_
+_authentication mechanisms behave accordingly._
+
+
+**FIA_UAU.6/CREDENTIAL Re-Authenticating (Credential Change)**
+
+
+FIA_UAU.6.1/CREDENTIAL
+
+The TSF shall re-authenticate the user **via the Password Authentication**
+**Factor** under the conditions [ _attempted change to any supported authentication_
+_mechanisms_ ].
+
+
+**Application Note:** The password authentication factor must be entered before
+either the password or biometric authentication factor, if selected in
+FIA_UAU.5.1, can be changed.
+
+
+**Evaluation Activities**
+
+
+
+
+
+**FIA_UAU.6/LOCKED Re-Authenticating (TSF Lock)**
+
+
+FIA_UAU.6.1/LOCKED
+
+The TSF shall re-authenticate the user **via an authentication factor defined**
+**in FIA_UAU.5.1** under the conditions **TSF-initiated lock, user-initiated lock,**
+
+**[assignment:** _**other conditions**_ **]** .
+
+
+**Application Note:** Depending on the selections made in FIA_UAU.5.1, either
+the password (at a minimum), biometric authentication or hybrid authentication
+mechanisms can be used to unlock the device. TSF-initiated and user-initiated
+locking is described in FTA_SSL_EXT.1.
+
+
+**Evaluation Activities**
+
+
+**FIA_UAU.7 Protected Authentication Feedback**
+
+
+FIA_UAU.7.1
+
+The TSF shall provide only [ _obscured feedback to the deviceโs display_ ] to the
+user while the authentication is in progress.
+
+
+**Application Note:** This applies to all authentication methods specified in
+FIA_UAU.5.1. The TSF may briefly (1 second or less) display each character or
+provide an option to allow the user to unmask the password; however, the
+password must be obscured by default.
+
+
+If biometric in accordance with the Biometric Enrollment and Verification,
+[version 1.1 is selected in FIA_UAU.5.1, the TSF must not display sensitive](https://github.com/biometricITC/cPP-biometrics/blob/master/Protection%20Profile/BiocPP.adoc)
+information regarding any BAF that could aid an adversary in identifying or
+spoofing the respective biometric characteristics of a given human user. While it
+is true that biometric samples, by themselves, are not secret, the analysis
+performed by the respective biometric algorithms, as well as output data from
+these biometric algorithms, is considered sensitive and must be kept secret.
+Where applicable, the TSF must not reveal or make public the reasons for
+authentication failure.
+
+
+**Evaluation Activities**
+
+
+_FIA_UAU.7_
+_**TSS**_
+_The evaluator shall ensure that the TSS describes the means of obscuring the authentication_
+_entry, for all authentication methods specified in FIA_UAU.5.1._
+
+
+_**Guidance**_
+_The evaluator shall verify that any configuration of this requirement is addressed in the AGD_
+_guidance and that the password is obscured by default._
+
+
+_**Tests**_
+
+_Test 55: The evaluator shall enter passwords on the device, including at least the Password_
+_Authentication Factor at lock screen, and verify that the password is not displayed on the_
+_device._
+_[Test 56: [conditional] If biometric in accordance with the Biometric Enrollment and](https://github.com/biometricITC/cPP-biometrics/blob/master/Protection%20Profile/BiocPP.adoc)_
+_Verification, version 1.1 is selected in FIA_UAU.5.1, for each BAF claimed in_
+_[FIA_MBV_EXT.1.1 in the Biometric Enrollment and Verification, version 1.1 the evaluator](https://github.com/biometricITC/cPP-biometrics/blob/master/Protection%20Profile/BiocPP.adoc)_
+_shall authenticate by producing a biometric sample at lock screen. As the biometric_
+
+
+_algorithms are performed, the evaluator shall verify that sensitive images, audio, or other_
+_information identifying the user are kept secret and are not revealed to the user._
+_Additionally, the evaluator shall produce a biometric sample that fails to authenticate and_
+_verify that the reasons for authentication failure (user mismatch, low sample quality, etc.)_
+_are not revealed to the user. It is acceptable for the BAF to state that it was unable to_
+_physically read the biometric sample, for example, if the sensor is unclean or the biometric_
+_sample was removed too quickly. However, specifics regarding why the presented biometric_
+_sample failed authentication shall not be revealed to the user._
+
+
+**FIA_UAU_EXT.1 Authentication for Cryptographic Operation**
+
+
+FIA_UAU_EXT.1.1
+
+The TSF shall require the user to present the Password Authentication Factor
+prior to decryption of protected data and encrypted DEKs, KEKs and [ **selection** :
+_long-term trusted channel key material_, _all software-based key storage_, _no other_
+_keys_ ] at startup.
+
+
+**Application Note:** The intent of this requirement is to prevent decryption of
+protected data before the user has authorized to the device using the Password
+Authentication Factor. The Password Authentication Factor is also required in
+order derive the key used to decrypt sensitive data, which includes softwarebased secure key storage.
+
+
+**Evaluation Activities**
+
+
+**FIA_UAU_EXT.2 Timing of Authentication**
+
+
+FIA_UAU_EXT.2.1
+
+The TSF shall allow [ **selection** : _[_ _**assignment**_ _: list of actions]_, _no actions_ ] on
+behalf of the user to be performed before the user is authenticated.
+
+
+FIA_UAU_EXT.2.2
+
+The TSF shall require each user to be successfully authenticated before allowing
+any other TSF-mediated actions on behalf of that user.
+
+
+**Application Note:** The security relevant actions allowed by unauthorized users
+in locked state must be listed. At a minimum the actions that correspond to the
+functions available to the user in FMT_SMF.1 and are allowed by unauthorized
+users in locked state should be listed. For example, if the user can enable/disable
+the camera per function 5 of FMT_SMF.1 and unauthorized users can take a
+picture when the device is in locked state, this action must be listed.
+
+
+**Evaluation Activities**
+
+
+
+
+
+**FIA_X509_EXT.1 X.509 Validation of Certificates**
+
+
+FIA_X509_EXT.1.1
+
+The TSF shall validate certificates in accordance with the following rules:
+
+RFC 5280 certificate validation and certificate path validation.
+The certificate path must terminate with a certificate in the Trust Anchor
+Database.
+The TSF shall validate a certificate path by ensuring the presence of the
+basicConstraints extension, that the CA flag is set to TRUE for all CA
+certificates, and that any path constraints are met.
+The TSF shall validate that any CA certificate includes caSigning purpose in
+the key usage field.
+The TSF shall validate the revocation status of the certificate using
+
+[ **selection** : _OCSP as specified in RFC 6960_, _CRL as specified in RFC 5759_,
+_an OCSP TLS Status Request Extension (OCSP stapling) as specified in RFC_
+_6066_, _OCSP TLS Multi-Certificate Status Request Extension (i.e., OCSP_
+_Multi-Stapling) as specified in RFC 6961_ ].
+The TSF shall validate the extendedKeyUsage field according to the
+following rules:
+
+Certificates used for trusted updates and executable code integrity
+verification shall have the Code Signing Purpose (id-kp 3 with OID
+1.3.6.1.5.5.7.3.3) in the extendedKeyUsage field.
+Server certificates presented for TLS shall have the Server
+Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the
+extendedKeyUsage field.
+Server certificates presented for EST shall have the CMC Registration
+Authority (RA) purpose (id-kp-cmcRA with OID 1.3.6.1.5.5.7.3.28) in
+the extendedKeyUsage field. [conditional]
+Client certificates presented for TLS shall have the Client
+Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the
+extendedKeyUsage field.
+OCSP certificates presented for OCSP responses shall have the OCSP
+Signing purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the
+extendedKeyUsage field. [conditional]
+
+
+**Application Note:** FIA_X509_EXT.1.1 lists the rules for validating certificates.
+The ST author must select whether revocation status is verified using OCSP or
+CRLs. OCSP stapling and OCSP multi-stapling only support TLS server
+certificate validation. If other certificate types are validated, either OCSP or CRL
+[should be claimed. The PP-Module for Wireless LAN Clients, version 1.0, to](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=386&id=386)
+which a MDF TOE must also conform, requires that certificates are used for
+EAP-TLS; this use requires that the extendedKeyUsage rules are verified.
+
+
+FIA_X509_EXT.1.2
+
+
+
+Certificates may optionally be used for trusted updates of system software and
+applications (FPT_TUD_EXT.2) and for integrity verification (FPT_TST_EXT.2(1))
+and, if implemented, must be validated to contain the Code Signing purpose
+extendedKeyUsage.
+
+
+While FIA_X509_EXT.1.1 requires that the TOE perform certain checks on the
+certificate presented by a TLS server, there are corresponding checks that the
+authentication server will have to perform on the certificate presented by the
+client; namely that the extendedKeyUsage field of the client certificate includes
+โClient Authenticationโ and that the key agreement bit (for the Diffie-Hellman
+ciphersuites) or the key encipherment bit (for RSA ciphersuites) be set.
+Certificates obtained for use by the TOE will have to conform to these
+requirements in order to be used in the enterprise. This check is required to
+[support EAP-TLS for the PP-Module for Wireless LAN Clients, version 1.0.](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=386&id=386)
+
+
+The TSF shall only treat a certificate as a CA certificate if the basicConstraints
+extension is present and the CA flag is set to TRUE.
+
+
+**Application Note:** This requirement applies to certificates that are used and
+processed by the TSF and restricts the certificates that may be added to the
+Trust Anchor Database.
+
+
+
+**Evaluation Activities**
+
+
+_FIA_X509_EXT.1_
+_**TSS**_
+_The evaluator shall ensure the TSS describes where the check of validity of the certificates takes_
+_place. The evaluator ensures the TSS also provides a description of the certificate path_
+_validation algorithm._
+
+
+_**Guidance**_
+_There are no guidance evaluation activities for this component._
+
+
+_**Tests**_
+_The tests described must be performed in conjunction with the other Certificate Services_
+_evaluation activities, including the use cases in FIA_X509_EXT.2.1 and FIA_X509_EXT.3. The_
+_tests for the extendedKeyUsage rules are performed in conjunction with the uses that require_
+_those rules. The evaluator shall create a chain of at least four certificates: the node certificate to_
+_be tested, two Intermediate CAs, and the self-signed Root CA._
+
+_Test 60: The evaluator shall demonstrate that validating a certificate without a valid_
+_certification path results in the function failing, for each of the following reasons, in turn:_
+
+_By establishing a certificate path in which one of the issuing certificates is not a CA_
+_certificate,_
+_By omitting the basicConstraints field in one of the issuing certificates,_
+_By setting the basicConstraints field in an issuing certificate to have CA=False,_
+_By omitting the CA signing bit of the key usage field in an issuing certificate, and_
+_By setting the path length field of a valid CA field to a value strictly less than the_
+_certificate path._
+
+_The evaluator shall then establish a valid certificate path consisting of valid CA certificates,_
+_and demonstrate that the function succeeds. The evaluator shall then remove trust in one of_
+_the CA certificates, and show that the function fails._
+
+
+_Test 61: The evaluator shall demonstrate that validating an expired certificate results in the_
+_function failing._
+
+
+_Test 62: The evaluator shall test that the TOE can properly handle revoked certificates-_
+_conditional on whether CRL, OCSP, OSCP stapling, or OCSP multi-stapling is selected; if_
+_multiple methods are selected, then the following tests shall be performed for each method:_
+
+
+_The evaluator shall test revocation of the node certificate._
+
+
+_The evaluator shall also test revocation of the intermediate CA certificate (i.e. the_
+_intermediate CA certificate should be revoked by the root CA). For the test of the WLAN_
+_use case, only pre-stored CRLs are used. If OCSP stapling per RFC 6066 is the only_
+_supported revocation method, this test is omitted._
+
+
+_The evaluator shall ensure that a valid certificate is used, and that the validation function_
+_succeeds. The evaluator then attempts the test with a certificate that has been revoked (for_
+_each method chosen in the selection) to ensure when the certificate is no longer valid that_
+_the validation function fails._
+
+
+_Test 63: If any OCSP option is selected, the evaluator shall configure the OCSP server or_
+_use a man-in-the-middle tool to present a certificate that does not have the OCSP signing_
+_purpose and verify that validation of the OCSP response fails. If CRL as specified in RFC_
+
+
+_5759 is selected, the evaluator shall configure the CA to sign a CRL with a certificate that_
+_does not have the cRLsign key usage bit set, and verify that validation of the CRL fails._
+
+
+_Test 64: The evaluator shall modify any byte in the first eight bytes of the certificate and_
+_demonstrate that the certificate fails to validate (the certificate will fail to parse correctly)._
+
+
+_Test 65: The evaluator shall modify any bit in the last byte of the signature algorithm of the_
+_certificate and demonstrate that the certificate fails to validate (the signature on the_
+_certificate will not validate)._
+
+
+_Test 66: The evaluator shall modify any byte in the public key of the certificate and_
+_demonstrate that the certificate fails to validate (the signature on the certificate will not_
+_validate)._
+
+
+_Test 67:_
+
+_Test 67.1: (Conditional on support for EC certificates as indicated in FCS_COP.1(3))._
+_The evaluator shall establish a valid, trusted certificate chain consisting of an EC leaf_
+_certificate, an EC Intermediate CA certificate not designated as a trust anchor, and an_
+_EC certificate designated as a trusted anchor, where the elliptic curve parameters are_
+_specified as a named curve. The evaluator shall confirm that the TOE validates the_
+_certificate chain._
+
+
+_Test 67.2: (Conditional on support for EC certificates as indicated in FCS_COP.1(3))._
+_The evaluator shall replace the intermediate certificate in the certificate chain for Test_
+_8a with a modified certificate, where the modified intermediate CA has a public key_
+_information field where the EC parameters uses an explicit format version of the_
+_Elliptic Curve parameters in the public key information field of the intermediate CA_
+_certificate from Test 8a, and the modified Intermediate CA certificate is signed by the_
+_trusted EC root CA, but having no other changes. The evaluator shall confirm the TOE_
+_treats the certificate as invalid._
+
+
+**FIA_X509_EXT.2 X.509 Certificate Authentication**
+
+
+FIA_X509_EXT.2.1
+
+The TSF shall use X.509v3 certificates as defined by RFC 5280 to support
+authentication for [ _mutually authenticated TLS as defined in the Functional_
+_Package for Transport Layer Security (TLS), version 1.1, HTTPS, [_ _**selection**_ _:_
+_IPsec in accordance with the PP-Module for Virtual Private Network (VPN)_
+_[Clients, version 2.4, mutually authenticated DTLS as defined in the Functional](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=467&id=467)_
+_Package for Transport Layer Security (TLS), version 1.1, no other protocol ]_ ] and
+
+[ **selection** : _code signing for system software updates_, _code signing for mobile_
+_applications_, _code signing for integrity verification_, _[_ _**assignment**_ _: other uses]_,
+_no additional uses_ ].
+
+
+**Application Note:** The ST authorโs first selection must match the selection of
+FDP_UPC_EXT.1.1/APPS and FTP_ITC_EXT.1.1.
+
+
+Certificates may optionally be used for trusted updates of system software
+(FPT_TUD_EXT.2.3) and mobile applications (FPT_TUD_EXT.6.1) and for
+integrity verification (FPT_TST_EXT.2.1/PREKERNEL and FPT_TST_EXT.3.1). If
+code signing for system software updates or code signing for mobile applications
+is selected FPT_TUD_EXT.4.1 must be included in the ST.
+
+
+If code signing for integrity verification is selected FPT_TST_EXT.3.1 must be
+included in the ST.
+
+
+If FPT_TUD_EXT.5.1 is included in the ST, code signing for mobile applications
+must be included in the selection.
+
+
+FIA_X509_EXT.2.2
+
+When the TSF cannot establish a connection to determine the revocation status
+of a certificate, the TSF shall [ **selection** : _allow the administrator to choose_
+_whether to accept the certificate in these cases_, _allow the user to choose_
+_whether to accept the certificate in these cases_, _accept the certificate_, _not_
+_accept the certificate_ ].
+
+
+**Application Note:** The TOE must not accept the certificate if it fails any of the
+other validation rules in FIA_X509_EXT.1. However, often a connection must be
+established to perform a verification of the revocation status of a certificate either to download a CRL or to perform OCSP. The selection is used to describe
+the behavior in the event that such a connection cannot be established (for
+example, due to a network error). If the TOE has determined the certificate is
+valid according to all other rules in FIA_X509_EXT.1, the behavior indicated in
+the selection must determine the validity. If allow the administrator to choose or
+allow the user to choose the administrator-configured or user-configured option
+
+
+is selected, the ST author must also select function 30 in FMT_SMF.1.
+
+
+The TOE may behave differently depending on the trusted channel; for example,
+in the case of WLAN where connections are unlikely to be established, the TOE
+may accept the certificate even though certificates are not accepted for other
+channels. The ST author should select all applicable behaviors.
+
+
+Validation Guidelines:
+
+
+**Rule #8**
+
+
+**Rule #9**
+
+
+**Evaluation Activities**
+
+
+
+
+
+**FIA_X509_EXT.3 Request Validation of Certificates**
+
+
+FIA_X509_EXT.3.1
+
+The TSF shall provide a certificate validation service to applications.
+
+
+FIA_X509_EXT.3.2
+
+The TSF shall respond to the requesting application with the success or failure
+of the validation.
+
+
+**Application Note:** In order to comply with all of the rules in FIA_X509_EXT.1,
+multiple API calls may be required; all of these calls should be clearly
+documented
+
+
+**Evaluation Activities**
+
+
+_FIA_X509_EXT.3_
+_The evaluator shall verify that the API documentation provided according to Section 5.2.2 Class_
+_ADV: Development includes the security function (certificate validation) described in this_
+_requirement. This documentation shall be clear as to which results indicate success and failure._
+
+
+_**TSS**_
+_There are no TSS evaluation activities for this component._
+
+
+_**Guidance**_
+_There are no guidance evaluation activities for this component._
+
+
+_**Tests**_
+_The evaluator shall write, or the developer shall provide access to, an application that requests_
+_certificate validation by the TSF. The evaluator shall verify that the results from the validation_
+_match the expected results according to the API documentation. This application may be used to_
+_verify that import, removal, modification, and validation are performed correctly according to_
+
+
+_the tests required by FDP_STG_EXT.1, FTP_ITC_EXT.1, FMT_SMF.1, and FIA_X509_EXT.1._
+
+
+**5.1.7 Class: Security Management (FMT)**
+Both the user and the administrator may manage the TOE. This administrator is likely to be acting remotely
+and could be the Mobile Device Management (MDM) Administrator acting through an MDM Agent.
+
+
+The Administrator is responsible for management activities, including setting the policy that is applied by the
+enterprise on the Mobile Device. These management functions are likely to be a different set than those
+management functions provided to the user. Management functions that are provided to the user and not the
+administrator are listed in FMT_MOF_EXT.1.1. Management functions for which the administrator may adopt
+a policy that restricts the user from performing that function are listed in FMT_MOF_EXT.1.2.
+
+
+Table 7 compares the management functions required by this Protection Profile in the following three
+requirements (FMT_MOF_EXT.1.1, FMT_MOF_EXT.1.2, and FMT_SMF.1).
+
+
+**FMT_MOF_EXT.1 Management of Security Functions Behavior**
+
+
+FMT_MOF_EXT.1.1
+
+The TSF shall restrict the ability to perform the functions [ _in column 4 of Table_
+_7_ ] to the user.
+
+
+**Application Note:** The functions that have an "M" in the fourth column are
+mandatory for this component, thus are restricted to the user, meaning that the
+administrator cannot manage those functions. The functions that have an "O" in
+the fourth column are optional and may be selected; and those functions with a
+"-" are not applicable and may not be selected. The ST author should select those
+security management functions that only the user may perform (i.e. the ones the
+administrator may not perform).
+
+
+The ST author may not select the same function in both FMT_MOF_EXT.1.1 and
+FMT_MOF_EXT.1.2. A function cannot contain an "M" in both column 4 and
+column 6.
+
+
+The ST author may use a table in the ST, indicating with clear demarcations (to
+be accompanied by an index) those functions that are restricted to the user
+(column 4). The ST author should iterate a row to indicate any variations in the
+selectable sub-functions or assigned values with respect to the values in the
+columns.
+
+
+For functions that are mandatory, any sub-functions not in a selection are also
+mandatory and any assignments must contain at least one assigned value. For
+non-selectable sub-functions in an optional function, all sub-functions outside a
+selection must be implemented in order for the function to be listed.
+
+
+FMT_MOF_EXT.1.2
+
+The TSF shall restrict the ability to perform the functions [ _in column 6 of Table_
+_7_ ] to the administrator when the device is enrolled and according to the
+administrator-configured policy.
+
+
+**Application Note:** As long as the device is enrolled in management, the
+administrator (of the enterprise) must be guaranteed that minimum security
+functions of the enterprise policy are enforced. Further restrictive policies can
+be applied at any time by the user on behalf of the user or other administrators.
+
+
+The functions that have an "M" in the sixth column are mandatory for this
+component; the functions that have an "O" in the sixth column are optional and
+may be selected; and those functions with a "-" in the sixth are not applicable
+and may not be selected.
+
+
+The ST author may not select the same function in both FMT_MOF_EXT.1.1 and
+FMT_MOF_EXT.1.2.
+
+
+The ST author should select those security management functions that the
+administrator may restrict. The ST author may use a table in the ST, indicating
+with clear demarcations (to be accompanied by an index) those functions that
+are and are not implemented with APIs for the administrator (as in column 5).
+Additionally, the ST author should demarcate which functions the user is
+prevented from accessing or performing (as in column 6). The ST author should
+iterate a row to indicate any variations in the selectable sub-functions or
+assigned values with respect to the values in the columns.
+
+
+For functions that are mandatory, any sub-functions not in a selection are also
+mandatory and any assignments must contain at least one assigned value. For
+non-selectable sub-functions in an optional function, all sub-functions outside the
+selection must be implemented in order for the function to be listed.
+
+
+**Evaluation Activities**
+
+
+**FMT_SMF.1 Specification of Management Functions**
+
+
+FMT_SMF.1.1
+
+The TSF shall be capable of performing the following management functions:
+
+
+**Table 7: Management Functions**
+
+
+Status Markers:
+M - Mandatory
+O - Optional/Objective
+
+
+
+**#** **Management Function** **Impl.** **User**
+**Only**
+
+
+
+**Admin** **Admin**
+
+**Only**
+
+
+
+
+
+
+
+2 configure session locking policy:
+
+Screen-lock enabled/disabled
+Screen lock timeout
+Number of authentication failures
+
+
+3 enable/disable the VPN protection:
+
+Across device
+
+[ **selection** :
+
+_on a per-app basis_
+_on a per-group of applications_
+_processes basis_
+
+
+
+M - M M
+
+
+M O O O
+
+
+_no other method_
+
+]
+
+
+4 enable/disable [ **assignment** : _list of all_
+_radios_ ]
+
+
+
+
+
+6 transition to the locked state
+
+
+8 configure application installation policy
+by
+
+[ **selection** :
+
+_restricting the sources of_
+_applications_
+_specifying a set of allowed_
+_applications based on_
+
+_[_ _**assignment**_ _: application_
+_characteristics] (an application_
+_allowlist)_
+_denying installation of_
+_applications_
+
+]
+
+
+10 destroy imported keys or secrets and
+
+[ **selection** : _no other keys or secrets_,
+
+_[_ _**assignment**_ _: list of other categories of_
+_keys or secrets]_ ] in the secure key
+storage
+
+
+12 remove imported X.509v3 certificates
+and [ **selection** : _no other X.509v3_
+_certificates_, _[_ _**assignment**_ _: list of other_
+_categories of X.509v3 certificates]_ ] in
+the Trust Anchor Database
+
+
+14 remove applications
+
+
+16 install applications
+
+
+18 enable/disable display notification in the
+locked state of: [ **selection** :
+
+_email notifications_
+_calendar appointments_
+_contact associated with phone call_
+_notification_
+_text message notification_
+
+_[_ _**assignment**_ _: other application-_
+_based notifications]_
+_all notifications_
+
+]
+
+
+20 enable removable mediaโs data-at-rest
+
+
+
+M O O O
+
+
+M - M
+
+M - M M
+
+
+M O O
+
+M O O
+
+M - M O
+
+
+M - M O
+
+
+M O O O
+
+
+M O O O
+
+
+protection
+
+
+
+
+
+22 enable/disable the use of [ **selection** :
+_Biometric Authentication Factor_, _Hybrid_
+_Authentication Factor_ ]
+
+
+24 enable/disable all data signaling over
+
+[ **assignment** : _list of externally accessible_
+_hardware ports_ ]
+
+
+26 enable/disable developer modes
+
+
+28 wipe Enterprise data
+
+
+30 configure whether to allow or disallow
+establishment of a trusted channel if the
+TSF cannot establish a connection to
+determine the validity of a certificate
+
+
+32 read audit logs kept by the TSF
+
+
+34 approve exceptions for shared use of
+keys or secrets by multiple applications
+
+
+36 configure the unlock banner
+
+
+38 retrieve TSF-software integrity
+verification values
+
+
+
+O O O O
+
+
+O O O O
+
+
+O O O O
+
+
+O O O
+
+O O O O
+
+
+O O O
+
+O O O O
+
+
+M - O O
+
+
+O O O O
+
+
+
+
+
+
+40 enable/disable backup of [ **selection** : _all_
+_applications_, _selected applications_,
+_selected groups of applications_,
+_configuration data_ ] to [ **selection** : _locally_
+_connected system_, _remote system_ ]
+
+
+
+
+
+
+
+42 approve exceptions for sharing data
+between [ **selection** : _applications_, _groups_
+_of applications_ ]
+
+
+44 unenroll the TOE from management
+
+
+
+O O O O
+
+
+O O O O
+
+
+O O O O
+
+
+O O O O
+
+
+
+
+
+
+
+46 revoke Biometric template
+
+
+
+**Application Note:** Table 7 compares the management functions required by
+this Protection Profile.
+
+
+The first column lists the management functions identified in the PP.
+
+
+In the following columns:
+
+โMโ means Mandatory
+โOโ means Optional/Objective
+'-' means that no value (M or O) can be assigned
+
+
+The third column ("Impl.") indicates whether the function is to be implemented.
+The ST author should select which Optional functions are implemented.
+
+
+The fourth column ("User Only") indicates functions that are to be restricted to
+the user (i.e. not available to the administrator).
+
+
+The fifth column ("Admin") indicates functions that are available to the
+administrator. The functions restricted to the user (column 4) cannot also be
+available to the administrator. Functions available to the administrator can still
+be available to the user, as long as the function is not restricted to the
+administrator (column 6). Thus, if the TOE must offer these functions to the
+administrator to perform, the fifth column must be selected.
+
+
+The sixth column (FMT_MOF_EXT.1.2) indicates whether the function is to be
+restricted to the administrator when the device is enrolled and the administrator
+applies the indicated policy. If the function is restricted to the administrator the
+function is not available to the user. This does not prevent the user from
+modifying a setting to make the function stricter, but the user cannot undo the
+configuration enforced by the administrator.
+
+
+The ST author may use a table in the ST, listing only those functions that are
+implemented. For functions that are mandatory, any sub-functions not in a
+selection are also mandatory and any assignments must contain at least one
+assigned value. For functions that are optional and contain an assignment or
+
+
+selection, at least one value must be assigned/selected to be included in the ST.
+For non-selectable sub-functions in an optional function, all sub-functions must
+be implemented in order for the function to be included. For functions with a
+"per-app basis" sub function and an assignment, the ST author must indicate
+which assigned features are manageable on a per-app basis and which are not by
+iterating the row.
+
+
+**Function-specific Application Notes:**
+
+
+Functions 3, 5, and 21 must be implemented on a device-wide basis but may
+also be implemented on a per-app basis or on a per-group of applications basis in
+which the configuration includes the list of applications or groups of applications
+to which the enable/disable applies.
+
+
+Function 3 addresses enabling and disabling the IPsec VPN only. The
+configuration of the VPN Client itself (with information such as VPN Gateway,
+[certificates, and algorithms) is addressed by the PP-Module for Virtual Private](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=467&id=467)
+Network (VPN) Clients, version 2.4. The administrator options should only be
+listed if the administrator can remotely enable/disable the VPN connection.
+
+
+Function 3 optionally allows the VPN to be configured per-app or per-groups of
+apps. If this configuration is selected, it does not void FDP_IFC_EXT.1. Instead
+FDP_IFC_EXT.1 is applied to the application or group of applications the VPN is
+applied to. In other words, all traffic destined for the VPN-enabled application or
+group of applications, must travel through the VPN, but traffic not destined for
+that application or group of applications can travel outside the VPN. When the
+VPN is configured across the device FDP_IFC_EXT.1 applies to all traffic and the
+VPN must not split tunnel.
+
+
+The assignment in function 4 consists of all radios present on the TSF, such as
+Wi-Fi, cellular, NFC, Bluetooth BR/EDR, and Bluetooth LE, which can be enabled
+and disabled. In the future, if both Bluetooth BR/EDR and Bluetooth LE are
+supported, they will be required to be enabled and disabled separately.
+Disablement of the cellular radio does not imply that the radio may not be
+enabled in order to place emergency phone calls; however, it is not expected
+that a device in "airplane mode", where all radios are disabled, will automatically
+(without authorization) turn on the cellular radio to place emergency calls.
+
+
+The assignment in function 5 consists of at least one audio or visual device, such
+as camera and microphone, which can be enabled and disabled by either the
+user or administrator. Disablement of the microphone does not imply that the
+microphone may not be enabled in order to place emergency phone calls. If
+certain devices are able to be restricted to the enterprise (either device-wide,
+per-app or per-group of applications) and others are able to be restricted to
+users, then this function should be iterated in the table with the appropriate
+table entries.
+
+
+Regarding functions 4 and 5, disablement of a particular radio or audio/visual
+device must be effective as soon as the TOE has power. Disablement must also
+apply when the TOE is booted into auxiliary boot modes, for example, associated
+with updates or backup. If the TOE supports states in which security
+management policy is inaccessible, for example, due to data-at-rest protection, it
+is acceptable to meet this requirement by ensuring that these devices are
+disabled by default while in these states. That these devices are disabled during
+auxiliary boot modes does not imply that the device (particularly the cellular
+radio) may not be enabled in order to perform emergency phone calls.
+
+
+Wipe of the TSF (function 7) is performed according to FCS_CKM_EXT.5.
+Protected data is all non-TSF data, including all user or enterprise data. Some or
+all of this data may be considered sensitive data as well.
+
+
+The selection in function 8 allows the ST author to select which mechanisms are
+available to the administrator through the MDM Agent to restrict the
+applications which the user may install. The ST author must state if application
+allowlist is applied device-wide or if it can be specified to apply to either the
+Enterprise or Personal applications.
+
+
+If the administrator can restrict the sources from which applications can be
+installed, the ST author selects "restricting the sources of applications".
+If the administrator can specify a allowlist of allowed applications, the ST
+author selects "application allowlist". The ST author should list any
+application characteristics (e.g. name, version, or developer) based on
+which the allowlist can be formed.
+If the administrator can prevent the user from installing additional
+applications, the ST author selects "denying installation of applications".
+
+
+In the future, function 12 may require destruction or disabling of any default
+trusted CA certificates, excepting those CA certificates necessary for continued
+operation of the TSF, such as the developerโs certificate. At this time, the ST
+author must indicate in the assignment whether pre-installed or any other
+
+
+category of X.509v3 certificates may be removed from the Trust Anchor
+Database.
+
+
+For function 13, the enrollment function may be installing an MDM agent and
+includes the policies to be applied to the device. It is acceptable for the user
+approval notice to require the user to intentionally opt to view the policies (for
+example, by "tapping" on a "View" icon) rather than listing the policies in full in
+the notice.
+
+
+For function 15, the administrator capability to update the system software may
+be limited to causing a prompt to the user to update rather than the ability to
+initiate the update itself. As the administrator is likely to be acting remotely,
+he/she would be unaware of inopportune situations, such as low power, which
+may cause the update to fail and the device to become inoperable. The user can
+refuse to accept the update in such situations. It is expected that system
+architects will be cognizant of this limitation and will enforce network access
+controls in order to enforce enterprise-critical updates.
+
+
+Function 16 addresses both installation and update. This protection profile does
+not distinguish between installation and update of applications because mobile
+devices typically completely overwrite the previous installation with a new
+installation during an application update.
+
+
+For function 17, "Enterprise applications" are those applications that belong to
+the Enterprise application group. Applications installed by the enterprise
+administrator (including automatic installation by the administrator after being
+requested by the user from a catalog of enterprise applications) are by default
+placed in the Enterprise application group unless an exception has been made in
+function 43 of FMT_SMF.1.1.
+
+
+If the display of notifications in the locked state is supported, the configuration
+of these notifications (function 18) must be included in the selection.
+
+
+Function 19 must be included in the selection if data-at-rest protection is not
+natively enabled.
+
+
+Function 20 is implicitly met if the TSF does not support removable media.
+
+
+For function 21, location services include location information gathered from
+GPS, cellular, and Wi-Fi.
+
+
+Function 22 must be included in the ST if the TOE contains a BAF. This selection
+must correspond with the selection made in FIA_UAU.5.1. If biometric in
+[accordance with the Biometric Enrollment and Verification, version 1.1 is](https://github.com/biometricITC/cPP-biometrics/blob/master/Protection%20Profile/BiocPP.adoc)
+selected in FIA_UAU.5.1, "Biometric Authentication Factor" must be selected
+and the user or admin must have the option to disable the use of it. If multiple
+[BAFs are claimed in FIA_MBV_EXT.1.1 in the Biometric Enrollment and](https://github.com/biometricITC/cPP-biometrics/blob/master/Protection%20Profile/BiocPP.adoc)
+Verification, version 1.1, this applies to all different modalities. If hybrid is
+selected in FIA_UAU.5.1 it must be selected and the user or admin must have
+the option to disable the use of it.
+
+
+Function 23 must be included in the ST if the function is configurable on the
+TOE for any of the trusted channels either mandated or selected in
+FTP_ITC_EXT.1.1 or FDP_UPC_EXT.1.1/APPS. The configuration can be different
+depending on the specific trusted channel(s) and they must be filled in for the
+assignment.
+
+
+The assignment in function 24 consists of all externally accessible hardware
+ports, such as USB, the SD card, and HDMI, whose data transfer capabilities can
+be enabled and disabled by either the user or administrator. Disablement of data
+transfer over an external port must be effective during and after boot into the
+normal operative mode of the device. If the TOE supports states in which
+configured security management policy is inaccessible, for example, due to dataat-rest protection, it is acceptable to meet this requirement by ensuring that
+data transfer is disabled by default while in these states. Each of the ports may
+be enabled or disabled separately. The configuration policy need not disable all
+ports together. In the case of USB, charging is still allowed if data transfer
+capabilities have been disabled.
+
+
+The assignment in function 25 consists of all protocols where the TSF acts as a
+server, which can be enabled and disabled by either the user or administrator.
+
+
+Function 26 must be included in the selection if developer modes are supported
+by the TSF.
+
+
+Function 27 must be included in the selection if bypass of local user
+authentication, such as a "Forgot Password", password hint, or remote
+authentication feature, is supported.
+
+
+Function 29 must be included in the selection if the TSF allows applications,
+other than the MDM Agents, to import or remove X.509v3 certificates from the
+Trust Anchor Database. The MDM Agent is considered the administrator. This
+function does not apply to applications trusting a certificate for its own
+validations. The function only applies to situations where the application
+modifies the device-wide Trust Anchor Database, affecting the validations
+
+
+performed by the TSF for other applications. The user or administrator may be
+provided the ability to globally allow or deny any application requests in order to
+meet this requirement.
+
+
+Function 30 must be included in the ST if "administrator-configured option" is
+selection in FIA_X509_EXT.2.2.
+
+
+Function 33 should be included in the selection if FPT_TUD_EXT.5.1 is included
+in the ST and the configurable option is selected.
+
+
+Function 34 should be included in the selection if user or administrator is
+selected in FCS_STG_EXT.1.4.
+
+
+Function 35 should be included in the selection if the user or the administrator is
+selected in FCS_STG_EXT.1.5.
+
+
+Function 37 must be included in the selection if FAU_SEL.1 is included in the ST.
+
+
+For function 41, hotspot functionality refers to the condition in which the mobile
+device is serving as an access point to other devices, not the connection of the
+TOE to external hotspots.
+
+
+Functions 42 and 43 correspond to FDP_ACF_EXT.1.2.
+
+
+For function 44, FMT_SMF_EXT.2.1 specifies actions to be performed when the
+TOE is unenrolled from management.
+
+
+Function 45 must be included in the ST if IPsec is selected in FTP_ITC_EXT.1
+and the native IPsec VPN client can be configured to be Always-On. Always-On is
+defined as when the TOE has a network connection the VPN attempts to
+connect, all data leaving the device uses the VPN when the VPN is connected
+and no data leaves that device when the VPN is disconnected. The configuration
+of the VPN Client itself (with information such as VPN Gateway, certificates, and
+[algorithms) is addressed by the PP-Module for Virtual Private Network (VPN)](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=467&id=467)
+Clients, version 2.4.
+
+
+Validation Guidelines:
+
+
+**Rule #8**
+
+
+**Rule #9**
+
+
+**Rule #10**
+
+
+**Rule #11**
+
+
+**Evaluation Activities**
+
+
+_FMT_SMF.1_
+_**TSS**_
+_The evaluator shall verify that the TSS describes all management functions, what roles can_
+_perform each function, and how these functions are (or can be) restricted to the roles identified_
+_by FMT_MOF_EXT.1._
+
+
+_The following activities are organized according to the function number in the table. These_
+_activities include TSS Evaluation Activities, AGD Evaluation Activities, and test activities._
+
+
+_Test activities specified below shall take place in the test environment described in the_
+_evaluation activity for FPT_TUD_EXT.1._
+
+
+_**Guidance**_
+_The evaluator shall consult the AGD guidance to perform each of the specified tests, iterating_
+_each test as necessary if both the user and administrator may perform the function. The_
+_evaluator shall verify that the AGD guidance describes how to perform each management_
+_function, including any configuration details. For each specified management function tested,_
+_the evaluator shall confirm that the underlying mechanism exhibits the configured setting._
+
+
+_The following EAs correspond to specific management functions._
+_**Function 1**_
+_**TSS**_
+_The evaluator shall verify the TSS defines the allowable policy options: the range of values for_
+_both password length and lifetime, and a description of complexity to include character set and_
+_complexity policies (e.g., configuration and enforcement of number of uppercase, lowercase, and_
+_special characters per password)._
+
+
+_**Tests**_
+_The evaluator shall exercise the TSF configuration as the administrator and perform positive and_
+_negative tests, with at least two values set for each variable setting, for each of the following:_
+
+_Minimum password length_
+_Minimum password complexity_
+_Maximum password lifetime_
+
+
+_**Function 2**_
+_**TSS**_
+_The evaluator shall verify the TSS defines the range of values for both timeout period and_
+_number of authentication failures for all supported authentication mechanisms._
+
+
+_**Tests**_
+_The evaluator shall exercise the TSF configuration as the administrator. The evaluator shall_
+_perform positive and negative tests, with at least two values set for each variable setting, for_
+_each of the following:_
+
+_Screen-lock enabled/disabled_
+_Screen lock timeout_
+_Number of authentication failures (may be combined with test for FIA_AFL_EXT.1)_
+
+
+_**Function 3**_
+_**Tests**_
+_The evaluator shall perform the following tests:_
+
+_Test 72: The evaluator shall exercise the TSF configuration to enable the VPN protection._
+_These configuration actions must be used for the testing of the FDP_IFC_EXT.1.1_
+_requirement._
+_Test 73: [conditional] If "on a per-app basis" is selected, the evaluator shall create two_
+_applications and enable one to use the VPN and the other to not use the VPN. The evaluator_
+_shall exercise each application (attempting to access network resources; for example, by_
+_browsing different websites) individually while capturing packets from the TOE. The_
+_evaluator shall verify from the packet capture that the traffic from the VPN-enabled_
+_application is encapsulated in IPsec and that the traffic from the VPN-disabled application_
+_is not encapsulated in IPsec._
+_Test 74: [conditional] If "on a per-group of applications processes basis" is selected, the_
+_evaluator shall create two applications and the applications shall be placed into different_
+_groups. Enable one application group to use the VPN and the other to not use the VPN. The_
+_evaluator shall exercise each application (attempting to access network resources; for_
+_example, by browsing different websites) individually while capturing packets from the_
+_TOE. The evaluator shall verify from the packet capture that the traffic from the application_
+_in the VPN-enabled group is encapsulated in IPsec and that the traffic from the application_
+_in the VPN-disabled group is not encapsulated in IPsec._
+
+
+_**Function 4**_
+_**TSS**_
+_The evaluator shall verify that the TSS includes a description of each radio and an indication of if_
+_the radio can be enabled/disabled along with what role can do so. In addition the evaluator shall_
+_verify that the frequency ranges at which each radio operates is included in the TSS. The_
+_evaluator shall verify that the TSS includes at what point in the boot sequence the radios are_
+_powered on and indicates if the radios are used as part of the initialization of the device._
+
+
+_**Guidance**_
+_The evaluator shall confirm that the AGD guidance describes how to perform the enable/disable_
+_function for each radio._
+
+
+_**Tests**_
+_The evaluator shall ensure that minimal signal leakage enters the RF shielded enclosure (i.e._
+_Faraday bag, Faraday box, RF shielded room) by performing the following steps:_
+
+
+_Step 1: Place the antenna of the spectrum analyzer inside the RF shielded enclosure._
+
+
+_Step 2: Enable "Max Hold" on the spectrum analyzer and perform a spectrum sweep of the_
+_frequency range between 300 MHz โ 6000 MHz, in I kHz steps (this range should encompass_
+_802.11, 802.15, GSM, UMTS, and LTE). This range will not address NFC 13.56.MHz, another_
+_test should be set up with similar constraints to address NFC._
+
+
+_If power above -90 dBm is observed, the Faraday box has too great of signal leakage and shall_
+_not be used to complete the test for Function 4. The evaluator shall exercise the TSF_
+_configuration as the administrator and, if not restricted to the administrator, the user, to enable_
+_and disable the state of each radio (e.g. Wi-Fi, cellular, NFC, Bluetooth). Additionally, the_
+_evaluator shall repeat the steps below, booting into any auxiliary boot mode supported by the_
+_device. For each radio, the evaluator shall:_
+
+
+_Step 1: Place the antenna of the spectrum analyzer inside the RF shielded enclosure. Configure_
+_the spectrum analyzer to sweep desired frequency range for the radio to be tested (based on_
+_range provided in the TSS)). The ambient noise floor shall be set to -110 dBm. Place the TOE_
+_into the RF shielded enclosure to isolate them from all other RF traffic._
+
+
+_Step 2: The evaluator shall create a baseline of the expected behavior of RF signals. The_
+_evaluator shall power on the device, ensure the radio in question is enabled, power off the_
+_device, enable "Max Hold" on the spectrum analyzer and power on the device. The evaluator_
+_shall wait 2 minutes at each Authentication Factor interface prior to entering the necessary_
+
+
+_password to complete the boot process, waiting 5 minutes after the device is fully booted. The_
+_evaluator shall observe that RF spikes are present at the expected uplink channel frequency. The_
+_evaluator shall clear the "Max Hold" on the spectrum analyzer._
+
+
+_Step 3: The evaluator shall verify the absence of RF activity for the uplink channel when the_
+_radio in question is disabled. The evaluator shall complete the following test five times. The_
+_evaluator shall power on the device, ensure the radio in question is disabled, power off the_
+_device, enable "Max Hold" on the spectrum analyzer and power on the device. The evaluator_
+_shall wait 2 minutes at each Authentication Factor interface prior to entering the necessary_
+_password to complete the boot process, waiting 5 minutes after the device is fully booted. The_
+_evaluator shall clear the "Max Hold" on the spectrum analyzer. If the radios are used for device_
+_initialization, then a spike of RF activity for the uplink channel can be observed initially at device_
+_boot. However, if a spike of RF activity for the uplink channel of the specific radio frequency_
+_band is observed after the device is fully booted or at an Authentication Factor interface it is_
+_deemed that the radio is enabled._
+
+
+_**Function 5**_
+_**TSS**_
+_The evaluator shall verify that the TSS includes a description of each collection device and an_
+_indication of if it can be enabled/disabled along with what role can do so. The evaluator shall_
+_confirm that the AGD guidance describes how to perform the enable/disable function._
+
+
+_**Tests**_
+_The evaluator shall perform the following tests:_
+
+_Test 75: The evaluator shall exercise the TSF configuration as the administrator and, if not_
+_restricted to the administrator, the user, to enable and disable the state of each audio or_
+_visual collection devices (e.g. camera, microphone) listed by the ST author. For each_
+_collection device, the evaluator shall disable the device and then attempt to use its_
+_functionality. The evaluator shall reboot the TOE and verify that disabled collection devices_
+_may not be used during or early in the boot process. Additionally, the evaluator shall boot_
+_the device into each available auxiliary boot mode and verify that the collection device_
+_cannot be used._
+_Test 76: [conditional] If "on a per-app basis" is selected, the evaluator shall create two_
+_applications and enable one to use access the A/V device and the other to not access the_
+_A/V device. The evaluator shall exercise each application attempting to access the A/V_
+_device individually. The evaluator shall verify that the enabled application is able to access_
+_the A/V device and the disabled application is not able to access the A/V device._
+_Test 77: [conditional] If "on a per-group of applications processes basis" is selected, the_
+_evaluator shall create two applications and the applications shall be placed into different_
+_groups. Enable one group to access the A/V device and the other to not access the A/V_
+_device. The evaluator shall exercise each application attempting to access the A/V device_
+_individually. The evaluator shall verify that the application in the enabled group is able to_
+_access the A/V device and the application in the disabled group is not able to access the A/V_
+_device._
+
+
+_**Function 6**_
+_**Tests**_
+_The evaluator shall use the test environment to instruct the TSF, both as a user and as the_
+_administrator, to command the device to transition to a locked state, and verify that the device_
+_transitions to the locked state upon command._
+
+
+_**Function 7**_
+_**Tests**_
+_The evaluator shall use the test environment to instruct the TSF, both as a user and as the_
+_administrator, to command the device to perform a wipe of protected data. The evaluator must_
+_ensure that this management setup is used when conducting the Evaluation Activities in_
+_FCS_CKM_EXT.5._
+
+
+_**Function 8**_
+_**TSS**_
+_The evaluator shall verify the TSS describes the allowable application installation policy options_
+_based on the selection included in the ST. If the application allowlist is selected, the evaluator_
+_shall verify that the TSS includes a description of each application characteristic upon which the_
+_allowlist may be based._
+
+
+_**Tests**_
+_The evaluator shall exercise the TSF configuration as the administrator to restrict particular_
+_applications, sources of applications, or application installation according to the AGD guidance._
+_The evaluator shall attempt to install unauthorized applications and ensure that this is not_
+_possible. The evaluator shall, in conjunction, perform the following specific tests:_
+
+_Test 78: [conditional] The evaluator shall attempt to connect to an unauthorized repository_
+_in order to install applications._
+_Test 79: [conditional] The evaluator shall attempt to install two applications (one_
+_allowlisted, and one not) from a known allowed repository and verify that the application_
+_not on the allowlist is rejected. The evaluator shall also attempt to side-load executables or_
+
+
+_installation packages via USB connections to determine that the white list is still adhered to_
+
+
+_**Functions 9/10**_
+_**TSS**_
+_The evaluator shall verify that the TSS describes each category of keys or secrets that can be_
+_imported into the TSFโs secure key storage._
+
+
+_**Tests**_
+_The test of these functions is performed in association with FCS_STG_EXT.1._
+
+
+_**Function 11**_
+_**Guidance**_
+_The evaluator shall review the AGD guidance to determine that it describes the steps needed to_
+_import, modify, or remove certificates in the Trust Anchor database, and that the users that have_
+_authority to import those certificates (e.g., only administrator, or both administrators and users)_
+_are identified._
+
+
+_**Tests**_
+_The evaluator shall import certificates according to the AGD guidance as the user or as the_
+_administrator, as determined by the administrative guidance. The evaluator shall verify that no_
+_errors occur during import. The evaluator should perform an action requiring use of the X.509v3_
+_certificate to provide assurance that installation was completed properly._
+
+
+_**Function 12**_
+_**TSS**_
+_The evaluator shall verify that the TSS describes each additional category of X.509 certificates_
+_and their use within the TSF._
+
+
+_**Tests**_
+_The evaluator shall remove an administrator-imported certificate and any other categories of_
+_certificates included in the assignment of function 14 from the Trust Anchor Database according_
+_to the AGD guidance as the user and as the administrator._
+
+
+_**Function 13**_
+_**TSS**_
+_The evaluator shall examine the TSS to ensure that it contains a description of each_
+_management function that will be enforced by the enterprise once the device is enrolled. The_
+_evaluator shall examine the AGD guidance to determine that this same information is present._
+
+
+_**Tests**_
+_The evaluator shall verify that user approval is required to enroll the device into management._
+
+
+_**Function 14**_
+_**TSS**_
+_The evaluator shall verify that the TSS includes an indication of what applications (e.g., user-_
+_installed applications, Administrator-installed applications, or Enterprise applications) can be_
+_removed along with what role can do so. The evaluator shall examine the AGD guidance to_
+_determine that it details, for each type of application that can be removed, the procedures_
+_necessary to remove those applications and their associated data. For the purposes of this_
+_Evaluation Activity, "associated data" refers to data that are created by the app during its_
+_operation that do not exist independent of the app's existence, for instance, configuration data,_
+_or e-mail information thatโs part of an e-mail client. It does not, on the other hand, refer to data_
+_such as word processing documents (for a word processing app) or photos (for a photo or_
+_camera app)._
+
+
+_**Tests**_
+_The evaluator shall attempt to remove applications according to the AGD guidance and verify_
+_that the TOE no longer permits users to access those applications or their associated data._
+
+
+_**Function 15**_
+_**Tests**_
+_The evaluator shall attempt to update the TSF system software following the procedures in the_
+_AGD guidance and verify that updates correctly install and that the version numbers of the_
+_system software increase._
+
+
+_**Function 16**_
+_**Tests**_
+_The evaluator shall attempt to install an application following the procedures in the AGD_
+_guidance and verify that the application is installed and available on the TOE._
+
+
+_**Function 17**_
+_**Tests**_
+_The evaluator shall attempt to remove any Enterprise applications from the device by following_
+_the administrator guidance. The evaluator shall verify that the TOE no longer permits users to_
+
+
+_access those applications or their associated data._
+
+
+_**Function 18**_
+_**Guidance**_
+_The evaluator shall examine the AGD Guidance to determine that it specifies, for at least each_
+_category of information selected for Function 18, how to enable and disable display information_
+_for that type of information in the locked state._
+
+
+_**Tests**_
+_For each category of information listed in the AGD guidance, the evaluator shall verify that when_
+_that TSF is configured to limit the information according to the AGD, the information is no_
+_longer displayed in the locked state._
+
+
+_**Function 19**_
+_**Tests**_
+_The evaluator shall exercise the TSF configuration as the administrator and, if not restricted to_
+_the administrator, the user, to enable system-wide data-at-rest protection according to the AGD_
+_guidance. The evaluator shall ensure that all Evaluation Activities for DAR (FDP_DAR) are_
+_conducted with the device in this configuration._
+
+
+_**Function 20**_
+_**Tests**_
+_The evaluator shall exercise the TSF configuration as the administrator and, if not restricted to_
+_the administrator, the user, to enable removable mediaโs data-at-rest protection according to the_
+_AGD guidance. The evaluator shall ensure that all Evaluation Activities for DAR (FDP_DAR) are_
+_conducted with the device in this configuration._
+
+
+_**Function 21**_
+_**Tests**_
+_The evaluator shall perform the following tests._
+
+_Test 80: The evaluator shall enable location services device-wide and shall verify that an_
+_application (such as a mapping application) is able to access the TOEโs location information._
+_The evaluator shall disable location services device-wide and shall verify that an application_
+_(such as a mapping application) is unable to access the TOEโs location information._
+_Test 81: [conditional] If on a per-app basis is selected, the evaluator shall create two_
+_applications and enable one to use access the location services and the other to not access_
+_the location services. The evaluator shall exercise each application attempting to access_
+_location services individually. The evaluator shall verify that the enabled application is able_
+_to access the location services and the disabled application is not able to access the location_
+_services._
+
+
+_**Function 22 [CONDITIONAL]**_
+_**Tests**_
+_The evaluator shall verify that the TSS states if the TOE supports a BAF or hybrid_
+_authentication. If the TOE does not include a BAF or hybrid authentication this test is implicitly_
+_met._
+
+_Test 82: [conditional] If biometric in accordance with the Biometric Enrollment and_
+_[Verification, version 1.1 is selected in FIA_UAU.5.1, for each BAF claimed in](https://github.com/biometricITC/cPP-biometrics/blob/master/Protection%20Profile/BiocPP.adoc)_
+_[FIA_MBV_EXT.1.1 in the Biometric Enrollment and Verification, version 1.1 the evaluator](https://github.com/biometricITC/cPP-biometrics/blob/master/Protection%20Profile/BiocPP.adoc)_
+_shall verify that the TSS describes the procedure to enable/disable the BAF. The evaluator_
+_shall configure the TOE to allow each supported BAF to authenticate and verify that_
+_successful authentication can be achieved using the BAF. The evaluator shall configure the_
+_TOE to disable the use of each supported BAF for authentication and confirm that the BAF_
+_cannot be used to authenticate._
+_Test 83: [conditional] If hybrid is selected the evaluator shall verify that the TSS describes_
+_the procedure to enable/disable the hybrid (biometric credential and PIN/password)_
+_authentication. The evaluator shall configure the TOE to allow hybrid authentication to_
+_authenticate and confirm that successful authentication can be achieved using the hybrid_
+_authentication. The evaluator shall configure the TOE to disable the use of hybrid_
+_authentication and confirm that the hybrid authentication cannot be used to authenticate._
+
+
+_**Function 23 [CONDITIONAL]**_
+_**Tests**_
+_The test of this function is performed in conjunction with FIA_X509_EXT.2.2, FCS_TLSC_EXT.1.3_
+_[in the Functional Package for Transport Layer Security (TLS), version 1.1.](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=439&id=439)_
+
+
+_**Function 24 [CONDITIONAL]**_
+_**TSS**_
+_The evaluator shall verify that the TSS includes a list of each externally accessible hardware port_
+_and an indication of if data transfer over that port can be enabled/disabled. AGD guidance will_
+_describe how to perform the enable/disable function._
+
+
+_**Tests**_
+
+
+_The evaluator shall exercise the TSF configuration to enable and disable data transfer_
+_capabilities over each externally accessible hardware ports (e.g. USB, SD card, HDMI) listed by_
+_the ST author. The evaluator shall use test equipment for the particular interface to ensure that_
+_while the TOE may continue to receive data on the RX pins, it is not responding on TX pins used_
+_for data transfer when they are disabled. For each disabled data transfer capability, the_
+_evaluator shall repeat this test by rebooting the device into the normal operational mode and_
+_verifying that the capability is disabled throughout the boot and early execution stage of the_
+_device._
+
+
+_**Function 25 [CONDITIONAL]**_
+_**TSS**_
+_The evaluator shall verify that the TSS describes how the TSF acts as a server in each of the_
+_protocols listed in the ST, and the reason for acting as a server._
+
+
+_**Tests**_
+_The evaluator shall attempt to disable each listed protocol in the assignment. The evaluator shall_
+_verify that remote devices can no longer access the TOE or TOE resources using any disabled_
+_protocols._
+
+
+_**Function 26 [CONDITIONAL]**_
+_**Tests**_
+_The evaluator shall exercise the TSF configuration as the administrator and, if not restricted to_
+_the administrator, the user, to enable and disable any developer mode. The evaluator shall test_
+_that developer mode access is not available when its configuration is disabled. The evaluator_
+_shall verify the developer mode remains disabled during device reboot._
+
+
+_**Function 27 [CONDITIONAL]**_
+_**Guidance**_
+_The evaluator shall examine the AGD guidance to determine that it describes how to enable and_
+_disable any "Forgot Password", password hint, or remote authentication (to bypass local_
+_authentication mechanisms) capability._
+
+
+_**Tests**_
+_For each mechanism listed in the AGD guidance that provides a "Forgot Password" feature or_
+_other means where the local authentication process can be bypassed, the evaluator shall disable_
+_the feature and ensure that they are not able to bypass the local authentication process._
+
+
+_**Function 28 [CONDITIONAL]**_
+_**Tests**_
+_The evaluator shall attempt to wipe Enterprise data resident on the device according to the_
+_administrator guidance. The evaluator shall verify that the data is no longer accessible by the_
+_user._
+
+
+_**Function 29 [CONDITIONAL]**_
+_**TSS**_
+_The evaluator shall verify that the TSS describes how approval for an application to perform the_
+_selected action (import, removal) with respect to certificates in the Trust Anchor Database is_
+_accomplished (e.g., a pop-up, policy setting, etc.)._
+
+
+_The evaluator shall also verify that the API documentation provided according to Section 5.2.2_
+_Class ADV: Development includes any security functions (import, modification, or destruction of_
+_the Trust Anchor Database) allowed by applications._
+
+
+_**Tests**_
+_The evaluator shall perform one of the following tests:_
+
+_Test 84: [conditional] If applications may import certificates to the Trust Anchor Database,_
+_the evaluator shall write, or the developer shall provide access to, an application that_
+_imports a certificate into the Trust Anchor Database. The evaluator shall verify that the TOE_
+_requires approval before allowing the application to import the certificate:_
+
+_The evaluator shall deny the approvals to verify that the application is not able to_
+_import the certificate. Failure of import shall be tested by attempting to validate a_
+_certificate that chains to the certificate whose import was attempted (as described in_
+_the evaluation activity for FIA_X509_EXT.1)._
+_The evaluator shall repeat the test, allowing the approval to verify that the application_
+_is able to import the certificate and that validation occurs._
+
+_Test 85: [conditional] If applications may remove certificates in the Trust Anchor Database,_
+_the evaluator shall write, or the developer shall provide access to, an application that_
+_removes certificates from the Trust Anchor Database. The evaluator shall verify that the_
+_TOE requires approval before allowing the application to remove the certificate:_
+
+_The evaluator shall deny the approvals to verify that the application is not able to_
+_remove the certificate. Failure of removal shall be tested by attempting to validate a_
+_certificate that chains to the certificate whose removal was attempted (as described in_
+_the evaluation activity for FIA_X509_EXT.1)._
+
+_The evaluator shall repeat the test, allowing the approval to verify that the application is able to_
+
+
+_remove/modify the certificate and that validation no longer occurs._
+
+
+_**Function 30 [CONDITIONAL]**_
+_**Tests**_
+_The test of this function is performed in conjunction with FIA_X509_EXT.2.2._
+
+
+_**Function 31 [CONDITIONAL]**_
+_**TSS**_
+_The evaluator shall ensure that the TSS describes which cellular protocols can be disabled._
+
+
+_**Guidance**_
+_The evaluator shall confirm that the AGD guidance describes the procedure for disabling each_
+_cellular protocol identified in the TSS._
+
+
+_**Tests**_
+_The evaluator shall attempt to disable each cellular protocol according to the administrator_
+_guidance. The evaluator shall attempt to connect the device to a cellular network and, using_
+_network analysis tools, verify that the device does not allow negotiation of the disabled_
+_protocols._
+
+
+_**Function 32 [CONDITIONAL]**_
+_**Tests**_
+_The evaluator shall attempt to read any device audit logs according to the administrator_
+_guidance and verify that the logs may be read. This test may be performed in conjunction with_
+_the evaluation activity of FAU_GEN.1._
+
+
+_**Function 33 [CONDITIONAL]**_
+_**Tests**_
+_The test of this function is performed in conjunction with FPT_TUD_EXT.5.1._
+
+
+_**Function 34 [CONDITIONAL]**_
+_**TSS**_
+_The evaluator shall verify that the TSS describes how the approval for exceptions for shared use_
+_of keys or secrets by multiple applications is accomplished (e.g., a pop-up, policy setting, etc.)._
+
+
+_**Tests**_
+_The test of this function is performed in conjunction with FCS_STG_EXT.1._
+
+
+_**Function 35 [CONDITIONAL]**_
+_**TSS**_
+_The evaluator shall verify that the TSS describes how the approval for exceptions for destruction_
+_of keys or secrets by applications that did not import the key or secret is accomplished (e.g., a_
+_pop-up, policy setting, etc.)._
+
+
+_**Tests**_
+_The test of this function is performed in conjunction with FCS_STG_EXT.1._
+
+
+_**Function 36**_
+_**TSS**_
+_The evaluator shall verify that the TSS describes any restrictions in banner settings (e.g.,_
+_character limitations)._
+
+
+_**Tests**_
+_The test of this function is performed in conjunction with FTA_TAB.1._
+
+
+_**Function 37 [CONDITIONAL]**_
+_**Tests**_
+_The test of this function is performed in conjunction with FAU_SEL.1._
+
+
+_**Function 38 [CONDITIONAL]**_
+_**Tests**_
+_The test of this function is performed in conjunction with FPT_NOT_EXT.2.1._
+
+
+_**Function 39 [CONDITIONAL]**_
+_**TSS**_
+_The evaluator shall verify that the TSS includes a description of how data transfers can be_
+_managed over USB._
+
+
+_**Tests**_
+_The evaluator shall perform the following tests based on the selections made in the table:_
+
+_Test 86: [conditional] The evaluator shall disable USB mass storage mode, attach the device_
+_to a computer, and verify that the computer cannot mount the TOE as a drive. The_
+_evaluator shall reboot the TOE and repeat this test with other supported auxiliary boot_
+_modes._
+
+
+_Test 87: [conditional] The evaluator shall disable USB data transfer without user_
+_authentication, attach the device to a computer, and verify that the TOE requires user_
+_authentication before the computer can access TOE data. The evaluator shall reboot the_
+_TOE and repeat this test with other supported auxiliary boot modes._
+_Test 88: [conditional] The evaluator shall disable USB data transfer without connecting_
+_system authentication, attach the device to a computer, and verify that the TOE requires_
+_connecting system authentication before the computer can access TOE data. The evaluator_
+_shall then connect the TOE to another computer and verify that the computer cannot access_
+_TOE data. The evaluator shall then connect the TOE to the original computer and verify that_
+_the computer can access TOE data._
+
+
+_**Function 40 [CONDITIONAL]**_
+_**TSS**_
+_The evaluator shall verify that the TSS includes a description of available backup methods that_
+_can be enabled/disabled. If "selected applications" or "selected groups of applications" are_
+_selected the TSS shall include which applications of groups of applications backup can be_
+_enabled/disabled._
+
+
+_**Tests**_
+_If all applications is selected, the evaluator shall disable each selected backup location in turn_
+_and verify that the TOE cannot complete a backup. The evaluator shall then enable each selected_
+_backup location in turn and verify that the TOE can perform a backup._
+
+
+_If selected applications is selected, the evaluator shall disable each selected backup location in_
+_turn and verify that for the selected application the TOE prevents backup from occurring. The_
+_evaluator shall then enable each selected backup location in turn and verify that for the selected_
+_application the TOE can perform a backup._
+
+
+_If selected groups of applications is selected, the evaluator shall disable each selected backup_
+_location in turn and verify that for a group of applications the TOE prevents the backup from_
+_occurring. The evaluator shall then enable each selected backup location in turn and verify for_
+_the group of application the TOE can perform a backup._
+
+
+_If configuration data is selected, the evaluator shall disable each selected backup location in_
+_turn and verify that the TOE prevents the backup of configuration data from occurring. The_
+_evaluator shall then enable each selected backup location in turn and verify that the TOE can_
+_perform a backup of configuration data._
+
+
+_**Function 41 [CONDITIONAL]**_
+_**TSS**_
+_The evaluator shall verify that the TSS includes a description of Hotspot functionality and USB_
+_tethering to include any authentication for these._
+
+
+_**Tests**_
+_The evaluator shall perform the following tests based on the selections in Function 41._
+
+_Test 89: [conditional] The evaluator shall enable hotspot functionality with each of the of_
+_the support authentication methods. The evaluator shall connect to the hotspot with_
+_another device and verify that the hotspot functionality requires the configured_
+_authentication method._
+_Test 90: [conditional] The evaluator shall enable USB tethering functionality with each of_
+_the of the support authentication methods. The evaluator shall connect to the TOE over_
+_USB with another device and verify that the tethering functionality requires the configured_
+_authentication method._
+
+
+_**Function 42 [CONDITIONAL]**_
+_**Tests**_
+_The test of this function is performed in conjunction with FDP_ACF_EXT.1.2._
+
+
+_**Function 43 [CONDITIONAL]**_
+_**Tests**_
+_The evaluator shall set a policy to cause a designated application to be placed into a particular_
+_application group. The evaluator shall then install the designated application and verify that it_
+_was placed into the correct group._
+
+
+_**Function 44 [CONDITIONAL]**_
+_**Tests**_
+_The evaluator shall attempt to unenroll the device from management and verify that the steps_
+_described in FMT_SMF_EXT.2.1 are performed. This test should be performed in conjunction_
+_with the FMT_SMF_EXT.2.1 evaluation activity._
+
+
+_**Function 45 [CONDITIONAL]**_
+_**TSS**_
+_The evaluator shall verify that the TSS contains guidance to configure the VPN as Always-On._
+
+
+_**Tests**_
+_The evaluator shall configure the VPN as Always-On and perform the following tests:_
+
+_Test 91: The evaluator shall verify that when the VPN is connected all traffic is routed_
+_through the VPN. This test is performed in conjunction with FDP_IFC_EXT.1.1._
+_Test 92: The evaluator shall verify that when the VPN is not established, that no traffic_
+_leaves the device. The evaluator shall ensure that the TOE has network connectivity and_
+_that the VPN is established. The evaluator shall use a packet sniffing tool to capture the_
+_traffic leaving the TOE. The evaluator shall disable the VPN connection on the server side._
+_The evaluator shall perform actions with the device such as navigating to websites, using_
+_provided applications, and accessing other Internet resources and verify that no traffic_
+_leaves the device._
+_Test 93: The evaluator shall verify that the TOE has network connectivity and that the VPN_
+_is established. The evaluator shall disable network connectivity (i.e. Airplane Mode) and_
+_verify that the VPN disconnects. The evaluator shall re-establish network connectivity and_
+_verify that the VPN automatically reconnects._
+
+
+_**Function 46 [CONDITIONAL]**_
+_**TSS**_
+_The evaluator shall verify that the TSS describes the procedure to revoke a biometric credential_
+_stored on the TOE._
+
+
+_**Tests**_
+_The evaluator shall configure the TOE to use BAF and confirm that the biometric can be used to_
+_authenticate to the device. The evaluator shall revoke the biometric credentialโs ability to_
+_authenticate to the TOE and confirm that the same BAF cannot be used to authenticate to the_
+_device._
+
+
+_**Function 47 [CONDITIONAL]**_
+_**TSS**_
+_The evaluator shall verify that the TSS describes all assigned security management functions_
+_and their intended behavior._
+
+
+_**Tests**_
+_The evaluator shall design and perform tests to demonstrate that the function may be configured_
+_and that the intended behavior of the function is enacted by the TOE._
+
+
+**FMT_SMF_EXT.2 Specification of Remediation Actions**
+
+
+FMT_SMF_EXT.2.1
+
+The TSF shall offer [ **selection** : _wipe of protected data_, _wipe of sensitive data_,
+_remove Enterprise applications_, _remove all device-stored Enterprise resource_
+_data_, _remove Enterprise secondary authentication data_, _[_ _**assignment**_ _: list other_
+_available remediation actions]_ ] upon unenrollment and [ **selection** :
+
+_[_ _**assignment**_ _: other administrator-configured triggers]_, _no other triggers_ ].
+
+
+**Application Note:** Unenrollment may consist of removing the MDM agent or
+removing the administratorโs policies. The functions in the selection are
+remediation actions that TOE may provide (perhaps via APIs) to the
+administrator (perhaps via an MDM agent) that may be performed upon
+unenrollment. "Enterprise applications" refers to applications that are in the
+Enterprise application group. "Enterprise resource data" refers to all stored
+Enterprise data and the separate resources that are available to the Enterprise
+application group, per FDP_ACF_EXT.2.1. If FDP_ACF_EXT.2.1 is included in the
+ST, then "remove all device-stored Enterprise resource data" must be selected,
+and is defined to be all resources selected in FDP_ACF_EXT.2.1. If
+FIA_UAU_EXT.4.1 is included in the ST, then "remove Enterprise secondary
+authentication data" must be selected. If FIA_UAU_EXT.4.1 is not included in the
+ST, then "remove Enterprise secondary authentication data" cannot be selected.
+Enterprise secondary authentication data only refers to any data stored on the
+TOE that is specifically used as part of a secondary authentication mechanism to
+authenticate access to Enterprise applications and shared resources. Material
+that is used for the TOEโs primary authentication mechanism or other purposes
+not related to authentication to or protection of Enterprise applications or
+shared resources should not be removed.
+
+
+Protected data is all non-TSF data, including all user or enterprise data. Some or
+all of this data may be considered sensitive data as well. If wipe of protected
+data is selected it is assumed that the sensitive data is wiped as well. However, if
+wipe of sensitive data is selected, it does not imply that all non-TSF data
+(protected data) is wiped. If wipe of protected data or wipe of sensitive data is
+selected the wipe must be in accordance with FCS_CKM_EXT.5.1. Thus
+cryptographically wiping the device is an acceptable remediation action.
+
+
+**Evaluation Activities**
+
+
+**5.1.8 Class: Protection of the TSF (FPT)**
+
+
+**FPT_AEX_EXT.1 Application Address Space Layout Randomization**
+
+
+FPT_AEX_EXT.1.1
+
+The TSF shall provide address space layout randomization ASLR to applications.
+
+
+FPT_AEX_EXT.1.2
+
+The base address of any user-space memory mapping will consist of at least 8
+unpredictable bits.
+
+
+**Application Note:** The 8 unpredictable bits may be provided by the TSF RBG
+(as specified in FCS_RBG_EXT.1) but is not required.
+
+
+**Evaluation Activities**
+
+
+
+
+
+**FPT_AEX_EXT.2 Memory Page Permissions**
+
+
+FPT_AEX_EXT.2.1
+
+The TSF shall be able to enforce read, write, and execute permissions on every
+page of physical memory.
+
+
+**Evaluation Activities**
+
+
+_FPT_AEX_EXT.2_
+_**TSS**_
+_The evaluator shall ensure that the TSS describes of the memory management unit (MMU), and_
+_ensures that this description documents the ability of the MMU to enforce read, write, and_
+_execute permissions on all pages of virtual memory._
+
+
+_**Guidance**_
+_There are no guidance evaluation activities for this component._
+
+
+_**Tests**_
+_There are no test evaluation activities for this component._
+
+
+**FPT_AEX_EXT.3 Stack Overflow Protection**
+
+
+FPT_AEX_EXT.3.1
+
+TSF processes that execute in a non-privileged execution domain on the
+application processor shall implement stack-based buffer overflow protection.
+
+
+**Application Note:** A "non-privileged execution domain" refers to the user mode
+(as opposed to kernel mode, for instance) of the processor. While not all TSF
+processes must implement such protection, it is expected that most of the
+processes (to include libraries used by TSF processes) do implement buffer
+overflow protections.
+
+
+**Evaluation Activities**
+
+
+
+
+
+**FPT_AEX_EXT.4 Domain Isolation**
+
+
+FPT_AEX_EXT.4.1
+
+The TSF shall protect itself from modification by untrusted subjects.
+
+
+FPT_AEX_EXT.4.2
+
+The TSF shall enforce isolation of address space between applications.
+
+
+**Application Note:** In addition to the TSF software (e.g., kernel image, device
+drivers, trusted applications) that resides in storage, the execution context (e.g.,
+address space, processor registers, per-process environment variables) of the
+software operating in a privileged mode of the processor (e.g., kernel), as well as
+the context of the trusted applications is to be protected. In addition to the
+software, any configuration information that controls or influences the behavior
+of the TSF is also to be protected from modification by untrusted subjects.
+
+
+Configuration information includes, but is not limited to, user and administrative
+management function settings, WLAN profiles, and Bluetooth data such as the
+service-level security requirements database.
+
+
+Untrusted subjects include untrusted applications; unauthorized users who have
+access to the device while powered off, in a screen-locked state, or when booted
+into auxiliary boot modes; and, unauthorized users or untrusted software or
+hardware which may have access to the device over a wired interface, either
+when the device is in a screen-locked state or booted into auxiliary boot modes.
+
+
+**Evaluation Activities**
+
+
+_FPT_AEX_EXT.4_
+_**TSS**_
+_The evaluator shall ensure that the TSS describes the mechanisms that are in place that_
+_prevents non-TSF software from modifying the TSF software or TSF data that governs the_
+_behavior of the TSF. These mechanisms could range from hardware-based means (e.g._
+_"execution rings" and memory management functionality); to software-based means (e.g._
+_boundary checking of inputs to APIs). The evaluator determines that the described mechanisms_
+_appear reasonable to protect the TSF from modification._
+
+
+_The evaluator shall ensure the TSS describes how the TSF ensures that the address spaces of_
+_applications are kept separate from one another._
+
+
+_The evaluator shall ensure the TSS details the USSD and MMI codes available from the dialer at_
+_the locked state or during auxiliary boot modes that may alter the behavior of the TSF. The_
+_evaluator shall ensure that this description includes the code, the action performed by the TSF,_
+_and a justification that the actions performed do not modify user or TSF data. If no USSD or_
+_MMI codes are available, the evaluator shall ensure that the TSS provides a description of the_
+_method by which actions prescribed by these codes are prevented._
+
+
+_The evaluator shall ensure the TSS documents any TSF data (including software, execution_
+_context, configuration information, and audit logs) which may be accessed and modified over a_
+_wired interface in auxiliary boot modes. The evaluator shall ensure that the description includes_
+_data, which is modified in support of update or restore of the device. The evaluator shall ensure_
+_that this documentation includes the auxiliary boot modes in which the data may be modified,_
+_the methods for entering the auxiliary boot modes, the location of the data, the manner in which_
+_data may be modified, the data format and packaging necessary to support modification, and_
+_software or hardware tools, if any, which are necessary for modifying the data._
+
+
+_The evaluator shall ensure that the TSS provides a description of the means by which_
+_unauthorized and undetected modification (that is, excluding cryptographically verified updates_
+_per FPT_TUD_EXT.2) of the TSF data over the wired interface in auxiliary boots modes is_
+_prevented. The lack of publicly available tools is not sufficient justification. Examples of_
+_sufficient justification include auditing of changes, cryptographic verification in the form of a_
+_digital signature or hash, disabling the auxiliary boot modes, and access control mechanisms_
+_that prevent writing to files or flashing partitions._
+
+
+_**Guidance**_
+_There are no guidance evaluation activities for this component._
+
+
+_**Tests**_
+_**Evaluation Activity Note:**_ _The following tests require the vendor to provide access to a test_
+_platform that provides the evaluator with tools that are typically not found on consumer Mobile_
+_Device products. In addition, the vendor provides a list of files (e.g., system files, libraries,_
+_configuration files, audit logs) that make up the TSF data. This list could be organized by_
+_folders/directories (e.g., /usr/sbin, /etc), as well as individual files that may exist outside of the_
+_identified directories._
+
+_Test 95: The evaluator shall create and load an app onto the Mobile Device. This app shall_
+_attempt to traverse over all file systems and report any locations to which data can be_
+_written or overwritten. The evaluator must ensure that none of these locations are part of_
+_the OS software, device drivers, system and security configuration files, key material, or_
+_another untrusted applicationโs image/data. For example, it is acceptable for a trusted_
+_photo editor app to have access to the data created by the camera app, but a calculator_
+_application shall not have access to the pictures._
+
+
+_Test 96: For each available auxiliary boot mode, the evaluator shall attempt to modify a TSF_
+_file of their choosing using the software or hardware tools described in the TSS. The_
+_evaluator shall verify that the modification fails._
+
+
+**FPT_JTA_EXT.1 JTAG Disablement**
+
+
+FPT_JTA_EXT.1.1
+
+The TSF shall [ **selection** : _disable access through hardware_, _control access by a_
+_signing key_ ] to JTAG.
+
+
+**Application Note:** This requirement means that access to JTAG must be
+disabled either through hardware or restricted through the use of a signing key.
+
+
+**Evaluation Activities**
+
+
+_FPT_JTA_EXT.1_
+_**TSS**_
+_If disable access through hardware is selected:_
+_The evaluator shall examine the TSS to determine the location of the JTAG ports on the TSF, to_
+_include the order of the ports (i.e. Data In, Data Out, Clock, etc.)._
+
+
+_If control access by a signing key is selected:_
+_The evaluator shall examine the TSS to determine how access to the JTAG is controlled by a_
+_signing key. The evaluator shall examine the TSS to determine when the JTAG can be accessed,_
+_i.e. what has the access to the signing key._
+
+
+_**Guidance**_
+_There are no guidance evaluation activities for this component._
+
+
+_**Tests**_
+_**Evaluation Activity Note:**_ _The following test requires the developer to provide access to a test_
+_platform that provides the evaluator with chip level access._
+
+
+_If disable access through hardware is selected:_
+_The evaluator shall connect a packet analyzer to the JTAG ports. The evaluator shall query the_
+_JTAG port for its device ID and confirm that the device ID cannot be retrieved._
+
+
+**FPT_KST_EXT.1 Key Storage**
+
+
+FPT_KST_EXT.1.1
+
+The TSF shall not store any plaintext key material in readable non-volatile
+memory.
+
+
+**Application Note:** The intention of this requirement is that the TOE will not
+write plaintext keying material to persistent storage. For the purposes of this
+requirement, keying material refers to authentication data, passwords,
+secret/private symmetric keys, private asymmetric keys, data used to derive
+keys, etc. These values must be stored encrypted.
+
+
+This requirement also applies to any value derived from passwords. Thus, the
+TOE cannot store plaintext password hashes for comparison purposes before
+protected data is decrypted, and the TOE should use key derivation and
+decryption to verify the Password Authentication Factor.
+
+
+If hybrid is selected in FIA_UAU.5.1 keying material also refers to the
+PIN/password used as part of the hybrid authentication.
+
+
+**Evaluation Activities**
+
+
+**FPT_KST_EXT.2 No Key Transmission**
+
+
+FPT_KST_EXT.2.1
+
+The TSF shall not transmit any plaintext key material outside the security
+boundary of the TOE.
+
+
+**Application Note:** The intention of this requirement is to prevent the logging of
+plaintext key information to a service that transmits the information off-device.
+For the purposes of this requirement, key material refers to keys, passwords,
+and other material that is used to derive keys.
+
+
+If hybrid is selected in FIA_UAU.5.1 keying material also refers to the
+
+
+PIN/password used as part of the hybrid authentication.
+
+
+In the future, this requirement will apply to symmetric and asymmetric private
+keys stored in the TOE secure key storage where applications are outside the
+boundary of the TOE. Thus, the TSF will be required to provide cryptographic
+key operations (signature, encryption, and decryption) on behalf of applications
+(FCS_SRV_EXT.2.1) that have access to those keys.
+
+
+**Evaluation Activities**
+
+
+
+
+
+**FPT_KST_EXT.3 No Plaintext Key Export**
+
+
+FPT_KST_EXT.3.1
+
+The TSF shall ensure it is not possible for the TOE users to export plaintext keys.
+
+
+**Application Note:** Plaintext keys include DEKs, KEKs, and all keys stored in the
+secure key storage (FCS_STG_EXT.1). The intent of this requirement is to
+prevent the plaintext keys from being exported during a backup authorized by
+the TOE user or administrator.
+
+
+**Evaluation Activities**
+
+
+
+
+
+
+
+**FPT_NOT_EXT.1 Self-Test Notification**
+
+
+FPT_NOT_EXT.1.1
+
+The TSF shall transition to non-operational mode and [ **selection** : _log failures in_
+_the audit record_, _notify the administrator_, _[_ _**assignment**_ _: other actions]_, _no other_
+_actions_ ] when the following types of failures occur:
+
+failures of the self-tests
+TSF software integrity verification failures
+
+[ **selection** : _no other failures_, _[_ _**assignment**_ _: other failures]_ ]
+
+
+**Evaluation Activities**
+
+
+**FPT_STM.1 Reliable Time Stamps**
+
+
+FPT_STM.1.1
+
+The TSF shall be able to provide reliable time stamps **for its own use** .
+
+
+**Evaluation Activities**
+
+
+
+
+
+
+
+**FPT_TST_EXT.1 TSF Cryptographic Functionality Testing**
+
+
+FPT_TST_EXT.1.1
+
+The TSF shall run a suite of self-tests during initial start-up (on power on) to
+demonstrate the correct operation of all cryptographic functionality.
+
+
+**Application Note:** This requirement may be met by performing known answer
+tests or pair-wise consistency tests. The self-tests must be performed before the
+cryptographic functionality is exercised (for example, during the initialization of
+a process that utilizes the functionality).
+
+
+The cryptographic functionality includes the cryptographic operations in
+FCS_COP, the key generation functions in FCS_CKM, and the random bit
+generation in FCS_RBG_EXT.
+
+
+**Evaluation Activities**
+
+
+_FPT_TST_EXT.1_
+_**TSS**_
+_The evaluator shall examine the TSS to ensure that it specifies the self-tests that are performed_
+_at start-up. This description must include an outline of the test procedures conducted by the TSF_
+_(e.g., rather than saying "memory is tested", a description similar to "memory is tested by_
+_writing a value to each memory location and reading it back to ensure it is identical to what was_
+_written" shall be used). The TSS must include any error states that they TSF may enter when_
+_self-tests fail, and the conditions and actions necessary to exit the error states and resume_
+_normal operation. The evaluator shall verify that the TSS indicates these self-tests are run at_
+_start-up automatically, and do not involve any inputs from or actions by the user or operator._
+
+
+_The evaluator shall inspect the list of self-tests in the TSS and verify that it includes algorithm_
+_self-tests. The algorithm self-tests will typically be conducted using known answer tests._
+
+
+_**Guidance**_
+_There are no guidance evaluation activities for this component._
+
+
+_**Tests**_
+_There are no test evaluation activities for this component._
+
+
+**FPT_TST_EXT.2/PREKERNEL TSF Integrity Checking (Pre-Kernel)**
+
+
+FPT_TST_EXT.2.1/PREKERNEL
+
+The TSF shall verify the integrity of [ _the bootchain up through the Application_
+_Processor OS kernel_ ] stored in mutable media prior to its execution through the
+use of [ **selection** : _a digital signature using an immutable hardware asymmetric_
+_key_, _an immutable hardware hash of an asymmetric key_, _an immutable hardware_
+_hash_, _a digital signature using a hardware-protected asymmetric key_ ].
+
+
+**Application Note:** The bootchain of the TSF is the sequence of firmware and
+software, including ROM, bootloaders, and kernel, which ultimately result in
+loading the kernel on the Application Processor, regardless of which processor
+executes that code. Executable code that would be loaded after the kernel is
+covered in FPT_TST_EXT.2/POSTKERNEL.
+
+
+In order to meet this requirement, the hardware protection may be transitive in
+nature: a hardware-protected public key, hash of an asymmetric key, or hash
+may be used to verify the mutable bootloader code which contains a key or hash
+used by the bootloader to verify the mutable OS kernel code, which contains a
+key or hash to verify the next layer of executable code, and so on.
+
+
+The cryptographic mechanism used to verify the (initial) mutable executable
+code must be protected, such as being implemented in hardware or in read-only
+memory (ROM).
+
+
+**Evaluation Activities**
+
+
+_FPT_TST_EXT.2/PREKERNEL_
+_**TSS**_
+_The evaluator shall verify that the TSS section of the ST includes a description of the boot_
+_procedures, including a description of the entire bootchain, of the software for the TSFโs_
+_Application Processor. The evaluator shall ensure that before loading the bootloaders for the_
+_operating system and the kernel, all bootloaders and the kernel software itself is_
+_cryptographically verified. For each additional category of executable code verified before_
+_execution, the evaluator shall verify that the description in the TSS describes how that software_
+_is cryptographically verified._
+
+
+_The evaluator shall verify that the TSS contains a justification for the protection of the_
+_cryptographic key or hash, preventing it from being modified by unverified or unauthenticated_
+_software. The evaluator shall verify that the TSS contains a description of the protection_
+_afforded to the mechanism performing the cryptographic verification._
+
+
+_The evaluator shall verify that the TSS describes each auxiliary boot mode available on the TOE_
+_during the boot procedures. The evaluator shall verify that, for each auxiliary boot mode, a_
+_description of the cryptographic integrity of the executed code through the kernel is verified_
+_before each execution._
+
+
+_**Guidance**_
+_There are no guidance evaluation activities for this component._
+
+
+_**Tests**_
+_**Evaluation Activity Note:**_ _The following tests require the vendor to provide access to a test_
+_platform that provides the evaluator with tools that are typically not found on consumer Mobile_
+_Device products._
+
+
+_The evaluator shall perform the following tests:_
+
+_Test 99: The evaluator shall perform actions to cause TSF software to load and observe that_
+_the integrity mechanism does not flag any executables as containing integrity errors and_
+_that the TOE properly boots._
+
+
+_Test 100: The evaluator shall modify a TSF executable that is integrity protected and cause_
+_that executable to be successfully loaded by the TSF. The evaluator observes that an_
+_integrity violation is triggered and the TOE does not boot. (Care must be taken so that the_
+_integrity violation is determined to be the cause of the failure to load the module, and not_
+_the fact that the module was modified so that it was rendered unable to run because its_
+_format was corrupt)._
+
+
+_Test 101: [conditional] If the ST author indicates that the integrity verification is performed_
+_using a public key, the evaluator shall verify that the update mechanism includes a_
+_certificate validation according to FIA_X509_EXT.1. The evaluator shall digitally sign the_
+_TSF executable with a certificate that does not have the Code Signing purpose in the_
+_extendedKeyUsage field and verify that an integrity violation is triggered. The evaluator_
+_shall repeat the test using a certificate that contains the Code Signing purpose and verify_
+_that the integrity verification succeeds. Ideally, the two certificates should be identical_
+_except for the extendedKeyUsage field._
+
+
+**FPT_TUD_EXT.1 TSF Version Query**
+
+
+FPT_TUD_EXT.1.1
+
+The TSF shall provide authorized users the ability to query the current version of
+the TOE firmware/software.
+
+
+FPT_TUD_EXT.1.2
+
+The TSF shall provide authorized users the ability to query the current version of
+the hardware model of the device.
+
+
+**Application Note:** The current version of the hardware model of the device is
+an identifier that is sufficient to indicate (in tandem with manufacturer
+documentation) the hardware which comprises the device.
+
+
+FPT_TUD_EXT.1.3
+
+The TSF shall provide authorized users the ability to query the current version of
+installed mobile applications.
+
+
+**Application Note:** The current version of mobile applications is the name and
+published version number of each installed mobile application.
+
+
+**Evaluation Activities**
+
+
+
+
+
+**FPT_TUD_EXT.2 TSF Update Verification**
+
+
+FPT_TUD_EXT.2.1
+
+The TSF shall verify software updates to the Application Processor system
+software and [ **selection** : _[_ _**assignment**_ _: other processor system software]_, _no_
+_other processor system software_ ] using a digital signature verified by the
+manufacturer trusted key prior to installing those updates.
+
+
+**Application Note:** The digital signature mechanism is implemented in
+accordance with FCS_COP.1.1/SIGN.
+
+
+At this time, this requirement does not require verification of software updates
+to the software operating outside the Application Processor.
+
+
+Any change, via a supported mechanism, to software residing in non-volatile
+storage is deemed a software update. Thus, this requirement applies to TSF
+software updates regardless of how the software arrives or is delivered to the
+
+
+FPT_TUD_EXT.2.2
+
+
+FPT_TUD_EXT.2.3
+
+
+
+device. This includes over-the-air (OTA) updates as well as partition images
+containing software which may be delivered to the device over a wired interface.
+
+
+The TSF shall [ **selection** : _never update_, _update only by verified software_ ] the
+TSF boot integrity [ **selection** : _key_, _hash_ ].
+
+
+**Application Note:** The key or hash updated via this requirement is used for
+verifying software before execution in FPT_TST_EXT.2/PREKERNEL. The key or
+hash is verified as a part of the digital signature on an update, and the software
+which performs the update of the key or hash is verified by
+FPT_TST_EXT.2/PREKERNEL.
+
+
+The TSF shall verify that the digital signature verification key used for TSF
+updates [ **selection** : _is validated to a public key in the Trust Anchor Database_,
+_matches an immutable hardware public key_ ].
+
+
+**Application Note:** The ST author must indicate the method by which the
+signing key for system software updates is limited and, if selected in
+FPT_TUD_EXT.2.3, must indicate how this signing key is protected by the
+hardware.
+
+
+If certificates are used, certificates are validated for the purpose of software
+updates in accordance with FIA_X509_EXT.1 and should be selected in
+FIA_X509_EXT.2.1. Additionally, FPT_TUD_EXT.4 must be included in the ST.
+
+
+
+**Evaluation Activities**
+
+
+
+
+**FPT_TUD_EXT.3 Application Signing**
+
+
+FPT_TUD_EXT.3.1
+
+The TSF shall verify mobile application software using a digital signature
+mechanism prior to installation.
+
+
+**Application Note:** This requirement does not necessitate an X.509v3 certificate
+or certificate validation. X.509v3 certificates and certificate validation are
+addressed in FPT_TUD_EXT.5.1.
+
+
+**Evaluation Activities**
+
+
+**5.1.9 Class: TOE Access (FTA)**
+
+
+**FTA_SSL_EXT.1 TSF- and User-initiated Locked State**
+
+
+FTA_SSL_EXT.1.1
+
+The TSF shall transition to a locked state after a time interval of inactivity.
+
+
+FTA_SSL_EXT.1.2
+
+The TSF shall transition to a locked state after initiation by either the user or the
+administrator.
+
+
+FTA_SSL_EXT.1.3
+
+The TSF shall, upon transitioning to the locked state, perform the following
+operations:
+
+Clearing or overwriting display devices, obscuring the previous contents;
+
+[ **assignment** : _Other actions performed upon transitioning to the locked_
+_state_ ].
+
+
+**Application Note:** The time interval of inactivity is configured using
+FMT_SMF.1 function 2. The user/administrator-initiated lock is specified in
+FMT_SMF.1 function 6.
+
+
+**Evaluation Activities**
+
+
+_FTA_SSL_EXT.1_
+_**TSS**_
+_The evaluator shall verify the TSS describes the actions performed upon transitioning to the_
+_locked state._
+
+
+_**Guidance**_
+_The evaluation shall verify that the AGD guidance describes the method of setting the inactivity_
+_interval and of commanding a lock. The evaluator shall verify that the TSS describes the_
+_information allowed to be displayed to unauthorized users._
+
+
+_**Tests**_
+
+_Test 108: The evaluator shall configure the TSF to transition to the locked state after a time_
+_of inactivity (FMT_SMF.1) according to the AGD guidance. The evaluator shall wait until the_
+_TSF locks and verify that the display is cleared or overwritten and that the only actions_
+_allowed in the locked state are unlocking the session and those actions specified in_
+_FIA_UAU_EXT.2._
+
+
+_Test 109: The evaluator shall command the TSF to transition to the locked state according_
+_to the AGD guidance as both the user and the administrator. The evaluator shall wait until_
+_the TSF locks and verify that the display is cleared or overwritten and that the only actions_
+_allowed in the locked state are unlocking the session and those actions specified in_
+_FIA_UAU_EXT.2._
+
+
+**FTA_TAB.1 Default TOE Access Banners**
+
+
+FTA_TAB.1.1
+
+Before establishing a user session, the TSF shall display an advisory warning
+message regarding unauthorized use of the TOE.
+
+
+**Application Note:** This requirement may be met with the configuration of
+either text or an image containing the text of the desired message. The TSF must
+minimally display this information at startup, but may also display the
+information at every unlock. The banner is configured according to FMT_SMF.1
+function 36.
+
+
+**Evaluation Activities**
+
+
+
+
+
+**5.1.10 Class: Trusted Path/Channels (FTP)**
+
+
+**FTP_ITC_EXT.1 Trusted Channel Communication**
+
+
+FTP_ITC_EXT.1.1
+
+The TSF shall use
+
+802.11-2012 in accordance with the [ _PP-Module for Wireless LAN Clients,_
+_version 1.0_ ],
+802.1X in accordance with the [ _PP-Module for Wireless LAN Clients,_
+_version 1.0_ ],
+EAP-TLS in accordance with the [ _PP-Module for Wireless LAN Clients,_
+_version 1.0_ ],
+Mutually authenticated TLS in accordance with [ _the Functional Package for_
+_Transport Layer Security (TLS), version 1.1_ ]
+
+and [ **selection** :
+
+_IPsec in accordance with the PP-Module for Virtual Private Network (VPN)_
+_Clients, version 2.4_
+_mutually authenticated DTLS as defined in the Functional Package for_
+_[Transport Layer Security (TLS), version 1.1](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=439&id=439)_
+_HTTPS_
+
+] protocols to provide a communication channel between itself and another
+trusted IT product that is logically distinct from other communication channels,
+provides assured identification of its end points, protects channel data from
+disclosure, and detects modification of the channel data.
+
+
+**Application Note:** The intent of the mandatory portion of the above
+requirement is to use the cryptographic protocols identified in the requirement
+to establish and maintain a trusted channel between the TOE and an access
+point, VPN Gateway, or other trusted IT product.
+
+
+The ST author must list which trusted channel protocols are implemented by the
+Mobile Device.
+
+
+The TSF must be validated against the PP-Module for Wireless LAN Clients,
+version 1.0 to satisfy the mandatory trusted channels of 802.11-2012, 802.1X,
+and EAP-TLS.
+
+
+FTP_ITC_EXT.1.2
+
+
+FTP_ITC_EXT.1.3
+
+
+
+To satisfy the mandatory trusted channel of TLS and if mutually authenticated
+DTLS is selected, the TSF must be validated against the Functional Package for
+Transport Layer Security (TLS), version 1.1, with the following selections made:
+
+FCS_TLS_EXT.1:
+
+Either TLS or DTLS is selected as appropriate
+Client is selected
+
+FCS_TLSC_EXT.1.1 or FCS_DTLSC_EXT.1.1 (as appropriate):
+
+The cipher suites selected must correspond with the algorithms and
+hash functions allowed in FCS_COP.1.
+Mutual authentication must be selected
+
+FCS_TLSC_EXT.1.3 or FCS_DTLSC_EXT.1.3 (as appropriate):
+
+With no exceptions is selected.
+
+
+[If the ST author selects IPsec, the TSF must be validated against the PP-Module](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=467&id=467)
+for Virtual Private Network (VPN) Clients, version 2.4.
+
+
+Appendix B - Selection-based Requirements contains the requirements for
+implementing each of the other optional trusted channel protocols. The ST
+author must include the security functional requirements for the trusted channel
+protocol selected in FTP_ITC_EXT.1 in the main body of the ST.
+
+
+Assured identification of endpoints is performed according to the authentication
+mechanisms used by the listed trusted channel protocols.
+
+
+Validation Guidelines:
+
+
+**Rule #13**
+
+
+**Rule #14**
+
+
+The TSF shall permit the TSF to initiate communication via the trusted channel.
+
+
+The TSF shall initiate communication via the trusted channel for wireless access
+point connections, administrative communication, configured enterprise
+connections, and [ **selection** : _OTA updates_, _no other connections_ ].
+
+
+
+**Evaluation Activities**
+
+
+
+
+**5.1.11 TOE Security Functional Requirements Rationale**
+The following rationale provides justification for each security objective for the TOE, showing that the SFRs
+are suitable to meet and achieve the security objectives:
+
+
+**Table 8: SFR Rationale**
+
+**Objective** **Addressed by** **Rationale**
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+FCS_CKM_EXT.7 (Sel-Based) FCS_CKM_EXT.7 supports the objective by ensuring that
+
+
+the TOE's root encryption key cannot be disclosed.
+
+
+FMT_SMF_EXT.2 FMT_SMF_EXT.2 supports the objective by defining the
+
+
+configuration actions that the TSF performs
+automatically upon unenrollment from mobile device
+management.
+
+
+FAU_STG.4 FAU_STG.4 supports the objective by ensuring the
+
+
+availability of audit records.
+
+
+
+
+
+
+
+
+FPT_TUD_EXT.1 FPT_TUD_EXT.1 supports the objective by allowing
+users to determine the version of the TOE's hardware,
+software/firmware, and installed applications.
+
+
+**5.2 Security Assurance Requirements**
+
+
+The Security Objectives in Section 4 Security Objectives were constructed to address threats identified in
+Section 3 Security Problem Description. The Security Functional Requirements (SFRs) in Section 5.1 Security
+Functional Requirements are a formal instantiation of the Security Objectives. The PP identifies the Security
+Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the documentation
+applicable for the evaluation and performs independent testing.
+
+
+This section lists the set of SARs from CC part 3 that are required in evaluations against this PP. Individual
+Evaluation Activities to be performed are specified both in Section 5.1 Security Functional Requirements as
+well as in this section.
+
+
+The general model for evaluation of TOEs against STs written to conform to this PP is as follows:
+
+
+After the ST has been approved for evaluation, the ITSEF will obtain the TOE, supporting environmental IT,
+and the administrative/user guides for the TOE. The ITSEF is expected to perform actions mandated by the
+Common Evaluation Methodology (CEM) for the ASE and ALC SARs. The ITSEF also performs the Evaluation
+Activities contained within Section 5.1 Security Functional Requirements, which are intended to be an
+interpretation of the other CEM evaluation requirements as they apply to the specific technology instantiated
+in the TOE. The Evaluation Activities that are captured in Section 5.1 Security Functional Requirements also
+provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the
+PP.
+
+
+The TOE Security Assurance Requirements are identified in Table 9.
+
+
+Table 9: Security Assurance Requirements
+
+
+**Assurance Class** **Assurance Components**
+
+
+Security Target (ASE) Conformance Claims (ASE_CCL.1)
+
+
+Extended Components Definition (ASE_ECD.1)
+
+
+ST Introduction (ASE_INT.1)
+
+
+Security Objectives for the Operational Environment (ASE_OBJ.1)
+
+
+Stated Security Requirements (ASE_REQ.1)
+
+
+Security Problem Definition (ASE_SPD.1)
+
+
+TOE Summary Specification (ASE_TSS.1)
+
+
+Development (ADV) Basic Functional Specification (ADV_FSP.1)
+
+
+
+
+
+Tests (ATE) Independent Testing โ Sample (ATE_IND.1)
+
+
+Vulnerability Assessment (AVA) Vulnerability Survey (AVA_VAN.1)
+
+
+**5.2.1 Class ASE: Security Target**
+The ST is evaluated as per ASE activities defined in the CEM for ASE_CCL.1, ASE_ECD.1, ASE_INT.1,
+ASE_OBJ.1, ASE_REQ.1, ASE_SPD.1, and ASE_TSS.1. In addition, there may be Evaluation Activities specified
+within Section 5.1 Security Functional Requirements that call for necessary descriptions to be included in the
+TSS that are specific to the TOE technology type.
+
+
+**5.2.2 Class ADV: Development**
+
+The design information about the TOE is contained in the guidance documentation available to the end user
+as well as the TSS portion of the ST, and any additional information required by this PP that is not to be made
+public.
+
+
+**ADV_FSP.1 Basic Functional Specification**
+
+
+The functional specification describes the TOE Security Functions Interface (TSFIs). It is not
+necessary to have a formal or complete specification of these interfaces. Additionally, because TOEs
+conforming to this PP will necessarily have interfaces to the Operational Environment that are not
+directly invokable by TOE users, there is little point specifying that such interfaces be described in
+and of themselves since only indirect testing of such interfaces may be possible. For this PP, the
+activities for this family should focus on understanding the interfaces presented in the TSS in
+response to the functional requirements and the interfaces presented in the AGD documentation. No
+additional "functional specification" documentation is necessary to satisfy the evaluation activities
+specified.
+
+
+The interfaces that need to be evaluated are characterized through the information needed to
+perform the evaluation activities listed, rather than as an independent, abstract list.
+
+
+**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.
+
+
+**Application Note:** As indicated in the introduction to this section, the functional
+specification is comprised of the information contained in the AGD_OPE,
+AGD_PRE, and the API information that is provided to application developers,
+including the APIs that require privilege to invoke.
+
+
+The developer may reference a website accessible to application developers and
+the evaluator. The API documentation must include those interfaces required in
+this profile. The API documentation must clearly indicate to which products and
+versions each available function applies.
+
+
+The evaluation activities in the functional requirements point to evidence that
+should exist in the documentation and TSS section; since these are directly
+associated with the SFRs, the tracing in element ADV_FSP.1.2D is implicitly
+already done and no additional documentation is necessary.
+
+
+**Content and presentation elements:**
+
+
+ADV_FSP.1.1C
+
+
+ADV_FSP.1.2C
+
+
+ADV_FSP.1.3C
+
+
+ADV_FSP.1.4C
+
+
+
+The functional specification shall describe the purpose and method of use for
+each SFR-enforcing and SFR-supporting TSFI.
+
+
+The functional specification shall identify all parameters associated with each
+SFR-enforcing and SFR-supporting TSFI.
+
+
+The functional specification shall provide rationale for the implicit categorization
+of interfaces as SFR-non-interfering.
+
+
+The tracing shall demonstrate that the SFRs trace to TSFIs in the functional
+specification.
+
+
+
+**Evaluator action elements:**
+
+
+ADV_FSP.1.1E
+
+The evaluator shall confirm that the information provided meets all requirements
+for content and presentation of evidence.
+
+
+ADV_FSP.1.2E
+
+The evaluator shall determine that the functional specification is an accurate and
+complete instantiation of the SFRs.
+
+
+**Evaluation Activities**
+
+
+
+
+
+**5.2.3 Class AGD: Guidance Documentation**
+The guidance documents will be provided with the ST. Guidance must include a description of how the IT
+personnel verifies that the Operational Environment can fulfill its role for the security functionality. The
+documentation should be in an informal style and readable by the IT personnel.
+
+
+Guidance must be provided for every operational environment that the product supports as claimed in the ST.
+This guidance includes:
+
+Instructions to successfully install the TSF in that environment
+Instructions to manage the security of the TSF as a product and as a component of the larger operational
+environment
+Instructions to provide a protected administrative capability
+
+
+Guidance pertaining to particular security functionality is also provided; requirements on such guidance are
+contained in the evaluation activities specified with each requirement.
+
+
+**AGD_OPE.1 Operational User Guidance**
+
+
+**Developer action elements:**
+
+
+AGD_OPE.1.1D
+
+The developer shall provide operational user guidance.
+
+
+**Application Note:** The operational user guidance does not have to be contained
+in a single document. Guidance to users, administrators and application
+developers can be spread among documents or web pages. Where appropriate,
+the guidance documentation is expressed in the eXtensible Configuration
+Checklist Description Format (XCCDF) to support security automation.
+
+
+Rather than repeat information here, the developer should review the evaluation
+activities for this component to ascertain the specifics of the guidance that the
+evaluator will be checking for. This will provide the necessary information for
+the preparation of acceptable guidance.
+
+
+**Content and presentation elements:**
+
+
+AGD_OPE.1.1C
+
+The operational user guidance shall describe, for each user role, the useraccessible functions and privileges that should be controlled in a secure
+processing environment, including appropriate warnings.
+
+
+AGD_OPE.1.2C
+
+
+AGD_OPE.1.3C
+
+
+AGD_OPE.1.4C
+
+
+AGD_OPE.1.5C
+
+
+AGD_OPE.1.6C
+
+
+AGD_OPE.1.7C
+
+
+
+**Application Note:** User and administrator (e.g., MDM agent), and application
+developer are to be considered in the definition of user role.
+
+
+The operational user guidance shall describe, for each user role, how to use the
+available interfaces provided by the TOE in a secure manner.
+
+
+The operational user guidance shall describe, for each user role, the available
+functions and interfaces, in particular all security parameters under the control
+of the user, indicating secure values as appropriate.
+
+
+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.
+
+
+The operational user guidance shall identify all possible modes of operation of
+the OS (including operation following failure or operational error), their
+consequences, and implications for maintaining secure operation.
+
+
+The operational user guidance shall, for each user role, describe the security
+measures to be followed in order to fulfill the security objectives for the
+operational environment as described in the ST.
+
+
+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.
+
+
+**Evaluation Activities**
+
+
+
+
+
+**AGD_PRE.1 Preparative Procedures**
+
+
+**Developer action elements:**
+
+
+AGD_PRE.1.1D
+
+The developer shall provide the TOE, including its preparative procedures.
+
+
+**Application Note:** As with the operational guidance, the developer should look
+to the evaluation activities to determine the required content with respect to
+preparative procedures.
+
+
+**Content and presentation elements:**
+
+
+AGD_PRE.1.1C
+
+The preparative procedures shall describe all the steps necessary for secure
+
+
+AGD_PRE.1.2C
+
+
+
+acceptance of the delivered TOE in accordance with the developer's delivery
+procedures.
+
+
+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 OS can
+be prepared securely for operation.
+
+
+**Evaluation Activities**
+
+
+
+
+
+**5.2.4 Class ALC: Life-cycle Support**
+
+At the assurance level provided for TOEs conformant to this PP, life-cycle support is limited to end-uservisible aspects of the life-cycle, rather than an examination of the TOE vendorโs development and
+configuration management process. This is not meant to diminish the critical role that a developerโs practices
+play in contributing to the overall trustworthiness of a product; rather, it is a reflection on the information to
+be made available for evaluation at this assurance level.
+
+
+**ALC_CMC.1 Labeling of the TOE**
+
+
+This component is targeted at identifying the TOE such that it can be distinguished from other
+products or versions from the same vendor and can be easily specified when being procured by an
+end user.
+
+
+**Developer action elements:**
+
+
+ALC_CMC.1.1D
+
+The developer shall provide the TOE and a reference for the TOE.
+
+
+**Content and presentation elements:**
+
+
+ALC_CMC.1.1C
+
+The TOE shall be labeled with a 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.
+
+
+**Evaluation Activities**
+
+
+
+
+
+**ALC_CMS.1 TOE CM Coverage**
+
+
+Given the scope of the TOE and its associated evaluation evidence requirements, this componentโs
+evaluation activities are covered by the evaluation activities listed for ALC_CMC.1.
+
+
+**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 following: 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.
+
+
+**Application Note:** The "evaluation evidence required by the SARs" in this PP is
+limited to the information in the ST coupled with the guidance provided to
+administrators and users under the AGD requirements. By ensuring that the TOE
+is specifically identified and that this identification is consistent in the ST and in
+the AGD guidance (as done in the evaluation activity for ALC_CMC.1), the
+evaluator implicitly confirms the information required by this component.
+
+
+Life-cycle support is targeted aspects of the developerโs life-cycle and
+instructions to providers of applications for the developerโs devices, rather than
+an in-depth examination of the TSF manufacturerโs development and
+configuration management process. This is not meant to diminish the critical
+role that a developerโs practices play in contributing to the overall
+trustworthiness of a product; rather, itโs a reflection on the information to be
+made available for evaluation.
+
+
+**Evaluation Activities**
+
+
+**ALC_TSU_EXT.1 Timely Security Updates**
+
+
+This component requires the TOE developer, in conjunction with any other necessary parties, to
+provide information as to how the end-user devices are updated to address security issues in a timely
+manner. The documentation describes the process of providing updates to the public from the time a
+security flaw is reported/discovered, to the time an update is released. This description includes the
+parties involved (e.g., the developer, cellular carriers) and the steps that are performed (e.g.,
+developer testing, carrier testing), including worst-case time periods, before an update is made
+available to the public.
+
+
+**Developer action elements:**
+
+
+ALC_TSU_EXT.1.1D
+
+The developer shall provide a description in the TSS of how timely security
+updates are made to the TOE.
+
+
+**Content and presentation elements:**
+
+
+ALC_TSU_EXT.1.1C
+
+The description shall include the process for creating and deploying security
+updates for the TOE software.
+
+
+**Note:** The software to be described includes the operating systems of the
+application processor and the baseband processor, as well as any firmware and
+applications. The process description includes the TOE developer processes as
+well as any third-party (carrier) processes. The process description includes each
+deployment mechanism (e.g., over-the-air updates, per-carrier updates,
+downloaded updates).
+
+
+ALC_TSU_EXT.1.2C
+
+The description shall express the time window as the length of time, in days,
+between public disclosure of a vulnerability and the public availability of security
+updates to the TOE.
+
+
+ALC_TSU_EXT.1.3C
+
+
+ALC_TSU_EXT.1.4C
+
+
+
+**Note:** The total length of time may be presented as a summation of the periods
+of time that each party (e.g., TOE developer, mobile carrier) on the critical path
+consumes. The time period until public availability per deployment mechanism
+may differ; each is described.
+
+
+The description shall include the mechanisms publicly available for reporting
+security issues pertaining to the TOE.
+
+
+**Note:** The reporting mechanism could include web sites, email addresses, as
+well as a means to protect the sensitive nature of the report (e.g., public keys
+that could be used to encrypt the details of a proof-of-concept exploit).
+
+
+The description shall include where users can seek information about the
+availability of new updates including details (e.g. CVE identifiers) of the specific
+public vulnerabilities corrected by each update.
+
+
+**Note:** The purpose of providing this information is so that users and enterprises
+can determine which devices are susceptible to publicly known vulnerabilities so
+that they can make appropriate risk decisions, such as limiting access to
+enterprise resources until updates are installed.
+
+
+
+**Evaluator action elements:**
+
+
+ALC_TSU_EXT.1.1E
+
+The evaluator shall confirm that the information provided meets all requirements
+for content and presentation of evidence.
+
+
+**Evaluation Activities**
+
+
+
+
+
+**5.2.5 Class ATE: Tests**
+Testing is specified for functional aspects of the system as well as aspects that take advantage of design or
+implementation weaknesses. The former is done through the ATE_IND family, while the latter is through the
+AVA_VAN family. At the assurance level specified in this PP, testing is based on advertised functionality and
+interfaces with dependency on the availability of design information. One of the primary outputs of the
+evaluation process is the test report as specified in the following requirements.
+
+
+Since many of the APIs are not exposed at the user interface (e.g., touch screen), the ability to stimulate the
+necessary interfaces requires a developerโs test environment. This test environment will allow the evaluator,
+for example, to access APIs and view file system information that is not available on consumer Mobile
+Devices.
+
+
+**ATE_IND.1 Independent Testing โ Conformance**
+
+
+Testing is performed to confirm the functionality described in the TSS as well as the administrative
+(including configuration and operational) documentation provided. The focus of the testing is to
+confirm that the requirements specified in Section 5.1 Security Functional Requirements being met,
+although some additional testing is specified for SARs in Section 5.2 Security Assurance
+Requirements. The Evaluation Activities identify the additional testing activities associated with
+
+
+these components. The evaluator produces a test report documenting the plan for and results of
+testing, as well as coverage arguments focused on the platform/TOE combinations that are claiming
+conformance to this PP.
+
+
+**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.
+
+
+**Evaluation Activities**
+
+
+**5.2.6 Class AVA: Vulnerability Assessment**
+
+For the current generation of this protection profile, the evaluation lab is expected to survey open sources to
+discover what vulnerabilities have been discovered in these types of products. In most cases, these
+vulnerabilities will require sophistication beyond that of a basic attacker. Until penetration tools are created
+and uniformly distributed to the evaluation labs, the evaluator will not be expected to test for these
+vulnerabilities in the TOE. The labs will be expected to comment on the likelihood of these vulnerabilities
+given the documentation provided by the vendor. This information will be used in the development of
+penetration testing tools and for the development of future protection profiles.
+
+
+**AVA_VAN.1 Vulnerability Survey**
+
+
+**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 requirements
+for content and presentation of evidence.
+
+
+AVA_VAN.1.2E
+
+The evaluator shall perform a search of public domain sources to identify
+potential vulnerabilities in the TOE.
+
+
+**Application Note:** Public domain sources include the Common Vulnerabilities
+and Exposures (CVE) dictionary for publicly-known vulnerabilities.
+
+
+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 possessing Basic attack potential.
+
+
+**Evaluation Activities**
+
+
+# **Appendix A - Optional Requirements**
+
+As indicated in the introduction to this PP, the baseline requirements (those that must be performed by the
+TOE) are contained in the body of this PP. This appendix contains three other types of optional requirements
+that may be included in the ST, but are not required in order to conform to this PP. However, applied
+modules, packages and/or use cases may refine specific requirements as mandatory.
+
+
+The first type (A.1 Strictly Optional Requirements) are strictly optional requirements that are independent of
+the TOE implementing any function. If the TOE fulfills any of these requirements or supports a certain
+functionality, the vendor is encouraged to include the SFRs in the ST, but are not required in order to
+conform to this PP.
+
+
+The second type (A.2 Objective Requirements) are objective requirements that describe security functionality
+not yet widely available in commercial technology. The requirements are not currently mandated in the body
+of this PP, but will be included in the baseline requirements in future versions of this PP. Adoption by vendors
+is encouraged and expected as soon as possible.
+
+
+The third type (A.3 Implementation-dependent Requirements) are dependent on the TOE implementing a
+particular function. If the TOE fulfills any of these requirements, the vendor must either add the related SFR
+or disable the functionality for the evaluated configuration.
+
+
+**A.1 Strictly Optional Requirements**
+
+
+**A.1.1 Class: Identification and Authentication (FIA)**
+
+
+**FIA_UAU_EXT.4 Secondary User Authentication**
+
+
+FIA_UAU_EXT.4.1
+
+The TSF shall provide a secondary authentication mechanism for accessing
+Enterprise applications and resources. The secondary authentication mechanism
+shall control access to the Enterprise application and shared resources and shall
+be incorporated into the encryption of protected and sensitive data belonging to
+Enterprise applications and shared resources.
+
+
+**Application Note:** For the BYOD use case, Enterprise applications and data
+must be protected using a different password than the user authentication to
+gain access to the personal applications and data, if configured.
+
+
+This requirement must be included in the ST if the TOE implements a container
+solution, in which there is a separate authentication, to separate user and
+Enterprise applications and resources.
+
+
+FIA_UAU_EXT.4.2
+
+The TSF shall require the user to present the secondary authentication factor
+prior to decryption of Enterprise application data and Enterprise shared
+resource data.
+
+
+**Application Note:** The intent of this requirement is to prevent decryption of
+protected Enterprise application data and Enterprise shared resource data
+before the user has authenticated to the device using the secondary
+authentication factor. Enterprise shared resource data consists of the
+FDP_ACF_EXT.2.1 selections.
+
+
+**Evaluation Activities**
+
+
+_FIA_UAU_EXT.4.1_
+_**TSS**_
+_There are no TSS evaluation activities for this element._
+
+
+_**Guidance**_
+_There are no guidance evaluation activities for this element._
+
+
+_**Tests**_
+_The Evaluation Activities for any selected requirements related to device authentication must be_
+_separately performed for the secondary authentication mechanism (in addition to activities_
+_performed for the primary authentication mechanism). The requirements are:_
+_FIA_UAU.6/CREDENTIAL, FIA_UAU.6/LOCKED, FIA_PMG_EXT.1, FIA_TRT_EXT.1, FIA_UAU.7,_
+_FIA_UAU_EXT.2, FTA_SSL_EXT.1, FCS_STG_EXT.2, FMT_SMF.1/FMT_MOF_EXT.1 #1, #2, #8,_
+_#21, and #36._
+
+
+_Additionally, FIA_AFL_EXT.1 must be met, except that in FIA_AFL_EXT.1.2 the separate test is_
+_performed with the text "wipe of all protected data" changed to "wipe of all Enterprise_
+_application data and all Enterprise shared resource data."_
+
+
+_FIA_UAU_EXT.4.2_
+_**TSS**_
+_The evaluator shall verify that the TSS section of the ST describes the process for decrypting_
+_Enterprise application data and shared resource data. The evaluator shall ensure that this_
+_process requires the user to enter an Authentication Factor and, in accordance with_
+_FCS_CKM_EXT.3, derives a KEK which is used to protect the software-based secure key storage_
+_and (optionally) DEKs for sensitive data, in accordance with FCS_STG_EXT.2._
+
+
+_**Guidance**_
+_There are no guidance evaluation activities for this element._
+
+
+_**Tests**_
+_There are no test evaluation activities for this element._
+
+
+**A.2 Objective Requirements**
+
+
+**A.2.1 Class: Security Audit (FAU)**
+
+
+**FAU_SEL.1 Selective Audit**
+
+
+FAU_SEL.1.1
+
+The TSF shall be able to select the set of events to be audited from the set of all
+auditable events based on the following attributes: [ **selection** :
+
+_[event type]_
+
+_[success of auditable security events_
+_failure of auditable security events_
+
+_[_ _**assignment**_ _: other attributes]]_
+
+].
+
+
+**Application Note:** The intent of this requirement is to identify all criteria that
+can be selected to trigger an audit event. This can be configured through an
+interface on the TSF for a user or administrator to invoke. For the ST author, the
+assignment is used to list any additional criteria or "none".
+
+
+**Evaluation Activities**
+
+
+**A.2.2 Class: Cryptographic Support (FCS)**
+
+
+**FCS_RBG_EXT.2 Random Bit Generator State Preservation**
+
+
+FCS_RBG_EXT.2.1
+
+The TSF shall save the state of the deterministic RBG at power-off, and shall use
+this state as input to the deterministic RBG at startup.
+
+
+**Application Note:** The capability to add the state saved at power-off as input to
+the RBG prevents an RBG that is slow to gather entropy from producing the
+same output regularly and across reboots. Since there is no guarantee of the
+protections provided when the state is stored (or a requirement for any such
+protection), it is assumed that the state is 'known', and therefore cannot
+contribute entropy to the RBG, but can introduce enough variation that the
+initial RBG values are not predictable and exploitable.
+
+
+**Evaluation Activities**
+
+
+
+
+
+**FCS_RBG_EXT.3 Support for Personalization String**
+
+
+FCS_RBG_EXT.3.1
+
+The TSF shall allow applications to add data to the deterministic RBG using the
+Personalization String as defined in SP 800-90A.
+
+
+**Application Note:** As specified in SP 800-90A, the TSF must not count data
+input from an application towards the entropy required by FCS_RBG_EXT.1.
+Thus, the TSF must not allow the only input to the RBG seed to be from an
+application.
+
+
+**Evaluation Activities**
+
+
+
+
+
+
+
+**FCS_SRV_EXT.2 Cryptographic Key Storage Services**
+
+
+FCS_SRV_EXT.2.1
+
+The TSF shall provide a mechanism for applications to request the TSF to
+perform the following cryptographic operations: [
+
+_Algorithms in FCS_COP.1/ENCRYPT_
+_Algorithms in FCS_COP.1/SIGN_
+
+] by keys stored in the secure key storage.
+
+
+**Application Note:** The TOE will, therefore, be required to perform
+cryptographic operations on behalf of applications using the keys stored in the
+TOEโs secure key storage.
+
+
+**Evaluation Activities**
+
+
+**A.2.3 Class: User Data Protection (FDP)**
+
+
+**FDP_ACF_EXT.3 Security Attribute Based Access Control**
+
+
+FDP_ACF_EXT.3.1
+
+The TSF shall enforce an access control policy that prohibits an application from
+granting both write and execute permission to a file on the device except for
+
+[ **selection** : _files stored in the application's private data folder_, _no exceptions_ ].
+
+
+**Evaluation Activities**
+
+
+
+
+
+
+
+**FDP_BCK_EXT.1 Application Backup**
+
+
+FDP_BCK_EXT.1.1
+
+The TSF shall provide a mechanism for applications to mark [ **selection** : _all_
+_application data_, _selected application data_ ] to be excluded from device backups.
+
+
+**Application Note:** Device backups include any mechanism built into the TOE
+that allows stored application data to be extracted over a physical port or sent
+over the network, but does not include any functionality implemented by a
+specific application itself if the application is not included in the TOE. The lack of
+a public/documented API for performing backups, when a private/undocumented
+API exists, is not sufficient to meet this requirement.
+
+
+**Evaluation Activities**
+
+
+_FDP_BCK_EXT.1_
+_**TSS**_
+_There are no TSS evaluation activities for this component._
+
+
+_**Guidance**_
+_There are no guidance evaluation activities for this component._
+
+
+_**Tests**_
+_If all application data is selected, the evaluator shall install an application that has marked all of_
+_its application data to be excluded from backups. The evaluator shall cause data to be placed_
+_into the applicationโs storage area. The evaluator shall attempt to back up the application data_
+_and verify that the backup fails or that the applicationโs data was not included in the backup._
+
+
+_If selected application data is selected, the evaluator shall install an application that has marked_
+_selected application data to be excluded from backups. The evaluator shall cause data covered_
+_by "selected application data" to be placed into the applicationโs storage area. The evaluator_
+_shall attempt to backup that selected application data and verify that either the backup fails or_
+_that the selected data is excluded from the backup._
+
+
+**FDP_BLT_EXT.1 Limitation of Bluetooth Device Access**
+
+
+FDP_BLT_EXT.1.1
+
+The TSF shall limit the applications that may communicate with a particular
+paired Bluetooth device.
+
+
+**Application Note:** Not every application with privileges to use Bluetooth should
+be permitted to communicate with every paired Bluetooth device. For example,
+the TSF may choose to require that only the application that initiated the current
+connection may communicate with the device, or it may strictly tie the paired
+device to the first application that makes a socket connection to the device
+following initial pairing. Additionally, for more flexibility, the TSF may choose to
+provide the user with a way to select which applications on the device may
+communicate with or observe communications with each paired Bluetooth
+device.
+
+
+**Evaluation Activities**
+
+
+
+
+
+**A.2.4 Class: Identification and Authentication (FIA)**
+
+
+**FIA_X509_EXT.4 X509 Certificate Enrollment**
+
+
+FIA_X509_EXT.4.1
+
+The TSF shall use the Enrollment over Secure Transport (EST) protocol as
+specified in RFC 7030 to request certificate enrollment using the simple
+enrollment method described in RFC 7030 Section 4.2.
+
+
+FIA_X509_EXT.4.2
+
+The TSF shall be capable of authenticating EST requests using an existing
+certificate and corresponding private key as specified by RFC 7030 Section
+3.3.2.
+
+
+FIA_X509_EXT.4.3
+
+The TSF shall be capable of authenticating EST requests using HTTP Basic
+Authentication with a username and password as specified by RFC 7030 Section
+3.2.3.
+
+
+FIA_X509_EXT.4.4
+
+The TSF shall perform authentication of the EST server using an Explicit Trust
+
+
+FIA_X509_EXT.4.5
+
+
+FIA_X509_EXT.4.6
+
+
+FIA_X509_EXT.4.7
+
+
+FIA_X509_EXT.4.8
+
+
+
+Anchor following the rules described in RFC 7030, section 3.6.1.
+
+
+**Application Note:** EST also uses HTTPS as specified in FCS_HTTPS_EXT.1 to
+establish a secure connection to an EST server. The separate Trust Anchor
+Database dedicated to EST operations is described as Explicit Trust Anchors in
+RFC 7030.
+
+
+The TSF shall be capable of requesting server-provided private keys as specified
+in RFC 7030 Section 4.4.
+
+
+The TSF shall be capable of updating its EST-specific Trust Anchor Database
+using the "Root CA Key Update" process described in RFC 7030 Section 4.1.3.
+
+
+The TSF shall generate a Certificate Request Message for EST as specified in
+RFC 2986 and be able to provide the following information in the request: public
+key and [ **selection** : _device-specific information_, _Common Name_, _Organization_,
+_Organizational Unit_, _Country_ ].
+
+
+**Application Note:** The public key referenced is the public key portion of the
+public-private key pair generated by the TOE as specified in FCS_CKM.1.
+
+
+The TSF shall validate the chain of certificates from the Root CA certificate in
+the Trust Anchor Database to the EST Server CA certificate upon receiving a CA
+Certificates Response.
+
+
+
+**Evaluation Activities**
+
+
+_FIA_X509_EXT.4_
+_**TSS**_
+_There are no TSS evaluation activities for this component._
+
+
+_**Guidance**_
+_The evaluator shall check to ensure that the operational guidance contains instructions on_
+_requesting certificates from an EST server, including generating a Certificate Request Message._
+
+
+_**Tests**_
+_The evaluator shall also perform the following tests. Other tests are performed in conjunction_
+_with the evaluation activity listed in the Package for Transport Layer Security._
+
+_Test 120: The evaluator shall use the operational guidance to cause the TOE to request_
+_certificate enrollment from an EST server using the simple enrollment method described in_
+_RFC 7030 Section 4.2, authenticating the certificate request to the server using an existing_
+_certificate and private key as described by RFC 7030 Section 3.3.2. The evaluator shall_
+_confirm that the resulting certificate is successfully obtained and installed in the TOE key_
+_store._
+
+
+_Test 121: The evaluator shall use the operational guidance to cause the TOE to request_
+_certificate enrollment from an EST server using the simple enrollment method described in_
+_RFC 7030 Section 4.2, authenticating the certificate request to the server using a username_
+_and password as described by RFC 7030 Section 3.2.3. The evaluator shall confirm that the_
+_resulting certificate is successfully obtained and installed in the TOE key store._
+
+
+_Test 122: The evaluator shall modify the EST server to return a certificate containing a_
+_different public key than the key included in the TOEโs certificate request. The evaluator_
+_shall use the operational guidance to cause the TOE to request certificate enrollment from_
+_an EST server. The evaluator shall confirm that the TOE does not accept the resulting_
+_certificate since the public key in the issued certificate does not match the public key in the_
+_certificate request._
+
+
+_Test 123: The evaluator shall configure the EST server or use a man-in-the-middle tool to_
+_present a server certificate to the TOE that is present in the TOE general Trust Anchor_
+_Database but not its EST-specific Trust Anchor Database. The evaluator shall cause the TOE_
+_to request certificate enrollment from the EST server. The evaluator shall verify that the_
+_request is not successful._
+
+
+_Test 124: The evaluator shall configure the EST server or use a man-in-the-middle tool to_
+_present an invalid certificate. The evaluator shall cause the TOE to request certificate_
+_enrollment from the EST server. The evaluator shall verify that the request is not successful_
+_The evaluator shall configure the EST server or use a man-in-the-middle tool to present a_
+_certificate that does not have the CMC RA purpose and verify that requests to the EST_
+_server fail. The tester shall repeat the test using a valid certificate and a certificate that_
+_contains the CMC RA purpose and verify that the certificate enrollment requests succeed._
+
+
+_Test 125: The evaluator shall use a packet sniffing tool between the TOE and an EST server._
+_The evaluator shall turn on the sniffing tool and cause the TOE to request certificate_
+_enrollment from an EST server. The evaluator shall verify that the EST protocol interaction_
+_occurs over a Transport Layer Security (TLS) protected connection. The evaluator is not_
+_expected to decrypt the connection but rather observe that the packets conform to the TLS_
+_protocol format._
+
+
+_Test 126: The evaluator shall use the operational guidance to cause the TOE to request a_
+_server-provided private key and certificate from an EST server. The evaluator shall confirm_
+_that the resulting private key and certificate are successfully obtained and installed in the_
+_TOE key store._
+
+
+_Test 127: The evaluator shall modify the EST server to, in response to a server-provided_
+_private key and certificate request, return a private key that does not correspond with the_
+_public key in the returned certificate. The evaluator shall use the operational guidance to_
+_cause the TOE to request a server-provided private key and certificate. The evaluator shall_
+_confirm that the TOE does not accept the resulting private key and certificate since the_
+_private key and public key do not correspond._
+
+
+_Test 128: The evaluator shall configure the EST server to provide a "Root CA Key Update"_
+_as described in RFC 7030 Section 4.1.3. The evaluator shall cause the TOE to request CA_
+_certificates from the EST server and shall confirm that the EST-specific Trust Anchor_
+_Database is updated with the new trust anchor._
+
+
+_Test 129: The evaluator shall configure the EST server to provide a "Root CA Key Update"_
+_as described in RFC 7030 Section 4.1.3, but shall modify part of the NewWithOld_
+_certificateโs generated signature. The evaluator shall cause the TOE to request CA_
+_certificates from the EST server and shall confirm that the EST-specific Trust Anchor_
+_Database is not updated with the new trust anchor since the signature did not verify._
+
+
+_Test 130: The evaluator shall use the operational guidance to cause the TOE to generate a_
+_certificate request message. The evaluator shall capture the generated message and ensure_
+_that it conforms to the format specified by RFC 2986. The evaluator shall confirm that the_
+_certificate request provides the public key and other required information, including any_
+_necessary user-input information._
+
+
+**FIA_X509_EXT.5 X.509 Certificate Requests**
+
+
+FIA_X509_EXT.5.1
+
+The TSF shall generate a Certificate Request Message as specified in RFC 2986
+and be able to provide the following information in the request: public key and
+
+[ **selection** : _device-specific information_, _Common Name_, _Organization_,
+_Organizational Unit_, _Country_ ].
+
+
+**Application Note:** The public key referenced in FIA_X509_EXT.5.1 is the public
+key portion of the public-private key pair generated by the TOE as specified in
+FCS_CKM.1. The trusted channel requirements do not apply to communication
+with the CA for the certificate request/response messages.
+
+
+As Enrollment over Secure Transport (EST) is a new standard that has not yet
+been widely adopted, this requirement is included as an interim objective
+requirement in order to allow developers to distinguish those products which
+have do have the ability to generate Certificate Request Messages but do not yet
+implement EST.
+
+
+FIA_X509_EXT.5.2
+
+The TSF shall validate the chain of certificates from the Root CA upon receiving
+the CA Certificate Response.
+
+
+**Evaluation Activities**
+
+
+_FIA_X509_EXT.5_
+_**TSS**_
+_If the ST author selects "device-specific information", the evaluator shall verify that the TSS_
+_contains a description of the device-specific fields used in certificate requests._
+
+
+_**Guidance**_
+_The evaluator shall check to ensure that the operational guidance contains instructions on_
+_generating a Certificate Request Message. If the ST author selects "Common Name",_
+_"Organization", "Organizational Unit", or "Country", the evaluator shall ensure that this guidance_
+_includes instructions for establishing these fields before creating the certificate request_
+_message._
+
+
+_**Tests**_
+
+
+_The evaluator shall also perform the following tests:_
+
+_Test 131: The evaluator shall use the operational guidance to cause the TOE to generate a_
+_certificate request message. The evaluator shall capture the generated message and ensure_
+_that it conforms to the format specified. The evaluator shall confirm that the certificate_
+_request provides the public key and other required information, including any necessary_
+_user-input information._
+
+
+_Test 132: The evaluator shall demonstrate that validating a certificate response message_
+_without a valid certification path results in the function failing. The evaluator shall then_
+_load a certificate or certificates as trusted CAs needed to validate the certificate response_
+_message, and demonstrate that the function succeeds. The evaluator shall then delete one_
+_of the certificates, and show that the function fails._
+
+
+**A.2.5 Class: Security Management (FMT)**
+
+
+**FMT_SMF_EXT.3 Current Administrator**
+
+
+FMT_SMF_EXT.3.1
+
+The TSF shall provide a mechanism that allows users to view a list of currently
+authorized administrators and the management functions that each
+administrator is authorized to perform.
+
+
+**Evaluation Activities**
+
+
+
+
+
+**A.2.6 Class: Protection of the TSF (FPT)**
+
+
+**FPT_AEX_EXT.5 Kernel Address Space Layout Randomization**
+
+
+FPT_AEX_EXT.5.1
+
+The TSF shall provide address space layout randomization (ASLR) to the kernel.
+
+
+FPT_AEX_EXT.5.2
+
+The base address of any kernel-space memory mapping will consist of
+
+[ **assignment** : _number greater than or equal to 4_ ] unpredictable bits.
+
+
+**Application Note:** The unpredictable bits may be provided by the TSF RBG (as
+specified in FCS_RBG_EXT.1).
+
+
+**Evaluation Activities**
+
+
+
+
+
+
+**FPT_AEX_EXT.6 Write or Execute Memory Page Permissions**
+
+
+FPT_AEX_EXT.6.1
+
+The TSF shall prevent write and execute permissions from being simultaneously
+granted to any page of physical memory [ **selection** : _with no exceptions_,
+
+_[_ _**assignment**_ _: specific exceptions]_ ].
+
+
+**Application Note:** Memory used for just-in-time (JIT) compilation is anticipated
+as an exception in this requirement; if so, the ST author must address how this
+exception is permitted. It is expected that the memory management unit will
+transition the system to a non-operational state if any violation is detected in
+kernel memory space.
+
+
+**Evaluation Activities**
+
+
+
+
+
+**FPT_AEX_EXT.7 Heap Overflow Protection**
+
+
+FPT_AEX_EXT.7.1
+
+The TSF shall include heap-based buffer overflow protections in the runtime
+environment it provides to processes that execute on the application processor.
+
+
+**Application Note:** These heap-based buffer overflow protections are expected
+to ensure the integrity of heap metadata such as memory addresses or offsets
+recorded by the heap implementation to manage memory blocks. This includes
+chunk headers, look-aside lists, and other data structures used to track the state
+and location of memory blocks managed by the heap.
+
+
+**Evaluation Activities**
+
+
+
+
+
+
+
+**FPT_BBD_EXT.1 Application Processor Mediation**
+
+
+FPT_BBD_EXT.1.1
+
+The TSF shall prevent code executing on any baseband processor (BP) from
+accessing application processor (AP) resources except when mediated by the AP.
+
+
+**Application Note:** These resources include:
+
+Volatile and non-volatile memory
+
+
+Control of and data from integrated and non-integrated peripherals (e.g.
+USB controllers, touch screen controllers, LCD controller, codecs)
+Control of and data from integrated and non-integrated I/O sensors (e.g.
+camera, light, microphone, GPS, accelerometers, geomagnetic field
+sensors)
+
+
+Mobile devices are becoming increasingly complex having an application
+processor that runs an operating system and user applications and separate
+baseband processors that handle cellular and other wireless network
+connectivity.
+
+
+The application processor within most modern Mobile Devices is a system
+on a chip (SoC) that integrates, for example, CPU/GPU cores and memory
+interface electronics into a single, power-efficient package.
+Baseband processors are becoming increasingly complex themselves
+delivering voice encoding alongside multiple independent radios (LTE, WiFi, Bluetooth, FM, GPS) in a single package containing multiple CPUs and
+DSPs.
+
+
+Thus, the baseband processors in these requirements include such integrated
+SoCs and include any radio processors (integrated or not) on the Mobile Device.
+
+
+All other requirements mostly, except where noted, apply to firmware/software
+on the application processor, but future requirements (notably, all Integrity,
+Access Control, and Anti-Exploitation requirements) will apply to application
+processors and baseband processors.
+
+
+**Evaluation Activities**
+
+
+
+
+
+**FPT_BLT_EXT.1 Limitation of Bluetooth Profile Support**
+
+
+FPT_BLT_EXT.1.1
+
+The TSF shall disable support for [ **assignment** : _list of Bluetooth profiles_ ]
+Bluetooth profiles when they are not currently being used by an application on
+the Mobile Device, and shall require explicit user action to enable them.
+
+
+**Application Note:** Some Bluetooth services incur more serious consequences if
+unauthorized remote devices gain access to them. Such services should be
+protected by measures like disabling support for the associated Bluetooth profile
+unless it is actively being used by an application on the Mobile Device (in order
+to prevent discovery by a Service Discovery Protocol search), and then requiring
+explicit user action to enable those profiles in order to use the services. It may
+be further appropriate to require additional user action before granting a remote
+device access to that service.
+
+
+For example, it may be appropriate to disable the OBEX Push Profile until a user
+on the Mobile Device pushes a button in an application indicating readiness to
+transfer an object. After completion of the object transfer, support for the OBEX
+profile should be suspended until the next time the user requests its use.
+
+
+**Evaluation Activities**
+
+
+_FPT_BLT_EXT.1_
+_**TSS**_
+_The evaluator shall ensure that the TSS lists all Bluetooth profiles that are disabled while not in_
+_use by an application and which need explicit user action in order to become enabled._
+
+
+_**Guidance**_
+_There are no guidance evaluation activities for this component._
+
+
+_**Tests**_
+_The evaluator shall perform the following tests:_
+
+_Test 134: While the service is not in active use by an application on the TOE, the evaluator_
+_shall attempt to discover a service associated with a "protected" Bluetooth profile (as_
+_specified by the requirement) on the TOE via a Service Discovery Protocol search. The_
+_evaluator shall verify that the service does not appear in the Service Discovery Protocol_
+_search results. Next, the evaluator shall attempt to gain remote access to the service from a_
+_device that does not currently have a trusted device relationship with the TOE. The_
+_evaluator shall verify that this attempt fails due to the unavailability of the service and_
+_profile._
+
+
+_Test 135: The evaluator shall repeat Test 1 with a device that currently has a trusted device_
+_relationship with the TOE and verify that the same behavior is exhibited._
+
+
+**FPT_NOT_EXT.2 Software Integrity Verification**
+
+
+FPT_NOT_EXT.2.1
+
+The TSF shall [ **selection** : _audit_, _provide the administrator with_ ] TSF-software
+integrity verification values.
+
+
+**Application Note:** These notifications are typically called remote attestation
+and these integrity values are typically called measurements. The integrity
+values are calculated from hashes of critical memory and values, including
+executable code. The ST author must select whether these values are logged as
+a part of FAU_GEN.1.1 or are provided to the administrator.
+
+
+FPT_NOT_EXT.2.2
+
+The TSF shall cryptographically sign all integrity verification values.
+
+
+**Application Note:** The intent of this requirement is to provide assurance to the
+administrator that the responses provided are from the TOE and have not been
+modified or spoofed by a man-in-the-middle such as a network-based adversary
+or a malicious MDM Agent.
+
+
+**Evaluation Activities**
+
+
+_FPT_NOT_EXT.2.1_
+_**TSS**_
+_The evaluator shall verify that the TSS describes which critical memory is measured for these_
+_integrity values and how the measurement is performed (including which TOE software_
+_performs these generates these values, how that software accesses the critical memory, and_
+_which algorithms are used)._
+
+
+_**Guidance**_
+_If the integrity values are provided to the administrator, the evaluator shall verify that the AGD_
+_guidance contains instructions for retrieving these values and information for interpreting them._
+_For example, if multiple measurements are taken, what those measurements are and how_
+_changes to those values relate to changes in the device state._
+
+
+_**Tests**_
+_**Evaluation Activity Note:**_ _The following test may require the developer to provide access to a_
+_test platform that provides the evaluator with tools that are typically not found on consumer_
+_Mobile Device products._
+
+
+_The evaluator shall repeat the following test for each measurement:_
+
+_Test 136: The evaluator shall boot the device in an approved state and record the_
+_measurement taken (either from the log or by using the administrative guidance to retrieve_
+_the value via an MDM Agent). The evaluator shall modify the critical memory or value that_
+_is measured. The evaluator shall boot the device and verify that the measurement changed._
+
+
+_FPT_NOT_EXT.2.2_
+_**TSS**_
+_The evaluator shall verify that the TSS describes which key the TSF uses to sign the responses to_
+_queries and the certificate used to prove ownership of the key, and the method of associating the_
+_certificate with a particular device manufacturer and model._
+
+
+_**Guidance**_
+_There are no guidance evaluation activities for this component._
+
+
+_**Tests**_
+_The evaluator shall perform the following test:_
+
+_Test 137: The evaluator shall write, or the developer shall provide, a management_
+_application that queries either the audit logs or the measurements. The evaluator shall_
+_verify that the responses to these queries are signed and verify the signatures against the_
+_TOEโs certificate._
+
+
+**FPT_TST_EXT.2/POSTKERNEL TSF Integrity Checking (Post-Kernel)**
+
+
+FPT_TST_EXT.2.1/POSTKERNEL
+
+The TSF shall verify the integrity of [ **selection** : _all executable code_,
+
+_[_ _**assignment**_ _: subset of executable code]_ ] stored in mutable media prior to its
+execution through the use of [ **selection** : _a digital signature using an immutable_
+_hardware asymmetric key_, _an immutable hardware hash of an asymmetric key_,
+_an immutable hardware hash_, _a digital signature using a hardware-protected_
+_asymmetric key_, _hardware-protected hash_ ].
+
+
+**Application Note:** All executable code covered in this requirement is executed
+after the kernel is loaded.
+
+
+If "all executable code in mutable media" is verified, implementation in hardware
+or in read-only memory is a natural logical consequence.
+
+
+At this time, the verification of software executed on other processors stored in
+mutable media is not required; however, it may be added in the first assignment.
+If all executable code (including bootloaders, kernel, device drivers, pre-loaded
+applications, user-loaded applications, and libraries) is verified, "all executable
+code stored in mutable media" should be selected.
+
+
+**Evaluation Activities**
+
+
+
+
+
+**FPT_TUD_EXT.5 Application Verification**
+
+
+FPT_TUD_EXT.5.1
+
+The TSF shall by default only install mobile applications cryptographically
+verified by [ **selection** : _a built-in X.509v3 certificate_, _a configured X.509v3_
+_certificate_ ].
+
+
+**Application Note:** The built-in certificate is installed by the manufacturer
+either at time of manufacture or as a part of system updates. The configured
+certificate used to verify the signature is set according to FMT_SMF.1 function
+33.
+
+
+**Evaluation Activities**
+
+
+_FPT_TUD_EXT.5_
+_**TSS**_
+_The evaluator shall verify that the TSS describes how mobile application software is verified at_
+_installation. The evaluator shall ensure that this method uses a digital signature by a code_
+_signing certificate._
+
+
+_**Guidance**_
+_There are no guidance evaluation activities for this component._
+
+
+_**Tests**_
+
+_Test 138: The evaluator shall write, or the developer shall provide access to, an application._
+_The evaluator shall try to install this application without a digitally signature and shall_
+
+
+_verify that installation fails. The evaluator shall attempt to install an application digitally_
+_signed with an appropriate certificate, and verify that installation succeeds._
+
+
+_Test 139: The evaluator shall digitally sign the application with an invalid certificate and_
+_verify that application installation fails. The evaluator shall digitally sign the application_
+_with a certificate that does not have the Code Signing purpose and verify that application_
+_installation fails. This test may be performed in conjunction with the Evaluation Activities_
+_for FIA_X509_EXT.1._
+
+
+_Test 140: If necessary, the evaluator shall configure the device to limit the public keys that_
+_can sign application software according to the AGD guidance. The evaluator shall digitally_
+_sign the application with a certificate disallowed by the device or configuration and verify_
+_that application installation fails. The evaluator shall attempt to install an application_
+_digitally signed with an authorized certificate and verify that application installation_
+_succeeds._
+
+
+**FPT_TUD_EXT.6 Trusted Update Verification**
+
+
+FPT_TUD_EXT.6.1
+
+The TSF shall verify that software updates to the TSF are a current or later
+version than the current version of the TSF.
+
+
+**Application Note:** A later version has a larger version number. The method for
+distinguishing newer software versions from older versions is determined by the
+manufacturer.
+
+
+**Evaluation Activities**
+
+
+
+
+
+**A.3 Implementation-dependent Requirements**
+
+
+**A.3.1 Bluetooth**
+If the TOE includes Bluetooth hardware, the following SFRs must be claimed:
+If this is implemented by the TOE, the following requirements must be included in the ST:
+
+
+**FDP_UPC_EXT.1/BLUETOOTH**
+
+
+**A.3.1.1 Class: User Data Protection (FDP)**
+
+
+**FDP_UPC_EXT.1/BLUETOOTH Inter-TSF User Data Transfer Protection (Bluetooth)**
+
+
+FDP_UPC_EXT.1.1/BLUETOOTH
+
+The TSF shall provide a means for non-TSF applications executing on the TOE to
+use [
+
+_Bluetooth BR/EDR in accordance with the PP-Module for Bluetooth, version_
+_1.0,_
+
+_and [_ _**selection**_ _:_
+
+_[Bluetooth LE in accordance with the PP-Module for Bluetooth, version 1.0](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=425&id=425)_
+_no other protocol_
+
+
+_]_ ] to provide a protected communication channel between the non-TSF
+application and another IT product that is logically distinct from other
+communication channels, provides assured identification of its end points,
+protects channel data from disclosure, and detects modification of the channel
+data.
+
+
+**Application Note:** If the TOE includes Bluetooth hardware, this requirement
+must be included in the ST. The intent of this requirement is that Bluetooth
+BR/EDR and optionally Bluetooth LE is available for use by user applications
+running on the device for use in connecting to distant-end services that are not
+necessarily part of the enterprise infrastructure. The ST author must list which
+trusted channel protocols are implemented by the Mobile Device for use by nonTSF apps.
+
+
+[The TSF must be validated against requirements from the PP-Module for](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=425&id=425)
+Bluetooth, version 1.0. It should be noted that the FTP_ITC_EXT.1 requires that
+all TSF communications be protected using the protocols indicated in that
+requirement, so the protocols required by this component ride "on top of" those
+listed in FTP_ITC_EXT.1.
+
+
+FDP_UPC_EXT.1.2/BLUETOOTH
+
+The TSF shall permit the non-TSF applications to initiate communication via the
+trusted channel.
+
+
+**Evaluation Activities**
+
+
+
+
+# **Appendix B - Selection-based Requirements**
+
+As indicated in the introduction to this PP, the baseline requirements (those that must be performed by the
+TOE or its underlying platform) are contained in the body of this PP. There are additional requirements based
+on selections in the body of the PP: if certain selections are made, then additional requirements below must
+be included.
+
+
+**B.1 Class: Cryptographic Support (FCS)**
+
+
+**FCS_CKM_EXT.7 Cryptographic Key Support (REK)**
+
+
+_**The inclusion of this selection-based component depends upon selection in**_
+_**FCS_CKM_EXT.1.1.**_
+
+
+FCS_CKM_EXT.7.1
+
+A REK shall not be able to be read from or exported from the hardware.
+
+
+**Application Note:** If mutable hardware is selected in FCS_CKM_EXT.1.1,
+FCS_CKM_EXT.7 must be included in the ST. Note that if immutable hardware is
+selected in FCS_CKM_EXT.1.1 it implicitly meets FCS_CKM_EXT.7.
+
+
+The lack of a public/documented API for importing or exporting, when a
+private/undocumented API exists, is not sufficient to meet this requirement.
+
+
+**Evaluation Activities**
+
+
+
+
+
+**B.2 Class: User Data Protection (FDP)**
+
+
+**FDP_ACF_EXT.2 Access Control for System Resources**
+
+
+_**The inclusion of this selection-based component depends upon selection in**_
+_**FDP_ACF_EXT.1.2.**_
+
+
+FDP_ACF_EXT.2.1
+
+The TSF shall provide a separate [ **selection** : _address book_, _calendar_, _keystore_,
+_account credential database, [_ _**assignment**_ _: list of additional resources]_ ] for
+each application group and only allow applications within that process group to
+access the resource. Exceptions may only be explicitly authorized for such
+sharing by [ **selection** : _the user_, _the administrator_, _no one_ ].
+
+
+**Application Note:** If groups of applications is selected in FDP_ACF_EXT.1.2,
+FDP_ACF_EXT.2 must be included in the ST.
+
+
+**Evaluation Activities**
+
+
+_FDP_ACF_EXT.2_
+_**TSS**_
+_There are no TSS evaluation activities for this component._
+
+
+_**Guidance**_
+_There are no guidance evaluation activities for this component._
+
+
+_**Tests**_
+_For each selected resource, the evaluator shall cause data to be placed into the Enterprise_
+
+
+_groupโs instance of that shared resource. The evaluator shall install an application into the_
+_Personal group that attempts to access the shared resource information and verify that it cannot_
+_access the information._
+
+
+**B.3 Class: Protection of the TSF (FPT)**
+
+
+**FPT_TST_EXT.3 TSF Integrity Testing**
+
+
+_**The inclusion of this selection-based component depends upon selection in**_
+_**FIA_X509_EXT.2.1.**_
+
+
+FPT_TST_EXT.3.1
+
+The TSF shall not execute code if the code signing certificate is deemed invalid.
+
+
+**Application Note:** Certificates may optionally be used for code signing for
+integrity verification (FPT_TST_EXT.2.1/PREKERNEL). If code signing for
+integrity verification is selected in FIA_X509_EXT.2.1, FPT_TST_EXT.3 must be
+included in the ST.
+
+
+Validity is determined by the certificate path, the expiration date, and the
+revocation status in accordance with RFC 5280.
+
+
+**Evaluation Activities**
+
+
+
+
+
+**FPT_TUD_EXT.4 Trusted Update Verification**
+
+
+_**The inclusion of this selection-based component depends upon selection in**_
+_**FIA_X509_EXT.2.1.**_
+
+
+FPT_TUD_EXT.4.1
+
+The TSF shall not install code if the code signing certificate is deemed invalid.
+
+
+**Application Note:** Certificates may optionally be used for code signing of
+system software updates (FPT_TUD_EXT.2.3) and of mobile applications
+(FPT_TUD_EXT.5.1). This element must be included in the ST if certificates are
+used for either update element. If either code signing for system software
+updates or code signing for mobile applications is selected in FIA_X509_EXT.2.1,
+FPT_TUD_EXT.4 must be included in the ST.
+
+
+Validity is determined by the certificate path, the expiration date, and the
+revocation status in accordance with RFC 5280.
+
+
+**Evaluation Activities**
+
+
+
+
+
+
+# **Appendix C - Extended Component Definitions**
+
+This appendix contains the definitions for all extended requirements specified in the PP.
+
+
+**C.1 Extended Components Table**
+
+
+All extended components specified in the PP are listed in this table:
+
+
+**Table 10: Extended Component Definitions**
+
+**Functional Class** **Functional Components**
+
+
+Class: Cryptographic Support (FCS) FCS_CKM_EXT Cryptographic Key Management
+FCS_HTTPS_EXT HTTPS Protocol
+FCS_IV_EXT Initialization Vector Generation
+FCS_RBG_EXT Random Bit Generation
+FCS_SRV_EXT Cryptographic Algorithm Services
+FCS_STG_EXT Cryptographic Key Storage
+
+
+Class: Identification and Authentication (FIA) FIA_AFL_EXT Authentication Failures
+FIA_PMG_EXT Password Management
+FIA_TRT_EXT Authentication Throttling
+FIA_UAU_EXT User Authentication
+FIA_X509_EXT X.509 Certificates
+
+
+Class: Protection of the TSF (FPT) FPT_AEX_EXT Anti-Exploitation Capabilities
+FPT_BBD_EXT Baseband Processing
+FPT_BLT_EXT Limitation of Bluetooth Profile Support
+FPT_JTA_EXT JTAG Disablement
+FPT_KST_EXT Key Storage
+FPT_NOT_EXT Self-Test Notification
+FPT_TST_EXT TSF Self Test
+FPT_TUD_EXT TSF Updates
+
+
+Class: Security Management (FMT) FMT_MOF_EXT Management of Functions in TSF
+FMT_SMF_EXT Specification of Management Functions
+
+
+Class: TOE Access (FTA) FTA_SSL_EXT Session Locking and Termination
+
+
+Class: Trusted Path/Channels (FTP) FTP_ITC_EXT Inter-TSF Trusted Channel
+
+
+Class: User Data Protection (FDP) FDP_ACF_EXT Access Control Functions
+FDP_BCK_EXT Application Backup
+FDP_BLT_EXT Limitation of Bluetooth Device Access
+FDP_DAR_EXT Data-at-Rest Encryption
+FDP_IFC_EXT Subset Information Flow Control
+FDP_STG_EXT User Data Storage
+FDP_UPC_EXT Inter-TSF User Data Transfer Protection
+
+
+**C.2 Extended Component Definitions**
+
+
+**C.2.1 Class: Cryptographic Support (FCS)**
+This PP defines the following extended components as part of the FCS class originally defined by CC Part 2:
+
+
+**C.2.1.1 FCS_CKM_EXT Cryptographic Key Management**
+
+
+**Family Behavior**
+
+
+This family defines requirements for management of cryptographic keys that are not addressed by
+FCS_CKM in CC Part 2.
+
+
+**Component Leveling**
+
+
+
+
+
+
+|FCS_CKM_EXT|1|
+|---|---|
+|FCS_CKM_EXT|2|
+|FCS_CKM_EXT|3|
+|FCS_CKM_EXT|4|
+|FCS_CKM_EXT|5|
+|FCS_CKM_EXT|6|
+|FCS_CKM_EXT|7|
+
+
+
+FCS_CKM_EXT.1, Cryptographic Key Support, requires the TSF to implement a Root Encryption Key (REK).
+
+
+FCS_CKM_EXT.2, Cryptographic Key Random Generation, requires the TSF to specify the mechanism it
+uses to generate Data Encryption Keys (DEKs).
+
+
+FCS_CKM_EXT.3, Cryptographic Key Generation, requires the TSF to generate and manage the strength of
+Key Encryption Keys (KEKs).
+
+
+FCS_CKM_EXT.4, Key Destruction, requires the TSF to be able to follow specified rules to destroy plaintext
+keying material and cryptographic keys when no longer needed.
+
+
+FCS_CKM_EXT.5, TSF Wipe, requires the TSF to implement a cryptographic or other mechanism to make
+TSF data unreadable.
+
+
+FCS_CKM_EXT.6, Salt Generation, requires the TSF to generate salts in a specified manner.
+
+
+FCS_CKM_EXT.7, Cryptographic Key Support (REK), requires the TSF to prevent the reading or exporting
+of REKs.
+
+
+**Management: FCS_CKM_EXT.1**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FCS_CKM_EXT.1**
+
+
+The following actions should be auditable if FAU_GEN Security audit data generation is included in the
+PP/ST:
+
+
+Generation of a REK.
+
+
+**FCS_CKM_EXT.1 Cryptographic Key Support**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FCS_RBG_EXT.1 Random Bit Generation
+
+
+**FCS_CKM_EXT.1.1**
+
+
+The TSF shall support [ **assignment** : _description of REKs_ ]
+
+
+**FCS_CKM_EXT.1.2**
+
+
+Each REK shall be hardware-isolated from the OS on the TSF in runtime.
+
+
+**FCS_CKM_EXT.1.3**
+
+
+Each REK shall be generated by an RBG in accordance with FCS_RBG_EXT.1.
+
+
+**Management: FCS_CKM_EXT.2**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FCS_CKM_EXT.2**
+
+
+There are no auditable events foreseen.
+
+
+**FCS_CKM_EXT.2 Cryptographic Key Random Generation**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FCS_RBG_EXT.1 Random Bit Generation
+
+
+**FCS_CKM_EXT.2.1**
+
+
+All DEKs shall be [ **assignment** : _generation mechanism_ ] with entropy corresponding to the security
+strength of AES key sizes of [ **assignment** : _number greater than 128_ ] bits.
+
+
+**Management: FCS_CKM_EXT.3**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FCS_CKM_EXT.3**
+
+
+There are no auditable events foreseen.
+
+
+**FCS_CKM_EXT.3 Cryptographic Key Generation**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FCS_CKM.1 Cryptographic Key Generation
+FCS_COP.1 Cryptographic Operation
+FCS_RBG_EXT.1 Random Bit Generation
+
+
+**FCS_CKM_EXT.3.1**
+
+
+The TSF shall use [ **assignment** : _description of KEKs_ ].
+
+
+**FCS_CKM_EXT.3.2**
+
+
+The TSF shall generate all KEKs using one of the following methods:
+
+
+Derive the KEK from a Password Authentication Factor according to FCS_COP.1.1 and
+
+[ **selection** :
+
+_Generate the KEK using an RBG that meets this profile (as specified in FCS_RBG_EXT.1)_
+_Generate the KEK using a key generation scheme that meets this profile (as specified in FCS_CKM.1)_
+_Combine the KEK from other KEKs in a way that preserves the effective entropy of each factor by_
+
+_[_ _**selection**_ _: using an XOR operation, concatenating the keys and using a KDF (as described in SP_
+_800-108), concatenating the keys and using a KDF (as described in SP 800-56C), encrypting one key_
+_with another ]_
+
+].
+
+
+**Management: FCS_CKM_EXT.4**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FCS_CKM_EXT.4**
+
+
+There are no auditable events foreseen.
+
+
+**FCS_CKM_EXT.4 Key Destruction**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FCS_RBG_EXT.1 Random Bit Generation
+
+
+**FCS_CKM_EXT.4.1**
+
+
+The TSF shall destroy cryptographic keys in accordance with the specified cryptographic key destruction
+methods:
+
+By clearing the KEK encrypting the target key
+In accordance with the following rules
+
+For volatile memory, the destruction shall be executed by a single direct overwrite [ **selection** :
+_consisting of a pseudorandom pattern using the TSFโs RBG_, _consisting of zeros_ ].
+For non-volatile EEPROM, the destruction shall be executed by a single direct overwrite
+consisting of a pseudo random pattern using the TSFโs RBG (as specified in FCS_RBG_EXT.1),
+followed by a read-verify.
+For non-volatile flash memory, that is not wear-leveled, the destruction shall be executed
+
+[ **selection** : _by a single direct overwrite consisting of zeros followed by a read-verify_, _by a block_
+_erase that erases the reference to memory that stores data as well as the data itself_ ].
+For non-volatile flash memory, that is wear-leveled, the destruction shall be executed
+
+[ **selection** : _by a single direct overwrite consisting of zeros_, _by a block erase_ ].
+For non-volatile memory other than EEPROM and flash, the destruction shall be executed by a
+single direct overwrite with a random pattern that is changed before each write.
+
+
+**FCS_CKM_EXT.4.2**
+
+
+The TSF shall destroy all plaintext keying material and critical security parameters when no longer
+needed.
+
+
+**Management: FCS_CKM_EXT.5**
+
+
+The following actions could be considered for the management functions in FMT:
+
+
+TSF wipe of protected data.
+TSF wipe of enterprise data.
+
+
+**Audit: FCS_CKM_EXT.5**
+
+
+The following actions should be auditable if FAU_GEN Security audit data generation is included in the
+PP/ST:
+
+
+Failure of the wipe.
+
+
+**FCS_CKM_EXT.5 TSF Wipe**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FCS_RBG_EXT.1 Random Bit Generation
+
+
+**FCS_CKM_EXT.5.1**
+
+
+The TSF shall wipe all protected data by [ **selection** :
+
+_Cryptographically erasing the encrypted DEKs or the KEKs in non-volatile memory by following the_
+_requirements in FCS_CKM_EXT.4.1_
+_Overwriting all PD according to the following rules:_
+
+_For EEPROM, the destruction shall be executed by a single direct overwrite consisting of a_
+_pseudo random pattern using the TSFโs RBG (as specified in FCS_RBG_EXT.1, followed by a_
+_read-verify._
+_For flash memory, that is not wear-leveled, the destruction shall be executed [_ _**selection**_ _: by a_
+_single direct overwrite consisting of zeros followed by a read-verify, by a block erase that erases_
+_the reference to memory that stores data as well as the data itself ]._
+
+
+_For flash memory, that is wear-leveled, the destruction shall be executed [_ _**selection**_ _: by a single_
+_direct overwrite consisting of zeros, by a block erase ]._
+_For non-volatile memory other than EEPROM and flash, the destruction shall be executed by a_
+_single direct overwrite with a random pattern that is changed before each write._
+
+].
+
+
+**FCS_CKM_EXT.5.2**
+
+
+The TSF shall perform a power cycle on conclusion of the wipe procedure.
+
+
+**Management: FCS_CKM_EXT.6**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FCS_CKM_EXT.6**
+
+
+There are no auditable events foreseen.
+
+
+**FCS_CKM_EXT.6 Salt Generation**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FCS_RBG_EXT.1 Random Bit Generation
+
+
+**FCS_CKM_EXT.6.1**
+
+
+The TSF shall generate all salts using an RBG that meets FCS_RBG_EXT.1.
+
+
+**Management: FCS_CKM_EXT.7**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FCS_CKM_EXT.7**
+
+
+There are no auditable events foreseen.
+
+
+**FCS_CKM_EXT.7 Cryptographic Key Support (REK)**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FCS_CKM_EXT.1 Cryptographic Key Support
+
+
+**FCS_CKM_EXT.7.1**
+
+
+A REK shall not be able to be read from or exported from the hardware.
+
+
+**C.2.1.2 FCS_HTTPS_EXT HTTPS Protocol**
+
+
+**Family Behavior**
+
+
+This family defines requirements for implementation of the HTTPS protocol.
+
+
+**Component Leveling**
+
+|FCS_HTTPS_EXT|Col2|1|
+|---|---|---|
+|FCS_HTTPS_EXT|||
+
+
+
+FCS_HTTPS_EXT.1, HTTPS Protocol, requires the TSF to implement the HTTPS protocol in accordance with
+the specified standard, using TLS, and notifying the application if invalid.
+
+
+**Management: FCS_HTTPS_EXT.1**
+
+
+The following actions could be considered for the management functions in FMT:
+
+
+Configuring whether to allow or disallow establishment of a trusted channel if the peer or server
+certificate is deemed invalid.
+
+
+**Audit: FCS_HTTPS_EXT.1**
+
+
+The following actions should be auditable if FAU_GEN Security audit data generation is included in the
+PP/ST:
+
+
+Failure of the certificate validity check.
+
+
+**FCS_HTTPS_EXT.1 HTTPS Protocol**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FIA_X509_EXT.1 X.509 Validation of Certificates
+FMT_SMF.1 Specification of Management Functions
+
+
+**FCS_HTTPS_EXT.1.1**
+
+
+The TSF shall implement the HTTPS protocol that complies with RFC 2818.
+
+
+**FCS_HTTPS_EXT.1.2**
+
+
+The TSF shall implement HTTPS using TLS as defined in [ **assignment** : _specification that defines TLS_
+_implementation requirements_ ].
+
+
+**FCS_HTTPS_EXT.1.3**
+
+
+The TSF shall notify the application and [ **assignment** : _a response_ ] if the peer certificate is deemed
+invalid.
+
+
+**C.2.1.3 FCS_IV_EXT Initialization Vector Generation**
+
+
+**Family Behavior**
+
+
+This family defines requirements for initialization vector generation in support of key generation.
+
+
+**Component Leveling**
+
+|FCS_IV_EXT|Col2|1|
+|---|---|---|
+|FCS_IV_EXT|||
+
+
+
+FCS_IV_EXT.1, Initialization Vector Generation, requires the TSF to generate IVs in accordance with a set
+of approved modes.
+
+
+**Management: FCS_IV_EXT.1**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FCS_IV_EXT.1**
+
+
+There are no auditable events foreseen.
+
+
+**FCS_IV_EXT.1 Initialization Vector Generation**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: No dependencies.
+
+
+**FCS_IV_EXT.1.1**
+
+
+The TSF shall generate IVs in accordance with [ **assignment** : _standard or specification for IV generation_ ].
+
+
+**C.2.1.4 FCS_RBG_EXT Random Bit Generation**
+
+
+**Family Behavior**
+
+
+This family defines requirements for the generation of random bits.
+
+
+**Component Leveling**
+
+
+
+
+
+
+|FCS_RBG_EXT|1|
+|---|---|
+|FCS_RBG_EXT|2|
+|FCS_RBG_EXT|3|
+
+
+
+FCS_RBG_EXT.1, Random Bit Generation, requires the TSF to generate random data with a certain amount
+of entropy and in accordance with applicable standards.
+
+
+FCS_RBG_EXT.2, Random Bit Generator State Preservation, requires the TSF to save and restore the state
+of the RBG when powering off and starting up.
+
+
+FCS_RBG_EXT.3, Support for Personalization String, requires the TSF to support a personalization string as
+a DRBG input parameter.
+
+
+**Management: FCS_RBG_EXT.1**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FCS_RBG_EXT.1**
+
+
+The following actions should be auditable if FAU_GEN Security audit data generation is included in the
+PP/ST:
+
+
+Failure of the randomization process.
+
+
+**FCS_RBG_EXT.1 Random Bit Generation**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: No dependencies.
+
+
+**FCS_RBG_EXT.1.1**
+
+
+The TSF shall perform all deterministic random bit generation services in accordance with NIST Special
+Publication 800-90A using [ **assignment** : _list of DRBG algorithms_ ].
+
+
+**FCS_RBG_EXT.1.2**
+
+
+The deterministic RBG shall be seeded by an entropy source that accumulates entropy from [ **assignment** :
+_list of sources of random_ ] with a minimum of [ **assignment** : _number of bits_ ] of entropy at least equal to
+the greatest security strength (according to NIST SP 800-57) of the keys and hashes that it will generate.
+
+
+**FCS_RBG_EXT.1.3**
+
+
+The TSF shall be capable of providing output of the RBG to applications running on the TSF that request
+random bits.
+
+
+**Management: FCS_RBG_EXT.2**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FCS_RBG_EXT.2**
+
+
+There are no auditable events foreseen.
+
+
+**FCS_RBG_EXT.2 Random Bit Generator State Preservation**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FCS_RBG_EXT.1 Random Bit Generation
+
+
+**FCS_RBG_EXT.2.1**
+
+
+The TSF shall save the state of the deterministic RBG at power-off, and shall use this state as input to the
+deterministic RBG at startup.
+
+
+**Management: FCS_RBG_EXT.3**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FCS_RBG_EXT.3**
+
+
+There are no auditable events foreseen.
+
+
+**FCS_RBG_EXT.3 Support for Personalization String**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FCS_RBG_EXT.1 Random Bit Generation
+
+
+**FCS_RBG_EXT.3.1**
+
+
+The TSF shall allow applications to add data to the deterministic RBG using the Personalization String as
+defined in SP 800-90A.
+
+
+**C.2.1.5 FCS_SRV_EXT Cryptographic Algorithm Services**
+
+
+**Family Behavior**
+
+
+This family defines requirements for the ability of the TOE to make its cryptographic operations available to
+non-TSF components.
+
+
+**Component Leveling**
+
+
+
+
+
+
+|FCS_SRV_EXT|Col2|1|
+|---|---|---|
+|FCS_SRV_EXT|FCS_SRV_EXT|2|
+|FCS_SRV_EXT|||
+
+
+
+FCS_SRV_EXT.1, Cryptographic Algorithm Services, requires the TSF to have externally-accessible
+cryptographic services for making algorithm functions available to applications.
+
+
+FCS_SRV_EXT.2, Cryptographic Key Storage Services, requires the TSF to support its stored keys being
+usable by external applications through cryptographic algorithm services.
+
+
+**Management: FCS_SRV_EXT.1**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FCS_SRV_EXT.1**
+
+
+There are no auditable events foreseen.
+
+
+**FCS_SRV_EXT.1 Cryptographic Algorithm Services**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FCS_CKM.1 Cryptographic Key Generation
+FCS_COP.1 Cryptographic Operation
+
+
+**FCS_SRV_EXT.1.1**
+
+
+The TSF shall provide a mechanism for applications to request the TSF to perform the following
+cryptographic operations: [ **assignment** : _cryptographic operations defined by the TSF in FCS_CKM.1 or_
+_FCS_COP.1_ ]
+
+
+**Management: FCS_SRV_EXT.2**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FCS_SRV_EXT.2**
+
+
+There are no auditable events foreseen.
+
+
+**FCS_SRV_EXT.2 Cryptographic Key Storage Services**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FCS_COP.1 Cryptographic Operation
+
+
+**FCS_SRV_EXT.2.1**
+
+
+The TSF shall provide a mechanism for applications to request the TSF to perform the following
+cryptographic operations: [ **assignment** : _cryptographic operations defined by the TSF in FCS_COP.1_ ] by
+keys stored in the secure key storage.
+
+
+**C.2.1.6 FCS_STG_EXT Cryptographic Key Storage**
+
+
+**Family Behavior**
+
+
+This family defines requirements for the implementation of secure key storage with access control,
+confidentiality, and integrity protections.
+
+
+**Component Leveling**
+
+
+
+
+
+
+|FCS_STG_EXT|1|
+|---|---|
+|FCS_STG_EXT|2|
+|FCS_STG_EXT|3|
+
+
+
+FCS_STG_EXT.1, Cryptographic Key Storage, requires the TSF to implement a secure key storage and
+defines the access restrictions to be enforced on this.
+
+
+FCS_STG_EXT.2, Encrypted Cryptographic Key Storage, requires the TSF to implement confidentiality
+measures to protect the key storage.
+
+
+FCS_STG_EXT.3, Integrity of Encrypted Key Storage, requires the TSF to implement integrity measures to
+protect the key storage.
+
+
+**Management: FCS_STG_EXT.1**
+
+
+The following actions could be considered for the management functions in FMT:
+
+
+Importing keys or secrets into the secure key storage.
+Destroying imported keys or secrets in the secure key storage.
+Approving exceptions for shared use of keys or secrets by multiple applications.
+Approving exceptions for destruction of keys or secrets by applications that did not import the key or
+secret
+
+
+**Audit: FCS_STG_EXT.1**
+
+
+The following actions should be auditable if FAU_GEN Security audit data generation is included in the
+PP/ST:
+
+
+Import or destruction of key.
+Exceptions to use and destruction rules.
+
+
+**FCS_STG_EXT.1 Cryptographic Key Storage**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: [FCS_CKM.1 Cryptographic Key Generation, or
+FDP_ITC.1 Import of User Data without Security Attributes, or
+FDP_ITC.2 Import of User Data with Security Attributes]
+FMT_SMR.1 Security Roles
+
+
+**FCS_STG_EXT.1.1**
+
+
+The TSF shall provide [ **assignment** : _storage medium_ ] secure key storage for asymmetric private keys and
+
+[ **assignment** : _list of secrets_ ] .
+
+
+**FCS_STG_EXT.1.2**
+
+
+The TSF shall be capable of importing keys or secrets into the secure key storage upon request of
+
+[ **assignment** : _list of users_ ] and [ **assignment** : _list of other subjects_ ].
+
+
+**FCS_STG_EXT.1.3**
+
+
+The TSF shall be capable of destroying keys or secrets in the secure key storage upon request of
+
+[ **selection** : _the user_, _the administrator_ ].
+
+
+**FCS_STG_EXT.1.4**
+
+
+The TSF shall have the capability to allow only the application that imported the key or secret the use of
+the key or secret. Exceptions may only be explicitly authorized by [ **selection** : _the user_, _the administrator_,
+_a common application developer_ ].
+
+
+**FCS_STG_EXT.1.5**
+
+
+The TSF shall allow only the application that imported the key or secret to request that the key or secret
+be destroyed. Exceptions may only be explicitly authorized by [ **assignment** : _list of subjects_ ].
+
+
+**Management: FCS_STG_EXT.2**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FCS_STG_EXT.2**
+
+
+There are no auditable events foreseen.
+
+
+**FCS_STG_EXT.2 Encrypted Cryptographic Key Storage**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FCS_COP.1 Cryptographic Operation
+FCS_STG_EXT.1 Cryptographic Key Storage
+
+
+**FCS_STG_EXT.2.1**
+
+
+The TSF shall encrypt all DEKs, KEKs, [ **assignment** : _any long-term trusted channel key material_ ] and
+
+[ **assignment** : _other secrets_ ] by KEKs that are [ **assignment** : _protection mechanism_ ].
+
+
+**FCS_STG_EXT.2.2**
+
+
+DEKs, KEKs, [ **assignment** : _any long-term trusted channel key material_ ] and [ **selection** : _all software-_
+_based key storage_, _no other keys_ ] shall be encrypted using one of the following methods: [ **selection** :
+
+_using a SP800-56B key establishment scheme_
+_using AES in the [_ _**selection**_ _: Key Wrap (KW) mode, Key Wrap with Padding (KWP) mode, GCM,_
+_CCM, CBC mode ]_
+
+].
+
+
+**Management: FCS_STG_EXT.3**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FCS_STG_EXT.3**
+
+
+The following actions should be auditable if FAU_GEN Security audit data generation is included in the
+PP/ST:
+
+
+Failure to verify the integrity of stored key.
+
+
+**FCS_STG_EXT.3 Integrity of Encrypted Key Storage**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FCS_COP.1 Cryptographic Operation
+FCS_STG_EXT.2 Encrypted Cryptographic Key Storage
+
+
+**FCS_STG_EXT.3.1**
+
+
+The TSF shall protect the integrity of any encrypted DEKs and KEKs and [ **selection** : _long-term trusted_
+_channel key material_, _all software-based key storage_, _no other keys_ ] by [ **selection** :
+
+_[_ _**selection**_ _: GCM, CCM, Key Wrap, Key Wrap with Padding ] cipher mode for encryption according to_
+_FCS_STG_EXT.2_
+_a hash (FCS_COP.1) of the stored key that is encrypted by a key protected by FCS_STG_EXT.2_
+_a keyed hash (FCS_COP.1) using a key protected by a key protected by FCS_STG_EXT.2_
+_a digital signature of the stored key using an asymmetric key protected according to FCS_STG_EXT.2_
+_an immediate application of the key for decrypting the protected data followed by a successful_
+_verification of the decrypted data with previously known information_
+
+].
+
+
+**FCS_STG_EXT.3.2**
+
+
+The TSF shall verify the integrity of the [ **selection** : _hash_, _digital signature_, _MAC_ ] of the stored key prior
+to use of the key.
+
+
+**C.2.2 Class: Identification and Authentication (FIA)**
+This PP defines the following extended components as part of the FIA class originally defined by CC Part 2:
+
+
+**C.2.2.1 FIA_AFL_EXT Authentication Failures**
+
+
+**Family Behavior**
+
+
+This family defines requirements for authentication failure handling that are not addressed by the FIA_AFL
+family in CC Part 2.
+
+
+**Component Leveling**
+
+|FIA_AFL_EXT|Col2|1|
+|---|---|---|
+|FIA_AFL_EXT|||
+
+
+
+FIA_AFL_EXT.1, Authentication Failure Handling, requires the TSF be able to manage unsuccessful
+authentication attempts and limit the number of attempts for each method.
+
+
+**Management: FIA_AFL_EXT.1**
+
+
+The following actions could be considered for the management functions in FMT:
+
+
+Configuration of authentication failure limit.
+
+
+**Audit: FIA_AFL_EXT.1**
+
+
+The following actions should be auditable if FAU_GEN Security audit data generation is included in the
+PP/ST:
+
+
+Exceeding configured authentication failure limit.
+
+
+**FIA_AFL_EXT.1 Authentication Failure Handling**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FCS_CKM_EXT.5 TSF Wipe
+FIA_UAU.1 Timing of Authentication
+
+
+**FIA_AFL_EXT.1.1**
+
+
+The TSF shall consider password and [ **assignment** : _list of acceptable authentication mechanisms_ ] as
+critical authentication mechanisms.
+
+
+**FIA_AFL_EXT.1.2**
+
+
+The TSF shall detect when a configurable positive integer within [ **assignment** : _range of acceptable_
+_values for each authentication mechanism_ ] of [ **selection** : _unique_, _non-unique_ ] unsuccessful
+authentication attempts occur related to last successful authentication for each authentication
+mechanism.
+
+
+**FIA_AFL_EXT.1.3**
+
+
+The TSF shall maintain the number of unsuccessful authentication attempts that have occurred upon
+power off.
+
+
+**FIA_AFL_EXT.1.4**
+
+
+When the defined number of unsuccessful authentication attempts has exceeded the maximum allowed for
+a given authentication mechanism, all future authentication attempts will be limited to other available
+authentication mechanisms, unless the given mechanism is designated as a critical authentication
+mechanism.
+
+
+**FIA_AFL_EXT.1.5**
+
+
+When the defined number of unsuccessful authentication attempts for the last available authentication
+mechanism or single critical authentication mechanism has been surpassed, the TSF shall perform a wipe
+of all protected data.
+
+
+**FIA_AFL_EXT.1.6**
+
+
+The TSF shall increment the number of unsuccessful authentication attempts prior to notifying the user
+that the authentication was unsuccessful.
+
+
+**C.2.2.2 FIA_PMG_EXT Password Management**
+
+
+**Family Behavior**
+
+
+This family defines requirements for the composition of password credentials.
+
+
+**Component Leveling**
+
+
+|FIA_PMG_EXT|Col2|1|
+|---|---|---|
+|FIA_PMG_EXT|||
+
+
+FIA_PMG_EXT.1, Password Management, requires the TSF to enforce character length and composition
+requirements for password credentials.
+
+
+**Management: FIA_PMG_EXT.1**
+
+
+The following actions could be considered for the management functions in FMT:
+
+
+Configuring password policy.
+
+
+**Audit: FIA_PMG_EXT.1**
+
+
+There are no auditable events foreseen.
+
+
+**FIA_PMG_EXT.1 Password Management**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FIA_UAU.1 Timing of Authentication
+
+
+**FIA_PMG_EXT.1.1**
+
+
+The TSF shall support the following for the Password Authentication Factor:
+
+
+1. Passwords shall be able to be composed of any combination of [ **selection** : _upper and lower case_
+
+_letters_, _[_ _**assignment**_ _: a character set of at least 52 characters]_ ], numbers, and special characters:
+
+[ **selection** : _"!"_, _"@"_, _"#"_, _"$"_, _"%"_, _"^"_, _"&"_, _"*"_, _"("_, _")"_, _[_ _**assignment**_ _: other characters]_ ];
+2. Password length up to [ **assignment** : _an integer greater than or equal to 14_ ] characters shall be
+
+supported.
+
+
+**C.2.2.3 FIA_TRT_EXT Authentication Throttling**
+
+
+**Family Behavior**
+
+
+This family defines requirements for prevention of brute-force authentication attempts.
+
+
+**Component Leveling**
+
+|FIA_TRT_EXT|Col2|1|
+|---|---|---|
+|FIA_TRT_EXT|||
+
+
+
+FIA_TRT_EXT.1, Authentication Throttling, requires the TSF to limit authentication attempts by number of
+attempts in a set amount of time.
+
+
+**Management: FIA_TRT_EXT.1**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FIA_TRT_EXT.1**
+
+
+There are no auditable events foreseen.
+
+
+**FIA_TRT_EXT.1 Authentication Throttling**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FIA_UAU.5 Multiple Authentication Mechanisms
+
+
+**FIA_TRT_EXT.1.1**
+
+
+The TSF shall limit automated user authentication attempts by [ **selection** : _preventing authentication via_
+_an external port_, _enforcing a delay between incorrect authentication attempts_ ] for all authentication
+mechanisms selected in FIA_UAU.5.1. The minimum delay shall be such that no more than 10 attempts
+can be attempted per 500 milliseconds.
+
+
+**C.2.2.4 FIA_UAU_EXT User Authentication**
+
+
+**Family Behavior**
+
+
+This family defines requirements for user authentication that are not addressed by FIA_UAU in CC Part 2.
+
+
+**Component Leveling**
+
+
+
+
+
+
+|FIA_UAU_EXT|1|
+|---|---|
+|FIA_UAU_EXT|2|
+|FIA_UAU_EXT|4|
+
+
+
+FIA_UAU_EXT.1, Authentication for Cryptographic Operation, requires the TSF enforce data-at-rest
+protection until successful authentication has occurred.
+
+
+FIA_UAU_EXT.2, Timing of Authentication, requires the TSF to prevent a subjectโs use of TOE until the user
+is authenticated.
+
+
+FIA_UAU_EXT.4, Secondary User Authentication, requires the TSF to enforce the use of a secondary
+authentication factor to access certain user data.
+
+
+**Management: FIA_UAU_EXT.1**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FIA_UAU_EXT.1**
+
+
+There are no auditable events foreseen.
+
+
+**FIA_UAU_EXT.1 Authentication for Cryptographic Operation**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FDP_DAR_EXT.1 Protected Data Encryption
+FDP_DAR_EXT.2 Sensitive Data Encryption
+
+
+**FIA_UAU_EXT.1.1**
+
+
+The TSF shall require the user to present the Password Authentication Factor prior to decryption of
+protected data and encrypted DEKs, KEKs and [ **selection** : _long-term trusted channel key material_, _all_
+_software-based key storage_, _no other keys_ ] at startup.
+
+
+**Management: FIA_UAU_EXT.2**
+
+
+The following actions could be considered for the management functions in FMT:
+
+
+Enabling/disabling display TSF notifications while in the locked state.
+Enabling/disabling bypass of local user authentication.
+
+
+**Audit: FIA_UAU_EXT.2**
+
+
+The following actions should be auditable if FAU_GEN Security audit data generation is included in the
+PP/ST:
+
+
+Action performed before authentication.
+
+
+**FIA_UAU_EXT.2 Timing of Authentication**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: No dependencies.
+
+
+**FIA_UAU_EXT.2.1**
+
+
+The TSF shall allow [ **selection** : _[_ _**assignment**_ _: list of actions]_, _no actions_ ] on behalf of the user to be
+performed before the user is authenticated.
+
+
+**FIA_UAU_EXT.2.2**
+
+
+The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated
+actions on behalf of that user.
+
+
+**Management: FIA_UAU_EXT.4**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FIA_UAU_EXT.4**
+
+
+There are no auditable events foreseen.
+
+
+**FIA_UAU_EXT.4 Secondary User Authentication**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FDP_ACF_EXT.2 Access Control for System Resources
+FIA_UAU.5 Multiple Authentication Mechanisms
+
+
+**FIA_UAU_EXT.4.1**
+
+
+The TSF shall provide a secondary authentication mechanism for accessing Enterprise applications and
+resources. The secondary authentication mechanism shall control access to the Enterprise application and
+shared resources and shall be incorporated into the encryption of protected and sensitive data belonging
+to Enterprise applications and shared resources.
+
+
+**FIA_UAU_EXT.4.2**
+
+
+The TSF shall require the user to present the secondary authentication factor prior to decryption of
+Enterprise application data and Enterprise shared resource data.
+
+
+**C.2.2.5 FIA_X509_EXT X.509 Certificates**
+
+
+**Family Behavior**
+
+
+This family defines requirements for the management and use of X.509 certificates.
+
+
+**Component Leveling**
+
+
+
+
+|FIA_X509_EXT|1|
+|---|---|
+|FIA_X509_EXT|2|
+|FIA_X509_EXT|3|
+|FIA_X509_EXT|4|
+|FIA_X509_EXT|5|
+
+
+
+FIA_X509_EXT.1, X.509 Validation of Certificates, specifies the rules the TSF must follow to determine if a
+particular X.509 certificate is valid.
+
+
+FIA_X509_EXT.2, X.509 Certificate Authentication, defines the TSFโs usage of X.509 certificates and how it
+reacts to certificates with undetermined revocation status.
+
+
+FIA_X509_EXT.3, Request Validation of Certificates, requires the TSF to make a certificate validation
+service available to environmental components.
+
+
+FIA_X509_EXT.4, X509 Certificate Enrollment, requires the TSF to implement Enrollment over Secure
+Transport (EST) as a mechanism to obtain X.509 certificates.
+
+
+FIA_X509_EXT.5, X.509 Certificate Requests, requires the TSF to generate X.509 certificate requests and
+validate the responses.
+
+
+**Management: FIA_X509_EXT.1**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FIA_X509_EXT.1**
+
+
+The following action is be auditable:
+
+
+Failure to validate X.509v3 certificate.
+
+
+**FIA_X509_EXT.1 X.509 Validation of Certificates**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FCS_COP.1 Cryptographic Operation
+
+
+**FIA_X509_EXT.1.1**
+
+
+The TSF shall validate certificates in accordance with the following rules: [ **assignment** : _list of rules_ ].
+
+
+**FIA_X509_EXT.1.2**
+
+
+The TSF shall only treat a certificate as a CA certificate if the basicConstraints extension is present and
+the CA flag is set to TRUE.
+
+
+**Management: FIA_X509_EXT.2**
+
+
+The following actions could be considered for the management functions in FMT:
+
+
+Configuring whether to allow or disallow establishment of a trusted channel if the TSF cannot establish
+a connection to determine the validity of a certificate.
+
+
+**Audit: FIA_X509_EXT.2**
+
+
+The following actions should be auditable if FAU_GEN Security audit data generation is included in the
+PP/ST:
+
+
+Failure to establish connection to determine revocation status.
+
+
+**FIA_X509_EXT.2 X.509 Certificate Authentication**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FIA_X509_EXT.1 X.509 Validation of Certificates
+FTP_ITC_EXT.1 Trusted Channel Communication
+
+
+**FIA_X509_EXT.2.1**
+
+
+The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for
+
+[ **assignment** : _trusted channel protocol_ ] and [ **selection** : _code signing for system software updates_, _code_
+_signing for mobile applications_, _code signing for integrity verification_, _[_ _**assignment**_ _: other uses]_, _no_
+_additional uses_ ].
+
+
+**FIA_X509_EXT.2.2**
+
+
+When the TSF cannot establish a connection to determine the revocation status of a certificate, the TSF
+shall [ **assignment** : _list of acceptable actions_ ].
+
+
+**Management: FIA_X509_EXT.3**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FIA_X509_EXT.3**
+
+
+There are no auditable events foreseen.
+
+
+**FIA_X509_EXT.3 Request Validation of Certificates**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FIA_X509_EXT.1 X.509 Validation of Certificates
+
+
+**FIA_X509_EXT.3.1**
+
+
+The TSF shall provide a certificate validation service to applications.
+
+
+**FIA_X509_EXT.3.2**
+
+
+The TSF shall respond to the requesting application with the success or failure of the validation.
+
+
+**Management: FIA_X509_EXT.4**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FIA_X509_EXT.4**
+
+
+The following actions should be auditable if FAU_GEN Security audit data generation is included in the
+PP/ST:
+
+
+Generation of Certificate Enrollment Request.
+Success or failure of enrollment.
+Update of EST Trust Anchor Database
+
+
+**FIA_X509_EXT.4 X509 Certificate Enrollment**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FCS_CKM.1 Cryptographic Key Generation
+FIA_X509_EXT.1 X.509 Validation of Certificates
+
+
+**FIA_X509_EXT.4.1**
+
+
+The TSF shall use the Enrollment over Secure Transport (EST) protocol as specified in RFC 7030 to
+request certificate enrollment using the simple enrollment method described in RFC 7030 Section 4.2.
+
+
+**FIA_X509_EXT.4.2**
+
+
+The TSF shall be capable of authenticating EST requests using an existing certificate and corresponding
+private key as specified by RFC 7030 Section 3.3.2.
+
+
+**FIA_X509_EXT.4.3**
+
+
+The TSF shall be capable of authenticating EST requests using HTTP Basic Authentication with a
+username and password as specified by RFC 7030 Section 3.2.3.
+
+
+**FIA_X509_EXT.4.4**
+
+
+The TSF shall perform authentication of the EST server using an Explicit Trust Anchor following the rules
+described in RFC 7030, section 3.6.1.
+
+
+**FIA_X509_EXT.4.5**
+
+
+The TSF shall be capable of requesting server-provided private keys as specified in RFC 7030 Section 4.4.
+
+
+**FIA_X509_EXT.4.6**
+
+
+The TSF shall be capable of updating its EST-specific Trust Anchor Database using the "Root CA Key
+Update" process described in RFC 7030 Section 4.1.3.
+
+
+**FIA_X509_EXT.4.7**
+
+
+The TSF shall generate a Certificate Request Message for EST as specified in RFC 2986 and be able to
+provide the following information in the request: public key and [ **selection** : _device-specific information_,
+_Common Name_, _Organization_, _Organizational Unit_, _Country_ ].
+
+
+**FIA_X509_EXT.4.8**
+
+
+The TSF shall validate the chain of certificates from the Root CA certificate in the Trust Anchor Database
+to the EST Server CA certificate upon receiving a CA Certificates Response.
+
+
+**Management: FIA_X509_EXT.5**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FIA_X509_EXT.5**
+
+
+There are no auditable events foreseen.
+
+
+**FIA_X509_EXT.5 X.509 Certificate Requests**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FCS_CKM.1 Cryptographic Key Generation
+FIA_X509_EXT.1 X.509 Validation of Certificates
+
+
+**FIA_X509_EXT.5.1**
+
+
+The TSF shall generate a Certificate Request Message as specified in RFC 2986 and be able to provide
+the following information in the request: public key and [ **selection** : _device-specific information_, _Common_
+_Name_, _Organization_, _Organizational Unit_, _Country_ ].
+
+
+**FIA_X509_EXT.5.2**
+
+
+The TSF shall validate the chain of certificates from the Root CA upon receiving the CA Certificate
+Response.
+
+
+**C.2.3 Class: Protection of the TSF (FPT)**
+
+This PP defines the following extended components as part of the FPT class originally defined by CC Part 2:
+
+
+**C.2.3.1 FPT_AEX_EXT Anti-Exploitation Capabilities**
+
+
+**Family Behavior**
+
+
+This family defines requirements for protecting against common types of software exploitation techniques.
+
+
+**Component Leveling**
+
+
+
+
+
+
+|FPT_AEX_EXT|1|
+|---|---|
+|FPT_AEX_EXT|2|
+|FPT_AEX_EXT|3|
+|FPT_AEX_EXT|4|
+|FPT_AEX_EXT|5|
+|FPT_AEX_EXT|6|
+|FPT_AEX_EXT|7|
+
+
+
+FPT_AEX_EXT.1, Application Address Space Layout Randomization, requires the TSF to support address
+space layout randomization (ASLR).
+
+
+FPT_AEX_EXT.2, Memory Page Permissions, requires the TSF to enforce access permissions on physical
+memory.
+
+
+FPT_AEX_EXT.3, Stack Overflow Protection, requires the TSF to implement stack overflow protection.
+
+
+FPT_AEX_EXT.4, Domain Isolation, requires the TSF to protect itself from untrusted subjects and enforce
+address space isolation.
+
+
+FPT_AEX_EXT.5, Kernel Address Space Layout Randomization, requires the TSF to provide ASLR to the
+kernel.
+
+
+FPT_AEX_EXT.6, Write or Execute Memory Page Permissions, requires the TSF to prevent physical memory
+from being both writable and executable.
+
+
+FPT_AEX_EXT.7, Heap Overflow Protection, requires the TSF to support heap-based buffer overflow
+protection.
+
+
+**Management: FPT_AEX_EXT.1**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FPT_AEX_EXT.1**
+
+
+There are no auditable events foreseen.
+
+
+**FPT_AEX_EXT.1 Application Address Space Layout Randomization**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FCS_RBG_EXT.1 Random Bit Generation
+
+
+**FPT_AEX_EXT.1.1**
+
+
+The TSF shall provide address space layout randomization ASLR to applications.
+
+
+**FPT_AEX_EXT.1.2**
+
+
+The base address of any user-space memory mapping will consist of at least 8 unpredictable bits.
+
+
+**Management: FPT_AEX_EXT.2**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FPT_AEX_EXT.2**
+
+
+There are no auditable events foreseen.
+
+
+**FPT_AEX_EXT.2 Memory Page Permissions**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: No dependencies.
+
+
+**FPT_AEX_EXT.2.1**
+
+
+The TSF shall be able to enforce read, write, and execute permissions on every page of physical memory.
+
+
+**Management: FPT_AEX_EXT.3**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FPT_AEX_EXT.3**
+
+
+There are no auditable events foreseen.
+
+
+**FPT_AEX_EXT.3 Stack Overflow Protection**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: No dependencies.
+
+
+**FPT_AEX_EXT.3.1**
+
+
+TSF processes that execute in a non-privileged execution domain on the application processor shall
+implement stack-based buffer overflow protection.
+
+
+**Management: FPT_AEX_EXT.4**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FPT_AEX_EXT.4**
+
+
+There are no auditable events foreseen.
+
+
+**FPT_AEX_EXT.4 Domain Isolation**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: No dependencies.
+
+
+**FPT_AEX_EXT.4.1**
+
+
+The TSF shall protect itself from modification by untrusted subjects.
+
+
+**FPT_AEX_EXT.4.2**
+
+
+The TSF shall enforce isolation of address space between applications.
+
+
+**Management: FPT_AEX_EXT.5**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FPT_AEX_EXT.5**
+
+
+There are no auditable events foreseen.
+
+
+**FPT_AEX_EXT.5 Kernel Address Space Layout Randomization**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: No dependencies.
+
+
+**FPT_AEX_EXT.5.1**
+
+
+The TSF shall provide address space layout randomization (ASLR) to the kernel.
+
+
+**FPT_AEX_EXT.5.2**
+
+
+The base address of any kernel-space memory mapping will consist of [ **assignment** : _number greater than_
+_or equal to 4_ ] unpredictable bits.
+
+
+**Management: FPT_AEX_EXT.6**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FPT_AEX_EXT.6**
+
+
+There are no auditable events foreseen.
+
+
+**FPT_AEX_EXT.6 Write or Execute Memory Page Permissions**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: No dependencies.
+
+
+**FPT_AEX_EXT.6.1**
+
+
+The TSF shall prevent write and execute permissions from being simultaneously granted to any page of
+physical memory [ **selection** : _with no exceptions_, _[_ _**assignment**_ _: specific exceptions]_ ].
+
+
+**Management: FPT_AEX_EXT.7**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FPT_AEX_EXT.7**
+
+
+There are no auditable events foreseen.
+
+
+**FPT_AEX_EXT.7 Heap Overflow Protection**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: No dependencies.
+
+
+**FPT_AEX_EXT.7.1**
+
+
+The TSF shall include heap-based buffer overflow protections in the runtime environment it provides to
+processes that execute on the application processor.
+
+
+**C.2.3.2 FPT_BBD_EXT Baseband Processing**
+
+
+**Family Behavior**
+
+
+This family defines requirements for separation of baseband and application processor execution.
+
+
+**Component Leveling**
+
+|FPT_BBD_EXT|Col2|1|
+|---|---|---|
+|FPT_BBD_EXT|||
+
+
+
+FPT_BBD_EXT.1, Application Processor Mediation, requires the TSF to enforce separation between
+baseband and application processor execution except through application processor mechanisms.
+
+
+**Management: FPT_BBD_EXT.1**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FPT_BBD_EXT.1**
+
+
+There are no auditable events foreseen.
+
+
+**FPT_BBD_EXT.1 Application Processor Mediation**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: No dependencies.
+
+
+**FPT_BBD_EXT.1.1**
+
+
+The TSF shall prevent code executing on any baseband processor (BP) from accessing application
+processor (AP) resources except when mediated by the AP.
+
+
+**C.2.3.3 FPT_BLT_EXT Limitation of Bluetooth Profile Support**
+
+
+**Family Behavior**
+
+
+This family defines requirements for limiting Bluetooth capabilities without user action.
+
+
+**Component Leveling**
+
+|FPT_BLT_EXT|Col2|1|
+|---|---|---|
+|FPT_BLT_EXT|||
+
+
+
+FPT_BLT_EXT.1, Limitation of Bluetooth Profile Support, requires the TSF to maintain a disabled by default
+posture for Bluetooth profiles.
+
+
+**Management: FPT_BLT_EXT.1**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FPT_BLT_EXT.1**
+
+
+There are no auditable events foreseen.
+
+
+**FPT_BLT_EXT.1 Limitation of Bluetooth Profile Support**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: No dependencies.
+
+
+**FPT_BLT_EXT.1.1**
+
+
+The TSF shall disable support for [ **assignment** : _list of Bluetooth profiles_ ] Bluetooth profiles when they
+are not currently being used by an application on the Mobile Device, and shall require explicit user action
+to enable them.
+
+
+**C.2.3.4 FPT_JTA_EXT JTAG Disablement**
+
+
+**Family Behavior**
+
+
+This family defines requirements for JTAG interface access limitations.
+
+
+**Component Leveling**
+
+|FPT_JTA_EXT|Col2|1|
+|---|---|---|
+|FPT_JTA_EXT|||
+
+
+
+FPT_JTA_EXT.1, JTAG Disablement, requires the TSF to specify the mechanism used to restrict access to its
+JTAG interface.
+
+
+**Management: FPT_JTA_EXT.1**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FPT_JTA_EXT.1**
+
+
+There are no auditable events foreseen.
+
+
+**FPT_JTA_EXT.1 JTAG Disablement**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: No dependencies.
+
+
+**FPT_JTA_EXT.1.1**
+
+
+The TSF shall [ **assignment** : _list access control mechanisms_ ] to JTAG.
+
+
+**C.2.3.5 FPT_KST_EXT Key Storage**
+
+
+**Family Behavior**
+
+
+This family defines requirements for protecting plaintext keys.
+
+
+**Component Leveling**
+
+
+
+
+
+
+|FPT_KST_EXT|1|
+|---|---|
+|FPT_KST_EXT|2|
+|FPT_KST_EXT|3|
+
+
+
+FPT_KST_EXT.1, Key Storage, requires the TSF to avoid storage of plaintext keys in readable memory.
+
+
+FPT_KST_EXT.2, No Key Transmission, requires the TSF to prevent transmitting plaintext key material to
+the operational environment.
+
+
+FPT_KST_EXT.3, No Plaintext Key Export, requires the TSF to prevent the export of plaintext keys.
+
+
+**Management: FPT_KST_EXT.1**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FPT_KST_EXT.1**
+
+
+There are no auditable events foreseen.
+
+
+**FPT_KST_EXT.1 Key Storage**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: No dependencies.
+
+
+**FPT_KST_EXT.1.1**
+
+
+The TSF shall not store any plaintext key material in readable non-volatile memory.
+
+
+**Management: FPT_KST_EXT.2**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FPT_KST_EXT.2**
+
+
+There are no auditable events foreseen.
+
+
+**FPT_KST_EXT.2 No Key Transmission**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: No dependencies.
+
+
+**FPT_KST_EXT.2.1**
+
+
+The TSF shall not transmit any plaintext key material outside the security boundary of the TOE.
+
+
+**Management: FPT_KST_EXT.3**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FPT_KST_EXT.3**
+
+
+There are no auditable events foreseen.
+
+
+**FPT_KST_EXT.3 No Plaintext Key Export**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: No dependencies.
+
+
+**FPT_KST_EXT.3.1**
+
+
+The TSF shall ensure it is not possible for the TOE users to export plaintext keys.
+
+
+**C.2.3.6 FPT_NOT_EXT Self-Test Notification**
+
+
+**Family Behavior**
+
+
+This family defines requirements for generation of notifications in response to completed self-tests.
+
+
+**Component Leveling**
+
+
+
+
+
+
+|FPT_NOT_EXT|Col2|1|
+|---|---|---|
+|FPT_NOT_EXT|FPT_NOT_EXT|2|
+|FPT_NOT_EXT|||
+
+
+
+FPT_NOT_EXT.1, Self-Test Notification, requires the TSF to become non-operational when certain failures
+occur.
+
+
+FPT_NOT_EXT.2, Software Integrity Verification, requires the TSF to generate and sign software integrity
+verification values.
+
+
+**Management: FPT_NOT_EXT.1**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FPT_NOT_EXT.1**
+
+
+The following actions should be auditable if FAU_GEN Security audit data generation is included in the
+PP/ST:
+
+
+Measurement of TSF software.
+
+
+**FPT_NOT_EXT.1 Self-Test Notification**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FPT_TST_EXT.1 TSF Cryptographic Functionality Testing
+FPT_TST_EXT.2 TSF Integrity Checking
+
+
+**FPT_NOT_EXT.1.1**
+
+
+The TSF shall transition to non-operational mode and [ **selection** : _log failures in the audit record_, _notify_
+_the administrator_, _[_ _**assignment**_ _: other actions]_, _no other actions_ ] when the following types of failures
+occur:
+
+failures of the self-tests
+TSF software integrity verification failures
+
+[ **selection** : _no other failures_, _[_ _**assignment**_ _: other failures]_ ]
+
+
+**Management: FPT_NOT_EXT.2**
+
+
+The following actions could be considered for the management functions in FMT:
+
+
+Retrieval of TSF software integrity verification values.
+
+
+**Audit: FPT_NOT_EXT.2**
+
+
+There are no auditable events foreseen.
+
+
+**FPT_NOT_EXT.2 Software Integrity Verification**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FCS_COP.1 Cryptographic Operation
+
+
+**FPT_NOT_EXT.2.1**
+
+
+The TSF shall [ **selection** : _audit_, _provide the administrator with_ ] TSF-software integrity verification
+values.
+
+
+**FPT_NOT_EXT.2.2**
+
+
+The TSF shall cryptographically sign all integrity verification values.
+
+
+**C.2.3.7 FPT_TST_EXT TSF Self Test**
+
+
+**Family Behavior**
+
+
+This family defines requirements for execution of self-tests that are not addressed by FPT_TST in CC Part 2.
+
+
+**Component Leveling**
+
+
+
+
+
+
+|FPT_TST_EXT|Col2|1|
+|---|---|---|
+|FPT_TST_EXT|FPT_TST_EXT|3|
+|FPT_TST_EXT|||
+
+
+
+FPT_TST_EXT.1, TSF Cryptographic Functionality Testing, requires the TSF to run self-test at start-up to
+verify correct operation.
+
+
+FPT_TST_EXT.3, TSF Integrity Testing, requires the TSF to validate a code signing certificate before the
+associated code is executed.
+
+
+**Management: FPT_TST_EXT.1**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FPT_TST_EXT.1**
+
+
+The following actions should be auditable if FAU_GEN Security audit data generation is included in the
+PP/ST:
+
+
+Initiation of self-test.
+Failure of self-test.
+
+
+**FPT_TST_EXT.1 TSF Cryptographic Functionality Testing**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FCS_COP.1 Cryptographic Operation
+
+
+**FPT_TST_EXT.1.1**
+
+
+The TSF shall run a suite of self-tests during initial start-up (on power on) to demonstrate the correct
+operation of all cryptographic functionality.
+
+
+**Management: FPT_TST_EXT.3**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FPT_TST_EXT.3**
+
+
+There are no auditable events foreseen.
+
+
+**FPT_TST_EXT.3 TSF Integrity Testing**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FPT_TST_EXT.2 TSF Integrity Checking
+FIA_X509_EXT.1 X.509 Validation of Certificates
+FIA_X509_EXT.2 X.509 Certificate Authentication
+
+
+**FPT_TST_EXT.3.1**
+
+
+The TSF shall not execute code if the code signing certificate is deemed invalid.
+
+
+**C.2.3.8 FPT_TUD_EXT TSF Updates**
+
+
+**Family Behavior**
+
+
+This family defines requirements for trusted updates.
+
+
+**Component Leveling**
+
+
+
+
+|FPT_TUD_EXT|1|
+|---|---|
+|FPT_TUD_EXT|2|
+|FPT_TUD_EXT|3|
+|FPT_TUD_EXT|4|
+|FPT_TUD_EXT|5|
+|FPT_TUD_EXT|6|
+
+
+
+FPT_TUD_EXT.1, TSF Version Query, requires the TSF to provide authorized users the ability to query the
+version of the TOE hardware, TOE software, and installed applications.
+
+
+FPT_TUD_EXT.2, TSF Update Verification, requires the TSF to ensure that system software updates are
+digitally signed prior to installation.
+
+
+FPT_TUD_EXT.3, Application Signing, requires the TSF to ensure that application software updates are
+digitally signed prior to installation.
+
+
+FPT_TUD_EXT.4, Trusted Update Verification, requires the TSF to enforce validity of system softwareโs
+code signing certificate prior to installation.
+
+
+FPT_TUD_EXT.5, Application Verification, requires the TSF to enforce validity of application softwareโs
+code signing certificate prior to installation.
+
+
+FPT_TUD_EXT.6, Trusted Update Verification, requires the TSF to prevent the intentional rollback of
+software updates.
+
+
+**Management: FPT_TUD_EXT.1**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FPT_TUD_EXT.1**
+
+
+There are no auditable events foreseen.
+
+
+**FPT_TUD_EXT.1 TSF Version Query**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: No dependencies.
+
+
+**FPT_TUD_EXT.1.1**
+
+
+The TSF shall provide authorized users the ability to query the current version of the TOE
+firmware/software.
+
+
+**FPT_TUD_EXT.1.2**
+
+
+The TSF shall provide authorized users the ability to query the current version of the hardware model of
+the device.
+
+
+**FPT_TUD_EXT.1.3**
+
+
+The TSF shall provide authorized users the ability to query the current version of installed mobile
+applications.
+
+
+**Management: FPT_TUD_EXT.2**
+
+
+The following actions could be considered for the management functions in FMT:
+
+
+Updating of system software.
+
+
+**Audit: FPT_TUD_EXT.2**
+
+
+The following actions should be auditable if FAU_GEN Security audit data generation is included in the
+PP/ST:
+
+
+Success or failure of signature verification for applications.
+
+
+**FPT_TUD_EXT.2 TSF Update Verification**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FCS_COP.1 Cryptographic Operation
+
+
+**FPT_TUD_EXT.2.1**
+
+
+The TSF shall verify software updates to the Application Processor system software and [ **selection** :
+
+_[_ _**assignment**_ _: other processor system software]_, _no other processor system software_ ] using a digital
+signature verified by the manufacturer trusted key prior to installing those updates.
+
+
+**FPT_TUD_EXT.2.2**
+
+
+The TSF shall [ **selection** : _never update_, _update only by verified software_ ] the TSF boot integrity
+
+[ **selection** : _key_, _hash_ ].
+
+
+**FPT_TUD_EXT.2.3**
+
+
+The TSF shall verify that the digital signature verification key used for TSF updates [ **selection** : _is_
+_validated to a public key in the Trust Anchor Database_, _matches an immutable hardware public key_ ].
+
+
+**Management: FPT_TUD_EXT.3**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FPT_TUD_EXT.3**
+
+
+The following actions should be auditable if FAU_GEN Security audit data generation is included in the
+PP/ST:
+
+
+Success or failure of signature verification for applications.
+
+
+**FPT_TUD_EXT.3 Application Signing**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FIA_X509_EXT.1 X.509 Validation of Certificates
+FIA_X509_EXT.2 X.509 Certificate Authentication
+
+
+**FPT_TUD_EXT.3.1**
+
+
+The TSF shall verify mobile application software using a digital signature mechanism prior to installation.
+
+
+**Management: FPT_TUD_EXT.4**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FPT_TUD_EXT.4**
+
+
+There are no auditable events foreseen.
+
+
+**FPT_TUD_EXT.4 Trusted Update Verification**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FIA_X509_EXT.1 X.509 Validation of Certificates
+FIA_X509_EXT.2 X.509 Certificate Authentication
+
+
+**FPT_TUD_EXT.4.1**
+
+
+The TSF shall not install code if the code signing certificate is deemed invalid.
+
+
+**Management: FPT_TUD_EXT.5**
+
+
+The following actions should be auditable if FAU_GEN Security audit data generation is included in the
+PP/ST:
+
+
+Configure certificate or public key used to validate digital signature on applications.
+
+
+**Audit: FPT_TUD_EXT.5**
+
+
+There are no auditable events foreseen.
+
+
+**FPT_TUD_EXT.5 Application Verification**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FIA_X509_EXT.1 X.509 Validation of Certificates
+FIA_X509_EXT.2 X.509 Certificate Authentication
+
+
+**FPT_TUD_EXT.5.1**
+
+
+The TSF shall by default only install mobile applications cryptographically verified by [ **selection** : _a built-_
+_in X.509v3 certificate_, _a configured X.509v3 certificate_ ].
+
+
+**Management: FPT_TUD_EXT.6**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FPT_TUD_EXT.6**
+
+
+There are no auditable events foreseen.
+
+
+**FPT_TUD_EXT.6 Trusted Update Verification**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: No dependencies.
+
+
+**FPT_TUD_EXT.6.1**
+
+
+The TSF shall verify that software updates to the TSF are a current or later version than the current
+version of the TSF.
+
+
+**C.2.4 Class: Security Management (FMT)**
+This PP defines the following extended components as part of the FMT class originally defined by CC Part 2:
+
+
+**C.2.4.1 FMT_MOF_EXT Management of Functions in TSF**
+
+
+**Family Behavior**
+
+
+This family defines requirements for authorization to manage the behavior of the TSF that are not
+addressed by FMT_MOF in CC Part 2.
+
+
+**Component Leveling**
+
+|FMT_MOF_EXT|Col2|1|
+|---|---|---|
+|FMT_MOF_EXT|||
+
+
+
+FMT_MOF_EXT.1, Management of Security Functions Behavior, requires the TSF to apply restrictions to
+access its management functions to the authorized roles.
+
+
+**Management: FMT_MOF_EXT.1**
+
+
+The following actions could be considered for the management functions in FMT:
+
+
+Managing the group of roles that can interact with the functions in the TSF.
+
+
+**Audit: FMT_MOF_EXT.1**
+
+
+There are no auditable events foreseen.
+
+
+**FMT_MOF_EXT.1 Management of Security Functions Behavior**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FMT_SMF.1 Specification of Management Functions
+
+
+**FMT_MOF_EXT.1.1**
+
+
+The TSF shall restrict the ability to perform the functions [ **assignment** : _reference to list of management_
+_functions_ ] to the user.
+
+
+**FMT_MOF_EXT.1.2**
+
+
+The TSF shall restrict the ability to perform the functions [ **assignment** : _reference to list of management_
+_functions_ ] to the administrator when the device is enrolled and according to the administrator-configured
+policy.
+
+
+**C.2.4.2 FMT_SMF_EXT Specification of Management Functions**
+
+
+**Family Behavior**
+
+
+This family defines requirements for security-relevant management functions that are not addressed by
+FMT_SMF in CC Part 2.
+
+
+**Component Leveling**
+
+
+
+
+
+
+|FMT_SMF_EXT|Col2|2|
+|---|---|---|
+|FMT_SMF_EXT|FMT_SMF_EXT|3|
+|FMT_SMF_EXT|||
+
+
+
+FMT_SMF_EXT.2, Specification of Remediation Actions, requires the TSF to automatically perform specific
+management functions in response to a specific event.
+
+
+FMT_SMF_EXT.3, Current Administrator, requires the TSF to provide users with a list of administrators and
+their specified functions.
+
+
+**Management: FMT_SMF_EXT.2**
+
+
+The following actions could be considered for the management functions in FMT:
+
+
+Configuration of the functions that are performed in response to unenrollment event.
+
+
+**Audit: FMT_SMF_EXT.2**
+
+
+The following actions should be auditable if FAU_GEN Security audit data generation is included in the
+PP/ST:
+
+
+Initiation of unenrollment.
+Completion of unenrollment.
+
+
+**FMT_SMF_EXT.2 Specification of Remediation Actions**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: No dependencies.
+
+
+**FMT_SMF_EXT.2.1**
+
+
+The TSF shall offer [ **assignment** : _list of remediation actions_ ] upon unenrollment and [ **assignment** : _list of_
+_triggers_ ].
+
+
+**Management: FMT_SMF_EXT.3**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FMT_SMF_EXT.3**
+
+
+There are no auditable events foreseen.
+
+
+**FMT_SMF_EXT.3 Current Administrator**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FMT_SMR.1 Security Roles
+
+
+**FMT_SMF_EXT.3.1**
+
+
+The TSF shall provide a mechanism that allows users to view a list of currently authorized administrators
+and the management functions that each administrator is authorized to perform.
+
+
+**C.2.5 Class: TOE Access (FTA)**
+This PP defines the following extended components as part of the FTA class originally defined by CC Part 2:
+
+
+**C.2.5.1 FTA_SSL_EXT Session Locking and Termination**
+
+
+**Family Behavior**
+
+
+This family defines requirements for session locking capabilities that are not addressed by FTA_SSL in CC
+Part 2.
+
+
+**Component Leveling**
+
+|FTA_SSL_EXT|Col2|1|
+|---|---|---|
+|FTA_SSL_EXT|||
+
+
+
+FTA_SSL_EXT.1, TSF- and User-initiated Locked State, requires the TSF to manage the transition to a
+locked state and what operations can be performed.
+
+
+**Management: FTA_SSL_EXT.1**
+
+
+The following actions could be considered for the management functions in FMT:
+
+
+Configuring session locking policy.
+Transitioning to the locked state.
+
+
+**Audit: FTA_SSL_EXT.1**
+
+
+There are no auditable events foreseen.
+
+
+**FTA_SSL_EXT.1 TSF- and User-initiated Locked State**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: No dependencies.
+
+
+**FTA_SSL_EXT.1.1**
+
+
+The TSF shall transition to a locked state after a time interval of inactivity.
+
+
+**FTA_SSL_EXT.1.2**
+
+
+The TSF shall transition to a locked state after initiation by either the user or the administrator.
+
+
+**FTA_SSL_EXT.1.3**
+
+
+The TSF shall, upon transitioning to the locked state, perform the following operations:
+
+Clearing or overwriting display devices, obscuring the previous contents;
+
+[ **assignment** : _Other actions performed upon transitioning to the locked state_ ].
+
+
+**C.2.6 Class: Trusted Path/Channels (FTP)**
+This PP defines the following extended components as part of the FTP class originally defined by CC Part 2:
+
+
+**C.2.6.1 FTP_ITC_EXT Inter-TSF Trusted Channel**
+
+
+**Family Behavior**
+
+
+This family defines requirements for trusted channels that are not addressed by FTP_ITC in CC Part 2
+
+
+because they apply specifically to channels required by a mobile device.
+
+
+**Component Leveling**
+
+|FTP_ITC_EXT|Col2|1|
+|---|---|---|
+|FTP_ITC_EXT|||
+
+
+
+FTP_ITC_EXT.1, Trusted Channel Communication, requires the TSF to manage the communication channel
+between itself and other trusted products.
+
+
+**Management: FTP_ITC_EXT.1**
+
+
+The following actions could be considered for the management functions in FMT:
+
+
+Configuring the actions that require trusted channel, if applicable.
+Enabling/disabling communications protocols where the TSF acts as a server.
+
+
+**Audit: FTP_ITC_EXT.1**
+
+
+The following actions should be auditable if FAU_GEN Security audit data generation is included in the
+PP/ST:
+
+
+Initiation and termination of trusted channel.
+
+
+**FTP_ITC_EXT.1 Trusted Channel Communication**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: No dependencies.
+
+
+**FTP_ITC_EXT.1.1**
+
+
+The TSF shall use
+
+802.11-2012 in accordance with [ **assignment** : _requirements or standards defining implementation_
+_of this protocol_ ],
+802.1X in accordance with [ **assignment** : _requirements or standards defining implementation of this_
+_protocol_ ],
+EAP-TLS in accordance with [ **assignment** : _requirements or standards defining implementation of_
+_this protocol_ ],
+Mutually authenticated TLS in accordance with [ **assignment** : _requirements or standards defining_
+_implementation of this protocol_ ]
+
+and [ **assignment** : _other protocols_ ] protocols to provide a communication channel between itself and
+another trusted IT product that is logically distinct from other communication channels, provides assured
+identification of its end points, protects channel data from disclosure, and detects modification of the
+channel data.
+
+
+**FTP_ITC_EXT.1.2**
+
+
+The TSF shall permit the TSF to initiate communication via the trusted channel.
+
+
+**FTP_ITC_EXT.1.3**
+
+
+The TSF shall initiate communication via the trusted channel for wireless access point connections,
+administrative communication, configured enterprise connections, and [ **selection** : _OTA updates_, _no other_
+_connections_ ].
+
+
+**C.2.7 Class: User Data Protection (FDP)**
+
+This PP defines the following extended components as part of the FDP class originally defined by CC Part 2:
+
+
+**C.2.7.1 FDP_ACF_EXT Access Control Functions**
+
+
+**Family Behavior**
+
+
+This family defines the rules for access control functions that are not addressed by the FDP_ACF family in
+CC Part 2.
+
+
+**Component Leveling**
+
+
+
+
+
+
+|FDP_ACF_EXT|1|
+|---|---|
+|FDP_ACF_EXT|2|
+|FDP_ACF_EXT|3|
+
+
+
+FDP_ACF_EXT.1, Access Control for System Services, requires the TSF to be able to control access to its
+own services.
+
+
+FDP_ACF_EXT.2, Access Control for System Resources, requires the TSF to be able to provide separate
+copies of system resources for different application groups.
+
+
+FDP_ACF_EXT.3, Security Attribute Based Access Control, requires the TSF to enforce policies on
+applications that prohibit write and execute permissions from being granted simultaneously.
+
+
+**Management: FDP_ACF_EXT.1**
+
+
+The following actions could be considered for the management functions in FMT:
+
+
+Placing applications into application groups based on enterprise configuration settings.
+Enabling/disabling location services.
+Enabling/disabling data signaling over externally-accessible hardware ports.
+
+
+**Audit: FDP_ACF_EXT.1**
+
+
+There are no auditable events foreseen.
+
+
+**FDP_ACF_EXT.1 Access Control for System Services**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FMT_SMR.1 Security Roles
+
+
+**FDP_ACF_EXT.1.1**
+
+
+The TSF shall provide a mechanism to restrict the system services that are accessible to an application.
+
+
+**FDP_ACF_EXT.1.2**
+
+
+The TSF shall provide an access control policy that prevents [ **assignment** : _list of subjects_ ] from accessing
+
+[ **selection** : _all_, _private_ ] data stored by other [ **assignment** : _list of subjects_ ]. Exceptions may only be
+explicitly authorized for such sharing by [ **assignment** : _list of authorized subjects_ ].
+
+
+**Management: FDP_ACF_EXT.2**
+
+
+The following actions could be considered for the management functions in FMT:
+
+
+Approving exceptions for sharing data between applications or groups of applications.
+
+
+**Audit: FDP_ACF_EXT.2**
+
+
+There are no auditable events foreseen.
+
+
+**FDP_ACF_EXT.2 Access Control for System Resources**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FDP_ACF_EXT.1 Access Control for System Services
+FMT_SMR.1 Security Roles
+
+
+**FDP_ACF_EXT.2.1**
+
+
+The TSF shall provide a separate [ **selection** : _address book_, _calendar_, _keystore_, _account credential_
+_database, [_ _**assignment**_ _: list of additional resources]_ ] for each application group and only allow
+applications within that process group to access the resource. Exceptions may only be explicitly
+authorized for such sharing by [ **selection** : _the user_, _the administrator_, _no one_ ].
+
+
+**Management: FDP_ACF_EXT.3**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FDP_ACF_EXT.3**
+
+
+There are no auditable events foreseen.
+
+
+**FDP_ACF_EXT.3 Security Attribute Based Access Control**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: No dependencies.
+
+
+**FDP_ACF_EXT.3.1**
+
+
+The TSF shall enforce an access control policy that prohibits an application from granting both write and
+execute permission to a file on the device except for [ **selection** : _files stored in the application's private_
+_data folder_, _no exceptions_ ].
+
+
+**C.2.7.2 FDP_BCK_EXT Application Backup**
+
+
+**Family Behavior**
+
+
+This family defines requirements for managing device backups.
+
+
+**Component Leveling**
+
+|FDP_BCK_EXT|Col2|1|
+|---|---|---|
+|FDP_BCK_EXT|||
+
+
+
+FDP_BCK_EXT.1, Application Backup, requires the TSF to be able to determine which data to include in
+backup operations.
+
+
+**Management: FDP_BCK_EXT.1**
+
+
+The following actions could be considered for the management functions in FMT:
+
+
+Enable/disable backup of certain applications to a local or remote system.
+
+
+**Audit: FDP_BCK_EXT.1**
+
+
+There are no auditable events foreseen.
+
+
+**FDP_BCK_EXT.1 Application Backup**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: No dependencies.
+
+
+**FDP_BCK_EXT.1.1**
+
+
+The TSF shall provide a mechanism for applications to mark [ **assignment** : _list of data categories_ ] to be
+excluded from device backups.
+
+
+**C.2.7.3 FDP_BLT_EXT Limitation of Bluetooth Device Access**
+
+
+**Family Behavior**
+
+
+This family defines requirements for managing Bluetooth devices.
+
+
+**Component Leveling**
+
+|FDP_BLT_EXT|Col2|1|
+|---|---|---|
+|FDP_BLT_EXT|||
+
+
+
+FDP_BLT_EXT.1, Limitation of Bluetooth Device Access, requires the TSF to manage which applications
+communicate with Bluetooth devices.
+
+
+**Management: FDP_BLT_EXT.1**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FDP_BLT_EXT.1**
+
+
+There are no auditable events foreseen.
+
+
+**FDP_BLT_EXT.1 Limitation of Bluetooth Device Access**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: No dependencies.
+
+
+**FDP_BLT_EXT.1.1**
+
+
+The TSF shall limit the applications that may communicate with a particular paired Bluetooth device.
+
+
+**C.2.7.4 FDP_DAR_EXT Data-at-Rest Encryption**
+
+
+**Family Behavior**
+
+
+This family defines requirements for implementation of data-at-rest protection.
+
+
+**Component Leveling**
+
+
+
+
+
+
+|FDP_DAR_EXT|Col2|1|
+|---|---|---|
+|FDP_DAR_EXT|FDP_DAR_EXT|2|
+|FDP_DAR_EXT|||
+
+
+
+FDP_DAR_EXT.1, Protected Data Encryption, requires the TSF to be able to protect all data with a chosen
+method of encryption.
+
+
+FDP_DAR_EXT.2, Sensitive Data Encryption, requires the TSF to protect the Trust Anchor Database.
+
+
+**Management: FDP_DAR_EXT.1**
+
+
+The following actions could be considered for the management functions in FMT:
+
+
+Enabling data-at-rest protection.
+Enabling removable mediaโs data-at-rest protection.
+
+
+**Audit: FDP_DAR_EXT.1**
+
+
+The following actions should be auditable if FAU_GEN Security audit data generation is included in the
+PP/ST:
+
+
+Failure to encrypt/decrypt data.
+
+
+**FDP_DAR_EXT.1 Protected Data Encryption**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FCS_COP.1 Cryptographic Operation
+
+
+**FDP_DAR_EXT.1.1**
+
+
+Encryption shall cover all protected data.
+
+
+**FDP_DAR_EXT.1.2**
+
+
+Encryption shall be performed using DEKs with AES in the [ **assignment** : _list of AES modes_ ] mode with
+key size [ **assignment** : _list of acceptable key sizes_ ] bits.
+
+
+**Management: FDP_DAR_EXT.2**
+
+
+The following actions could be considered for the management functions in FMT:
+
+
+Importing X.509v3 certificates into the Trust Anchor Database.
+Removing imported X.509v3 certificates from the Trust Anchor Database.
+Approving import and removal by applications of X.509v3 certificates in the Trust Anchor Database.
+
+
+**Audit: FDP_DAR_EXT.2**
+
+
+The following actions should be auditable if FAU_GEN Security audit data generation is included in the
+PP/ST:
+
+
+Addition or removal of certificate from Trust Anchor Database
+
+
+**FDP_DAR_EXT.2 Sensitive Data Encryption**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FCS_COP.1 Cryptographic Operation
+FCS_CKM.2 Cryptographic Key Establishment
+FCS_STG_EXT.2 Encrypted Cryptographic Key Storage
+
+
+**FDP_DAR_EXT.2.1**
+
+
+The TSF shall provide a mechanism for applications to mark data and keys as sensitive.
+
+
+**FDP_DAR_EXT.2.2**
+
+
+The TSF shall use an asymmetric key scheme to encrypt and store sensitive data received while the
+product is locked.
+
+
+**FDP_DAR_EXT.2.3**
+
+
+The TSF shall encrypt any stored symmetric key and any stored private key of the asymmetric keys used
+for the protection of sensitive data according to [ **assignment** : _mechanism for encrypted key storage_ ].
+
+
+**FDP_DAR_EXT.2.4**
+
+
+The TSF shall decrypt the sensitive data that was received while in the locked state upon transitioning to
+the unlocked state using the asymmetric key scheme and shall re-encrypt that sensitive data using the
+symmetric key scheme.
+
+
+**C.2.7.5 FDP_IFC_EXT Subset Information Flow Control**
+
+
+**Family Behavior**
+
+
+This family defines requirements for handling of information flows that are not addressed by FDP_IFC in CC
+Part 2.
+
+
+**Component Leveling**
+
+|FDP_IFC_EXT|Col2|1|
+|---|---|---|
+|FDP_IFC_EXT|||
+
+
+
+FDP_IFC_EXT.1, Subset Information Flow Control, requires the TSF to be able to support the use of an
+IPsec VPN to protect data in transit.
+
+
+**Management: FDP_IFC_EXT.1**
+
+
+The following actions could be considered for the management functions in FMT:
+
+
+Enabling/disabling VPN protection.
+Enabling/disabling Always On VPN protection.
+
+
+**Audit: FDP_IFC_EXT.1**
+
+
+There are no auditable events foreseen.
+
+
+**FDP_IFC_EXT.1 Subset Information Flow Control**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FTP_ITC_EXT.1 Trusted Channel Communication
+
+
+**FDP_IFC_EXT.1.1**
+
+
+The TSF shall [ **selection** :
+
+_provide an interface which allows a VPN client to protect all IP traffic using IPsec_
+_[provide a VPN client which can protect all IP traffic using IPsec](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=467&id=467)_ _**as defined in the PP-Module for**_
+_**Virtual Private Network (VPN) Clients, version 2.4**_
+
+] with the exception of IP traffic needed to manage the VPN connection, and [ **selection** : _[_ _**assignment**_ _:_
+_traffic needed for correct functioning of the TOE]_, _no other traffic_ ], when the VPN is enabled.
+
+
+**C.2.7.6 FDP_STG_EXT User Data Storage**
+
+
+**Family Behavior**
+
+
+This family defines requirements for managing data storage.
+
+
+**Component Leveling**
+
+|FDP_STG_EXT|Col2|1|
+|---|---|---|
+|FDP_STG_EXT|||
+
+
+
+FDP_STG_EXT.1, User Data Storage, requires the TSF to be able to label, encrypt, store, and decrypt
+sensitive data and keys.
+
+
+**Management: FDP_STG_EXT.1**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FDP_STG_EXT.1**
+
+
+The following actions should be auditable if FAU_GEN Security audit data generation is included in the
+PP/ST:
+
+
+Failure to encrypt/decrypt data.
+
+
+**FDP_STG_EXT.1 User Data Storage**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FCS_COP.1 Cryptographic Operation
+FCS_CKM.2 Cryptographic Key Establishment
+FCS_STG_EXT.2 Encrypted Cryptographic Key Storage
+
+
+**FDP_STG_EXT.1.1**
+
+
+The TSF shall provide protected storage for the Trust Anchor Database.
+
+
+**C.2.7.7 FDP_UPC_EXT Inter-TSF User Data Transfer Protection**
+
+
+**Family Behavior**
+
+
+This family defines requirements for the use of trusted channel protocols to protect user data.
+
+
+**Component Leveling**
+
+|FDP_UPC_EXT|Col2|1|
+|---|---|---|
+|FDP_UPC_EXT|||
+
+
+
+FDP_UPC_EXT.1, Inter-TSF User Data Transfer Protection, requires the TSF to be able to protect
+communication channels between products using a chosen secure method.
+
+
+**Management: FDP_UPC_EXT.1**
+
+
+There are no management activities foreseen.
+
+
+**Audit: FDP_UPC_EXT.1**
+
+
+The following actions should be auditable if FAU_GEN Security audit data generation is included in the
+PP/ST:
+
+
+Application initiation of trusted channel.
+
+
+**FDP_UPC_EXT.1 Inter-TSF User Data Transfer Protection**
+
+
+Hierarchical to: No other components.
+
+
+Dependencies to: FTP_ITC_EXT.1 Trusted Channel Communication
+
+
+**FDP_UPC_EXT.1.1**
+
+
+The TSF shall provide a means for non-TSF applications executing on the TOE to use [ **assignment** : _data_
+_transfer protocol_ ] to provide a protected communication channel between the non-TSF application and
+another IT product that is logically distinct from other communication channels, provides assured
+
+
+identification of its end points, protects channel data from disclosure, and detects modification of the
+channel data.
+
+
+**FDP_UPC_EXT.1.2**
+
+
+The TSF shall permit the non-TSF applications to initiate communication via the trusted channel.
+
+
+# **Appendix D - Validation Guidelines**
+
+This appendix contains "rules" specified by the PP Authors that indicate whether certain selections require
+the making of other selections in order for a Security Target to be valid. For example, selecting "HMAC-SHA3-384" as a supported keyed-hash algorithm would require that "SHA-3-384" be selected as a hash algorithm.
+
+
+This appendix contains only such "rules" as have been defined by the PP Authors, and does not necessarily
+represent all such dependencies in the document.
+
+
+**Rule #1**
+
+
+
+
+
+
+
+
+
+
+
+|Rule #2|Col2|
+|---|---|
+|DECISION J|**CHOICE J1**
FromFCS_COP.1.1/HASH:
* selectSHA-256
* select256 bits|
+|DECISION J|**CHOICE J2**
FromFCS_COP.1.1/HASH:
Do not choose:
* SHA-256
Do not choose:
* 256 bits|
+
+
+|Rule #3|Col2|
+|---|---|
+|DECISION K|**CHOICE K1**
FromFCS_COP.1.1/HASH:
* selectSHA-384
* select384 bits|
+|DECISION K|**CHOICE K2**
FromFCS_COP.1.1/HASH:
Do not choose:
* SHA-384
Do not choose:
* 384 bits|
+
+
+|Rule #4|Col2|
+|---|---|
+|DECISION L|**CHOICE L1**
FromFCS_COP.1.1/HASH:
* selectSHA-512
* select512 bits|
+|DECISION L|**CHOICE L2**
FromFCS_COP.1.1/HASH:
Do not choose:
* SHA-512
Do not choose:
* 512 bits|
+
+
+**Rule #5**
+
+
+
+
+
+
+
+
+[From the Functional Package for Transport Layer Security (TLS):](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=439&id=439)
+THEN
+From FCS_TLSC_EXT.1.3:
+
+ - select with no exceptions
+
+
+**Rule #6**
+
+
+
+
+
+
+
+
+
+
+
+**Rule #7**
+
+
+
+
+
+
+
+
+
+
+
+**Rule #8**
+
+
+
+
+
+
+
+
+
+
+
+**Rule #9**
+
+
+
+
+
+
+
+
+
+
+
+**Rule #10**
+
+
+
+
+
+
+
+
+
+
+
+**Rule #11**
+
+
+
+
+
+
+
+
+
+
+
+**Rule #12**
+
+
+[From the Functional Package for Transport Layer Security (TLS):](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=439&id=439)
+From FCS_TLS_EXT.1.1:
+
+ - select TLS as a client
+
+
+From FCS_TLSC_EXT.1.1:
+
+ - select mutual authentication
+From FCS_TLSC_EXT.1.3:
+
+ - select with no exceptions
+
+
+**Rule #13**
+
+
+
+
+
+
+
+
+
+
+
+
+
+**Rule #14**
+
+
+
+
+
+
+
+THEN [Include the PP-Module for Virtual Private Network (VPN) Clients, version 2.4 module in the ST](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=467&id=467)
+
+
+# **Appendix E - Implicitly Satisfied Requirements**
+
+This appendix lists requirements that should be considered satisfied by products successfully evaluated
+against this PP. These requirements are not featured explicitly as SFRs and should not be included in the ST.
+They are not included as standalone SFRs because it would increase the time, cost, and complexity of
+evaluation. This approach is permitted by [CC] Part 1, 8.2 Dependencies between components.
+
+
+This information benefits systems engineering activities which call for inclusion of particular security
+controls. Evaluation against the PP provides evidence that these controls are present and have been
+evaluated.
+
+
+**Requirement** **Rationale for Satisfaction**
+
+
+
+FAU_SEL.1 Selective Audit
+
+
+FCS_CKM.1 Cryptographic
+Key Generation
+
+
+FCS_CKM.1 Cryptographic
+Key Generation
+
+
+FCS_CKM.2 Cryptographic
+Key
+Establishment
+
+
+FCS_COP.1 Cryptographic
+Operation
+
+
+FCS_STG_EXT.1
+
+- Cryptographic
+Key Storage
+
+
+FDP_ACF_EXT.1
+
+- Access Control
+for System
+Services
+
+
+FDP_ACF_EXT.2
+
+- Access Control
+for System
+Resources
+
+
+FIA_AFL_EXT.1 Authentication
+Failure Handling
+
+
+FIA_PMG_EXT.1
+
+- Password
+Management
+
+
+FIA_UAU.7 Protected
+Authentication
+Feedback
+
+
+FMT_SMF_EXT.3
+
+- Current
+Administrator
+
+
+
+FAU_SEL.1 has a dependency on FMT_MTD.1 since configuration of audit data is a
+subset of managing TSF data. This dependency is met by FMT_SMF.1, which defines
+"configure the auditable items" as a management function and specifies the roles that
+may perform this, consistent with how FMT_MTD.1 would typically satisfy the
+dependency.
+
+
+FCS_CKM.1 has a dependency on FCS_CKM.4 for the subsequent destruction of any
+keys that the TSF generates. This dependency is met by the extended SFR
+FCS_CKM_EXT.4, which serves the same purpose.
+
+
+FCS_CKM.1 has a dependency on FCS_CKM.4 for the subsequent destruction of any
+keys that the TSF generates. This dependency is met by the extended SFR
+FCS_CKM_EXT.4, which serves the same purpose as its CC Part 2 equivalent.
+
+
+Both iterations of FCS_CKM.2 have a dependency on FCS_CKM.4 for the subsequent
+destruction of any keys that the TSF establishes. This dependency is met by the
+extended SFR FCS_CKM_EXT.4, which serves the same purpose as its CC Part 2
+equivalent.
+
+
+All iterations of FCS_COP.1 have a dependency on FCS_CKM.4 for the subsequent
+destruction of any residual key material the TSF creates as part of the operation. This
+dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same
+purpose as its CC Part 2 equivalent.
+
+
+FCS_STG_EXT.1 has a dependency on FMT_SMR.1 for the management roles that are
+authorized to manage the functionality defined by the requirement. This dependency is
+met by FMT_SMF.1, which implicitly defines separate management roles for the TSF.
+
+
+FDP_ACF_EXT.1 has a dependency on FMT_SMR.1 for the management roles that are
+authorized to manage the functionality defined by the requirement. This dependency is
+met by FMT_SMF.1, which implicitly defines separate management roles for the TSF.
+
+
+FDP_ACF_EXT.2 has a dependency on FMT_SMR.1 for the management roles that are
+authorized to manage the functionality defined by the requirement. This dependency is
+met by FMT_SMF.1, which implicitly defines separate management roles for the TSF.
+
+
+FIA_AFL_EXT.1 has a dependency on FIA_UAU.1 since handling of authentication
+failures is not possible without an authentication mechanism. This dependency is met by
+the extended SFR FIA_UAU_EXT.1, which serves the same purpose as its CC Part 2
+equivalent.
+
+
+FIA_PMG_EXT.1 has a dependency on FIA_UAU.1 since composition of authentication
+credentials is not possible without an authentication mechanism. This dependency is met
+by the extended SFR FIA_UAU_EXT.1, which serves the same purpose as its CC Part 2
+equivalent.
+
+
+FIA_UAU.7 has a dependency on FIA_UAU.1 since protected authentication feedback is
+not possible without an authentication mechanism. This dependency is met by the
+extended SFR FIA_UAU_EXT.1, which serves the same purpose as its CC Part 2
+equivalent.
+
+
+FMT_SMF_EXT.3 has a dependency on FMT_SMR.1 through its reference to
+management roles in the requirement text. This dependency is met by FMT_SMF.1,
+which implicitly defines separate management roles for the TSF.
+
+
+# **Appendix F - Entropy Documentation And** **Assessment**
+
+The documentation of the entropy source should be detailed enough that, after reading, the evaluator will
+thoroughly understand the entropy source and why it can be relied upon to provide entropy. This
+documentation should include multiple detailed sections: design description, entropy justification, operating
+conditions, and health testing. This documentation is not required to be part of the TSS.
+
+
+**F.1 Design Description**
+
+
+Documentation shall include the design of the entropy source as a whole, including the interaction of all
+entropy source components. It will describe the operation of the entropy source to include how it works, how
+entropy is produced, and how unprocessed (raw) data can be obtained from within the entropy source for
+testing purposes. The documentation should walk through the entropy source design indicating where the
+random comes from, where it is passed next, any post-processing of the raw outputs (hash, XOR, etc.),
+if/where it is stored, and finally, how it is output from the entropy source. Any conditions placed on the
+process (e.g., blocking) should also be described in the entropy source design. Diagrams and examples are
+encouraged.
+
+
+This design must also include a description of the content of the security boundary of the entropy source and
+a description of how the security boundary ensures that an adversary outside the boundary cannot affect the
+entropy rate.
+
+
+If implemented, the design description shall include a description of how third-party applications can add
+entropy to the RBG. A description of any RBG state saving between power-off and power-on shall be included.
+
+
+**F.2 Entropy Justification**
+
+
+There should be a technical argument for where the unpredictability in the source comes from and why there
+is confidence in the entropy source exhibiting probabilistic behavior (an explanation of the probability
+distribution and justification for that distribution given the particular source is one way to describe this). This
+argument will include a description of the expected entropy rate and explain how you ensure that sufficient
+entropy is going into the TOE randomizer seeding process. This discussion will be part of a justification for
+why the entropy source can be relied upon to produce bits with entropy.
+
+
+The entropy justification shall not include any data added from any third-party application or from any state
+saving between restarts.
+
+
+**F.3 Operating Conditions**
+
+
+Documentation will also include the range of operating conditions under which the entropy source is expected
+to generate random data. It will clearly describe the measures that have been taken in the system design to
+ensure the entropy source continues to operate under those conditions. Similarly, documentation shall
+describe the conditions under which the entropy source is known to malfunction or become inconsistent.
+Methods used to detect failure or degradation of the source shall be included.
+
+
+**F.4 Health Testing**
+
+
+More specifically, all entropy source health tests and their rationale will be documented. This will include a
+description of the health tests, the rate and conditions under which each health test is performed (e.g., at
+startup, continuously, or on-demand), the expected results for each health test, and rationale indicating why
+each test is believed to be appropriate for detecting one or more failures in the entropy source.
+
+
+# **Appendix G - Initialization Vector Requirements** **for NIST-Approved Cipher Modes**
+
+Table 11: References and IV Requirements for NIST-approved Cipher Modes
+
+
+**Cipher Mode** **Reference** **IV Requirements**
+
+
+
+Counter (CTR) SP 80038A
+
+
+Cipher Block Chaining (CBC) SP 80038A
+
+
+Output Feedback (OFB) SP 80038A
+
+
+Cipher Feedback (CFB) SP 80038A
+
+
+
+
+
+XEX (XOR Encrypt XOR)
+Tweakable Block Cipher with
+Ciphertext Stealing (XTS)
+
+
+Cipher-based Message
+Authentication Code (CMAC)
+
+
+Key Wrap and Key Wrap with
+Padding
+
+
+Counter with CBC-Message
+Authentication Code (CCM)
+
+
+
+SP 80038E
+
+
+SP 80038B
+
+
+SP 80038F
+
+
+SP 80038C
+
+
+
+"Initial Counter" shall be non-repeating. No counter value shall
+be repeated across multiple messages with the same secret
+key.
+
+
+IVs shall be unpredictable. Repeating IVs leak information
+about whether the first one or more blocks are shared between
+two messages, so IVs should be non-repeating in such
+situations.
+
+
+IVs shall be non-repeating and shall not be generated by
+invoking the cipher on another IV.
+
+
+IVs should be non-repeating as repeating IVs leak information
+about the first plaintext block and about common shared
+prefixes in messages.
+
+
+No IV. Tweak values shall be non-negative integers, assigned
+consecutively, and starting at an arbitrary non-negative
+integer.
+
+
+No IV
+
+
+No IV
+
+
+No IV. Nonces shall be non-repeating.
+
+
+IV shall be non-repeating. The number of invocations of GCM
+
+implementation only uses 96-bit IVs (default length).
+
+
+
+Galois Counter Mode (GCM) SP 80038D
+
+
+# **Appendix H - Use Case Templates**
+
+**H.1 Enterprise-owned device for general-purpose enterprise use and limited**
+**personal use**
+
+
+The configuration for _[USE CASE 1] Enterprise-owned device for general-purpose enterprise use and limited_
+_personal use_ modifies the base requirements as follows:
+From FCS_STG_EXT.1.2:
+
+Do not choose:
+
+ - the user
+From FMT_SMF.1.1:
+
+Include 21 in the ST
+Include 25 in the ST and :
+
+ - for the 1 [st] assignment, Include personal Hotspot connections in the assignment
+Include 36 in the ST
+Include 39 in the ST and :
+
+ - select USB mass storage mode
+Include 41 in the ST and :
+
+ - select USB tethering
+Include FPT_BBD_EXT.1 in the ST
+Include FPT_TST_EXT.2/POSTKERNEL in ST.
+From FPT_TST_EXT.2.1/POSTKERNEL:
+
+ - select all executable code
+
+Include FPT_TUD_EXT.5 in the ST
+Include FTA_TAB.1 in the ST
+
+
+**H.2 Enterprise-owned device for specialized, high security use**
+
+
+The configuration for _[USE CASE 2] Enterprise-owned device for specialized, high security use_ modifies the
+base requirements as follows:
+
+
+
+
+
+
+|DECISION B|CHOICE B1
From FCS_CKM_EXT.1.1:
* select symmetric
* select 256 bits|
+|---|---|
+|DECISION B|**CHOICE B2**
FromFCS_CKM_EXT.1.1:
* selectasymmetric
* select128 bits|
+
+
+|DECISION C|CHOICE C1
From FCS_CKM_EXT.3.1:
* select symmetric KEKs
* select 256-bit|
+|---|---|
+|DECISION C|**CHOICE C2**
FromFCS_CKM_EXT.3.1:
* selectasymmetric KEKs
* for the1st assignment, 128|
+
+
+
+DECISION A
+
+
+
+**CHOICE A2**
+From FCS_CKM.1.1:
+
+ - select ECC schemes
+
+
+
+
+
+
+|DECISION D|CHOICE D1
From FCS_CKM_EXT.1.1:
* select symmetric
* select 256 bits|
+|---|---|
+|DECISION D|**CHOICE D2**
FromFCS_CKM_EXT.1.1:
* selectasymmetric
* select192 bits|
+
+
+|DECISION E|CHOICE E1
From FCS_CKM_EXT.3.1:
* select symmetric KEKs
* select 256-bit|
+|---|---|
+|DECISION E|**CHOICE E2**
FromFCS_CKM_EXT.3.1:
* selectasymmetric KEKs
* for the1st assignment, 128|
+
+
+
+
+
+[From the Functional Package for Transport Layer Security (TLS):](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=439&id=439)
+From FCS_TLSS_EXT.1.3:
+
+ - select ECDHE parameters using elliptic curves [ **selection** : _secp256r1_, _secp384r1_,
+_secp521r1_ ] and no other curves
+
+ - select secp384r1
+
+
+|DECISION F|CHOICE F1
From FCS_CKM.2.1/LOCKED:
* select Elliptic curve-based key establishment schemes
* select Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography|
+|---|---|
+|DECISION F|**CHOICE F2**
FromFCS_CKM.2.1/LOCKED:
* selectRSA-based key establishment schemes|
+
+
+
+From FCS_COP.1.1/ENCRYPT:
+
+ - select 256-bit key sizes
+From FCS_RBG_EXT.1.2:
+
+ - select 256 bits
+From FDP_DAR_EXT.1.2:
+
+ - select 256
+
+
+
+
+
+
+|DECISION G|CHOICE G1
From FIA_X509_EXT.2.2:
* select allow the administrator to choose|
+|---|---|
+|DECISION G|**CHOICE G2**
FromFIA_X509_EXT.2.2:
* selectnot accept the certificate|
+
+
+
+From FMT_SMF.1.1:
+
+Include 3 in the ST
+From 4:
+
+ - for the 1 [st] assignment, assign all radios on TSF
+From 5:
+
+ - for the 1 [st] assignment, assign all audio or visual collection devices on TSF
+Include 19 in the ST
+Include 21 in the ST
+Include 44 in the ST
+
+
+**H.3 Personally-owned device for personal and enterprise use**
+
+
+The configuration for _[USE CASE 3] Personally-owned device for personal and enterprise use_ modifies the
+base requirements as follows:
+
+
+
+
+
+
+|DECISION H|CHOICE H1
From FMT_SMF.1.1:
From 3:
* select on a per-app basis|
+|---|---|
+|DECISION H|**CHOICE H2**
FromFMT_SMF.1.1:
From3:
* selecton a per-group of applications processes basis|
+|DECISION H|**CHOICE H3**
FromFMT_SMF.1.1:
From3:
* selecton a per-app basis
* selecton a per-group of applications processes basis|
+
+
+
+
+|Col1|CHOICE I2
From FMT_SMF.1.1:
From 5:
* select on a per-group of applications processes basis|
+|---|---|
+|||
+||**CHOICE I3**
FromFMT_SMF.1.1:
From5:
* selecton a per-app basis
* selecton a per-group of applications processes basis|
+
+
+
+From FMT_SMF.1.1:
+
+Include 17 in the ST
+Include 28 in the ST
+Include 44 in the ST
+From FMT_SMF_EXT.2.1:
+
+ - select remove Enterprise applications
+From FDP_ACF_EXT.1.2:
+
+ - select groups of applications
+
+Include FDP_ACF_EXT.2 in the ST
+
+
+**H.4 Personally-owned device for personal and limited enterprise use**
+
+
+The use case _[USE CASE 4] Personally-owned device for personal and limited enterprise use_ makes no
+changes to the base requirements.
+
+
+# **Appendix I - Acronyms**
+
+**Acronym** **Meaning**
+
+
+AEAD Authenticated Encryption with Associated Data
+
+
+AES Advanced Encryption Standard
+
+
+ANSI American National Standards Institute
+
+
+AP Application Processor
+
+
+API Application Programming Interface
+
+
+ASLR Address Space Layout Randomization
+
+
+BAF Biometric Authentication Factor
+
+
+Base-PP Base Protection Profile
+
+
+BP Baseband Processor
+
+
+BR/EDR (Bluetooth) Basic Rate/Enhanced Data Rate
+
+
+BYOD Bring Your Own Device
+
+
+CA Certificate Authority
+
+
+CBC Cipher Block Chaining
+
+
+CC Common Criteria
+
+
+CCM Counter with CBC-Message Authentication Code
+
+
+CCMP CCM Protocol
+
+
+CEM Common Evaluation Methodology
+
+
+CMC Certificate Management over Cryptographic Message Syntax (CMS)
+
+
+cPP Collaborative Protection Profile
+
+
+CPU Central Processing Unit
+
+
+CRL Certificate Revocation List
+
+
+CSP Critical Security Parameter
+
+
+DAR Data At Rest
+
+
+DEK Data Encryption Key
+
+
+DEK Data Encryption Key
+
+
+DEP Data Execution Prevention
+
+
+DH Diffie-Hellman
+
+
+DNS Domain Name System
+
+
+DSA Digital Signature Algorithm
+
+
+DTLS Datagram Transport Layer Security
+
+
+EAP Extensible Authentication Protocol
+
+
+EAPOL EAP Over LAN
+
+
+ECDH Elliptic Curve Diffie Hellman
+
+
+ECDSA Elliptic Curve Digital Signature Algorithm
+
+
+EEPROM Electrically Erasable Programmable Read-Only Memory
+
+
+EP Extended Package
+
+
+EST Enrollment over Secure Transport
+
+
+FEK File Encryption Key
+
+
+FFC Finite Field Cryptography
+
+
+FIPS Federal Information Processing Standards
+
+
+FM Frequency Modulation
+
+
+FP Functional Package
+
+
+FQDN Fully Qualified Domain Name
+
+
+GCM Galois Counter Mode
+
+
+GPS Global Positioning System
+
+
+GPU Graphics Processing Unit
+
+
+HDMI High Definition Multimedia Interface
+
+
+HMAC Keyed-Hash Message Authentication Code
+
+
+HTTPS HyperText Transfer Protocol Secure
+
+
+IEEE Institute of Electrical and Electronics Engineers
+
+
+IP Internet Protocol
+
+
+IPC Inter-Process Communication
+
+
+IPsec Internet Protocol Security
+
+
+KAT Known Answer Test
+
+
+KDF Key Derivation Function
+
+
+KEK Key Encryption Key
+
+
+LE (Bluetooth) Low Energy
+
+
+LTE Long Term Evolution
+
+
+MD Mobile Device
+
+
+MDM Mobile Device Management
+
+
+MMI Man-Machine Interface
+
+
+MMS Multimedia Messaging Service
+
+
+MMU Memory Management Unit
+
+
+NFC Near Field Communication
+
+
+NIST National Institute of Standards and Technology
+
+
+NTP Network Time Protocol
+
+
+NX Never Execute
+
+
+OCSP Online Certificate Status Protocol
+
+
+OE Operational Environment
+
+
+OID Object Identifier
+
+
+OS Operating System
+
+
+OTA Over the Air
+
+
+PAE Port Access Entity
+
+
+PBKDF Password-Based Key Derivation Function
+
+
+PD Protected Data
+
+
+PIV Personal Identity Verification
+
+
+PMK Pairwise Master Key
+
+
+PP Protection Profile
+
+
+PP-Configuration Protection Profile Configuration
+
+
+PP-Module Protection Profile Module
+
+
+PRF Pseudorandom Function
+
+
+PSK Pre-Shared Key
+
+
+PTK Pairwise Temporal Key
+
+
+RA Registration Authority
+
+
+RBG Random Bit Generator
+
+
+REK Root Encryption Key
+
+
+ROM Read-only memory
+
+
+RSA Rivest Shamir Adleman Algorithm
+
+
+SAFAR System Authentication False Accept Rate
+
+
+SAR Security Assurance Requirement
+
+
+SFR Security Functional Requirement
+
+
+SHA Secure Hash Algorithm
+
+
+SMS Short Messaging Service
+
+
+SoC System On a Chip
+
+
+SPI Security Parameter Index
+
+
+SSH Secure Shell
+
+
+SSID Service Set Identifier
+
+
+ST Security Target
+
+
+TLS Transport Layer Security
+
+
+TOE Target of Evaluation
+
+
+TSF TOE Security Functionality
+
+
+TSFI TSF Interface
+
+
+TSS TOE Summary Specification
+
+
+URI Uniform Resource Identifier
+
+
+USB Universal Serial Bus
+
+
+USSD Unstructured Supplementary Service Data
+
+
+VPN Virtual Private Network
+
+
+XCCDF eXtensible Configuration Checklist Description Format
+
+
+XTS XEX (XOR Encrypt XOR) Tweakable Block Cipher with Ciphertext Stealing
+
+
+# **Appendix J - Bibliography**
+
+**Identifier** **Title**
+
+
+
+
+
+
+[CEM] Common Evaluation Methodology for Information Technology Security - Evaluation
+[Methodology, CCMB-2012-09-004, Version 3.1, Revision 5, April 2017.](http://www.commoncriteriaportal.org/files/ccfiles/CEMV3.1R5.pdf)
+
+
+# **Appendix K - Acknowledgments**
+
+This protection profile was developed by the Mobility Technical Community with representatives from
+industry, U.S. Government agencies, Common Criteria Test Laboratories, and international Common Criteria
+schemes. The National Information Assurance Partnership wishes to acknowledge and thank the members of
+this group whose dedicated efforts contributed significantly to the publication. These organizations include:
+
+
+**U.S. Government**
+Defense Information Systems Agency (DISA)
+CyberSecurity Directorate (CSD)
+National Information Assurance Partnership (NIAP)
+National Institute of Standards and Technology (NIST)
+
+
+**International Common Criteria Schemes**
+Australian Information Security Evaluation Program (AISEP)
+Canadian Common Criteria Evaluation and Certification Scheme (CSEC)
+Information-technology Promotion Agency, Japan (IPA)
+UK IT Security Evaluation and Certificate Scheme (NCSC)
+
+
+**Industry**
+Apple, Inc.
+BlackBerry
+LG Electronics, Inc.
+Microsoft Corporation
+Motorola Solutions
+Samsung Electronics Co., Ltd.
+Other Members of the Mobility Technical Community
+
+
+**Common Criteria Test Laboratories**
+EWA-Canada, Ltd.
+Gossamer Security Solutions
+
+
+
diff --git a/niap-cc/sdp-file-encrypt/doc/knowledge_base/st-google-android15.md b/niap-cc/sdp-file-encrypt/doc/knowledge_base/st-google-android15.md
new file mode 100644
index 0000000..d766898
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/doc/knowledge_base/st-google-android15.md
@@ -0,0 +1,6463 @@
+Consider using the pymupdf_layout package for a greatly improved page layout analysis.
+# Google Pixel Devices on Android 15 โ Security Target
+
+## **Google LLC**
+
+1600 Amphitheatre Parkway
+Mountain View, CA 94043
+USA
+
+
+
+Version: 1.0
+April 4, 2025
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+## Table of Contents
+
+
+**1** **Security Target Introduction .......................................................................................................5**
+1.1 Security Target Reference ............................................................................................................. 6
+1.2 TOE Reference ............................................................................................................................... 6
+1.3 TOE Overview ................................................................................................................................ 6
+1.4 TOE Description............................................................................................................................. 7
+1.4.1 TOE Architecture ................................................................................................................... 8
+1.4.2 TOE Documentation ............................................................................................................ 11
+**2** **Conformance Claims ................................................................................................................. 12**
+2.1 Conformance Rationale .............................................................................................................. 13
+**3** **Security Objectives ................................................................................................................... 14**
+3.1 Security Objectives for the Operational Environment ................................................................ 14
+**4** **Extended Components Definition.............................................................................................. 16**
+**5** **Security Requirements.............................................................................................................. 19**
+5.1 TOE Security Functional Requirements ...................................................................................... 19
+5.1.1 Security Audit (FAU) ............................................................................................................ 22
+5.1.2 Cryptographic Support (FCS) ............................................................................................... 28
+5.1.3 User Data Protection (FDP) ................................................................................................. 37
+5.1.4 Identification and Authentication (FIA) .............................................................................. 39
+5.1.5 Security management (FMT) ............................................................................................... 46
+5.1.6 Protection of the TSF (FPT) ................................................................................................. 55
+5.1.7 TOE Access (FTA) ................................................................................................................. 58
+5.1.8 Trusted Path/Channels (FTP) .............................................................................................. 59
+5.2 TOE Security Assurance Requirements ....................................................................................... 61
+5.2.1 Development (ADV) ............................................................................................................ 61
+5.2.2 Guidance Documents (AGD) ............................................................................................... 62
+5.2.3 Life-cycle support (ALC) ...................................................................................................... 63
+5.2.4 Tests (ATE) ........................................................................................................................... 64
+5.2.5 Vulnerability assessment (AVA) .......................................................................................... 64
+**6** **TOE Summary Specification ...................................................................................................... 66**
+6.1 Security audit .............................................................................................................................. 66
+6.2 Cryptographic support ................................................................................................................ 68
+6.3 User data protection ................................................................................................................... 79
+6.4 Identification and authentication ............................................................................................... 85
+6.5 Security management ................................................................................................................. 91
+6.6 Protection of the TSF .................................................................................................................. 92
+6.7 TOE access ................................................................................................................................... 98
+6.8 Trusted path/channels ................................................................................................................ 99
+6.9 Live Cycle ................................................................................................................................... 100
+
+
+2 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+## List of Tables
+
+
+Table 1 - TOE Common Attributes ................................................................................................................ 6
+Table 2 - Evaluated Devices .......................................................................................................................... 7
+Table 3 - Technical Decisions ...................................................................................................................... 13
+Table 4 - PP_MDF_V3.3 Extended Components ......................................................................................... 17
+Table 5 - MOD_BT_V1.0 Extended Components ........................................................................................ 17
+Table 6 - MOD_WLANC_V1.0 Extended Components ................................................................................ 17
+Table 7 - MOD_BIO_V1.1 Extended Components ...................................................................................... 18
+Table 8 - PKG_TLS_V1.1 Extended Components......................................................................................... 18
+Table 9 - MOD_MDM_AGENT_V1.0 Extended Components ...................................................................... 18
+Table 10 - PP_MDF_V3.3 Extended Assurance Components ..................................................................... 18
+Table 11 - TOE Security Functional Components ........................................................................................ 22
+Table 12 - PP_MDF_V3.3 Audit Events ....................................................................................................... 24
+Table 13 - MOD_BT_V1.0 Audit Events ...................................................................................................... 25
+Table 14 - MOD_WLANC_V1.0 Audit Events .............................................................................................. 26
+Table 15 - MOD_MDM_AGENT_V1.0 Audit Events .................................................................................... 27
+Table 16 - Security Management Functions ............................................................................................... 53
+Table 17 - Bluetooth Security Management Functions .............................................................................. 53
+Table 18 - WLAN Security Management Functions .................................................................................... 54
+Table 19 - Assurance Components ............................................................................................................. 61
+Table 20 - Audit Event Table References .................................................................................................... 67
+Table 21 - Asymmetric Key Generation ...................................................................................................... 68
+Table 22 - Wi-Fi Alliance Certificates .......................................................................................................... 69
+Table 23 - Salt Nonces ................................................................................................................................. 71
+Table 24 - BoringSSL Cryptographic Algorithms ......................................................................................... 72
+Table 25 - LockSettings Service KDF Cryptographic Algorithms ................................................................. 72
+Table 26 - Titan Security Chipsets ............................................................................................................... 72
+Table 27 - Titan M2 with v1.5.1 Firmware Cryptographic Algorithms ........................................................ 73
+Table 28 - Titan M2 with v1.3.10 Firmware Cryptographic Algorithms ...................................................... 73
+Table 29 - Titan M2 with v1.2.10 Firmware Cryptographic Algorithms ...................................................... 73
+Table 30 - Wi-Fi Chipsets ............................................................................................................................. 74
+Table 31 - Google Tensor G4 Hardware Cryptographic Algorithms ........................................................... 74
+Table 32 - Google Tensor G3 Hardware Cryptographic Algorithms ........................................................... 74
+Table 33 - Google Tensor G2 Hardware Cryptographic Algorithms ........................................................... 75
+Table 34 - Google Tensor Hardware Cryptographic Algorithms ................................................................. 75
+Table 35 - Functional Categories ................................................................................................................. 82
+Table 36 - Supported Biometric Modalities ................................................................................................ 85
+Table 37 - Fingerprint False Accept/Reject Rates ....................................................................................... 87
+Table 38 - Power-up Cryptographic Algorithm Known Answer Tests ......................................................... 97
+
+
+3 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+Table 39 - Security Update Period ............................................................................................................ 100
+
+## List of Figures
+
+
+Figure 1 - Password Conditioning ............................................................................................................... 76
+
+
+4 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+## 1 Security Target Introduction
+
+
+This section identifies the Security Target (ST) and Target of Evaluation (TOE) identification, ST
+conventions, ST conformance claims, and the ST organization. The TOE consists of the Pixel Devices on
+Android 15 provided by Google LLC. The TOE is being evaluated as a Mobile Device.
+
+
+The Security Target contains the following additional sections:
+
+ - Conformance Claims (Section 2)
+
+ - Security Objectives (Section 3)
+
+ - Extended Components Definition (Section 4)
+
+ - Security Requirements (Section 5)
+
+ - TOE Summary Specification (Section 6)
+
+
+_**Acronyms and Terminology**_
+
+
+AA Assurance Activity
+
+
+BAF Biometric Authentication Factor
+
+
+CC Common Criteria
+
+
+CCEVS Common Criteria Evaluation and Validation Scheme
+
+
+MDM Mobile Device Management
+
+
+NFC Near Field Communication
+
+
+PBFPS Power-Button Fingerprint Sensor
+
+
+PP Protection Profile
+
+
+SAR Security Assurance Requirement
+
+
+SEE Separate Execution Environment
+
+
+SFR Security Functional Requirement
+
+
+ST Security Target
+
+
+TEE Trusted Execution Environment
+
+
+TOE Target of Evaluation
+
+
+UDFPS Under-Display Fingerprint Sensor
+
+
+UI User Interface
+
+
+_**Conventions**_
+
+
+The following conventions have been applied in this document:
+
+ - Security Functional Requirements โ Part 2 of the CC defines the approved set of operations that
+may be applied to functional requirements: iteration, assignment, selection, and refinement.
+
+
+5 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+`o` Iteration: allows a component to be used more than once with varying operations. In
+
+the ST, iteration is indicated by a parenthetical number placed at the end of the
+component. For example FDP_ACC.1(1) and FDP_ACC.1(2) indicate that the ST includes
+two iterations of the FDP_ACC.1 requirement.
+
+`o` Assignment: allows the specification of an identified parameter. Assignments are
+
+indicated using bold and are surrounded by brackets (e.g., [ **assignment** ]). Note that an
+assignment within a selection would be identified in italics and with embedded bold
+brackets (e.g., [ _**[selected-assignment]**_ ]).
+
+`o` Selection: allows the specification of one or more elements from a list. Selections are
+
+indicated using bold italics and are surrounded by brackets (e.g., [ _**selection**_ ]).
+
+`o` Refinement: allows the addition of details. Refinements are indicated using bold, for
+
+additions, and strike-through, for deletions (e.g., โโฆ all objects โฆโ or โโฆ some big things
+โฆโ).
+
+ - Other sections of the ST โ Other sections of the ST use bolding to highlight text of special
+interest, such as captions.
+
+### 1.1 Security Target Reference
+
+
+**ST Title** Google Pixel Devices on Android 15 โ Security Target
+**ST Version** 1.0
+**ST Date** April 4, 2025
+
+### 1.2 TOE Reference
+
+
+**TOE Identification** Google Pixel Devices on Android 15
+**TOE Developer** Google LLC
+**Evaluation Sponsor** Google LLC
+
+### 1.3 TOE Overview
+
+
+The Target of Evaluation (TOE) is Google Pixel Devices on Android 15. All the included phones have the
+following information in common:
+
+|Android OS Version|Device Policy Version|Architecture|Security Patch Level|
+|---|---|---|---|
+|Android 15|128|ARMv8|December 2024|
+
+
+
+_**Table 1 - TOE Common Attributes**_
+
+
+The TOE consists of the following devices:
+
+|Google Product|Col2|Model #|SoC|Kernel|
+|---|---|---|---|---|
+|Pixel 9 Pro XL|GZC4K, GQ57S, GGX8B|GZC4K, GQ57S, GGX8B|Google Tensor G4|6.1|
+|Pixel 9 Pro|GEC77, GWVK6, GR83Y|GEC77, GWVK6, GR83Y|Google Tensor G4|6.1|
+|Pixel 9|GUR25, G1B60, G2YBB|GUR25, G1B60, G2YBB|Google Tensor G4|6.1|
+|Pixel 9 Pro Fold|GGH2X, GC15S|GGH2X, GC15S|Google Tensor G4|6.1|
+|Pixel 9a|GXQ96, GTF7P, G3Y12|GXQ96, GTF7P, G3Y12|Google Tensor G4|6.1|
+|Pixel 8 Pro|G1NMW, GC3VE|G1NMW, GC3VE|Google Tensor G3|6.1|
+
+
+
+6 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+|Google Product|Col2|Model #|SoC|Kernel|
+|---|---|---|---|---|
+|Pixel 8|GKWS6, G9BQD|GKWS6, G9BQD|Google Tensor G3|6.1|
+|Pixel 8a|G5760D, G6GPR, G8HHN|G5760D, G6GPR, G8HHN|Google Tensor G3|6.1|
+|Pixel Tablet|GTU8P|GTU8P|Google Tensor G2|6.1|
+|Pixel Fold|G9FPL, G0B96|G9FPL, G0B96|Google Tensor G2|6.1|
+|Pixel 7 Pro|GVU6C, G03Z5, GQML3|GVU6C, G03Z5, GQML3|Google Tensor G2|6.1|
+|Pixel 7|GE2AE, GFE4J, GP4BC|GE2AE, GFE4J, GP4BC|Google Tensor G2|6.1|
+|Pixel 7a|GWKK3, GHL1X, G82U8,
G0DZQ|GWKK3, GHL1X, G82U8,
G0DZQ|Google Tensor G2|6.1|
+|Pixel 6 Pro|GF5KQ, G8V0U, GLU0G|GF5KQ, G8V0U, GLU0G|Google Tensor|6.1|
+|Pixel 6|GR1YH, GB7N6, G9S9B|GR1YH, GB7N6, G9S9B|Google Tensor|6.1|
+|Pixel 6a|GX7AS, GB62Z, G1AZG, GB17L|GX7AS, GB62Z, G1AZG, GB17L|Google Tensor|6.1|
+
+
+
+_**Table 2 - Evaluated Devices**_
+
+
+Google manufacturers some of the phones in multiple variants, differing in size (the designations vary,
+from the โbaseโ device not having any, and other models having something like โaโ or โProโ) or build
+materials (entry and premium). The only differences between variants of a given device are build
+materials, screen type and size, battery capacity, cameras, RAM and Flash storage. The Pro phones are
+normally physically larger and have larger screen sizes, battery capacity and possibly RAM, while the โaโ
+phones may have a smaller screen or different build materials. Storage options vary with each release
+and may be selectable by the customer of the device at purchase.
+
+
+The TOE allows basic telephony features (make and receive phone calls, send and receive SMS/MMS
+messages) as well as advanced network connectivity (allowing connections to both 802.11 Wi-Fi and
+5G/4G LTE/3G/2G mobile data networks). The TOE supports using client certificates to connect to access
+points offering WPA2/WPA3 networks with 802.1x/EAP-TLS, or alternatively connecting to cellular base
+stations when utilizing mobile data.
+
+
+The TOE offers mobile applications an Application Programming Interface (API) including that provided
+by the Android framework and supports API calls to the Android Management APIs.
+
+### 1.4 TOE Description
+
+
+The TOE is a mobile device to support enterprises and individual users alike.
+
+
+Some features and settings must be enabled for the TOE to operate in its evaluated configuration. The
+following features and settings must be enabled:
+
+
+1. Enable a password screen lock
+2. Do not use Smart Lock
+3. Enable encryption of Wi-Fi and Bluetooth secrets (NIAP mode DPM API)
+4. Do not use USB debugging
+5. Do not allow installation of applications from unknown sources
+6. Enable security logging
+7. Disable โUsage & Diagnosticโ settings
+8. Disable Captive Portal Checking
+9. Loaded applications must be implemented utilizing the NIAPSEC library
+
+
+7 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+Doing this ensures that the phone complies with the PP_MDF_V3.3 requirements. Please refer to the
+Admin Guide on how to configure these settings and features.
+
+
+1.4.1 TOE Architecture
+
+
+The TOE provides a rich API to mobile applications and provides users installing an application the
+option to either approve or reject an application based upon the API access that the application requires
+(or to grant applications access at runtime).
+
+
+The TOE also provides users with the ability to protect Data-At-Rest with AES encryption, including all
+user and mobile application data stored in the userโs data partition. The TOE uses a key hierarchy that
+combines a REK with the userโs password to provide protection to all user and application cryptographic
+keys stored in the TOE.
+
+
+The TOE includes an additional hardware security chip (the Titan M2) that provides dedicated key
+storage [1] . The TOE makes this secure, hardware key storage available to mobile applications through the
+StrongBox extensions to the Android Keystore. Currently, the StrongBox extension is not used for any
+system keys, but remains an option for applications to use should they desire the protections it
+provides.
+
+
+Finally, the TOE can interact with a Mobile Device Management (MDM) system to allow enterprise
+control of the configuration and operation of the device so as to ensure adherence to enterprise-wide
+policies (for example, restricting use of a corporate provided deviceโs camera, forced configuration of
+maximum login attempts, pulling of audit logs off the TOE, etc.) as well as policies governing enterprise
+applications and data. An MDM is made up of two parts: the MDM Agent and MDM Server. The MDM
+Agent is installed on the phone as an administrator with elevated permissions (allowing it to change the
+relevant settings on the phone) while the MDM Server is used to issue the commands to the MDM
+Agent. The TOE includes an MDM Agent as part of the evaluated configuration. A user may choose to
+install a third party MDM Agent, which is out-of-scope for this evaluation.
+
+
+The TOE includes several different levels of execution including (from lowest to highest): hardware, a
+Trusted Execution Environment, Androidโs bootloader, and Androidโs user space, which provides APIs
+allowing applications to leverage the cryptographic functionality of the device.
+
+
+_1.4.1.1_ _Physical Boundaries_
+
+
+The TOEโs physical boundary is the physical perimeter of its enclosure. The TOE runs Android as its
+software/OS, executing on the Google Tensor processors. The TOE does not include the user
+applications that run on top of the operating system, but does include controls that limit application
+behavior. Further, the device provides a built-in MDM Agent (downloadable MDM Agents are not
+considered in-scope) to be installed to limit or permit different functionality of the device.
+
+
+The TOE communicates and interacts with 802.11-2012 Access Points and mobile data networks to
+establish network connectivity, and through that connectivity interacts with MDM servers that allow
+administrative control of the TOE.
+
+
+1 Does not apply to the Pixel 6 Pro/6/6a
+
+8 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+_1.4.1.2_ _Logical Boundaries_
+
+
+This section summarizes the security functions provided by the Pixel phones:
+
+
+- Security audit
+
+
+- Cryptographic support
+
+
+- User data protection
+
+
+- Identification and authentication
+
+
+- Security management
+
+
+- Protection of the TSF
+
+
+- TOE access
+
+
+- Trusted path/channels
+
+
+_1.4.1.2.1_ _Security audit_
+
+
+The TOE implements the SecurityLog and logcat that are stored in a circular memory buffers. An MDM
+agent can read/fetch the logs (both the SecurityLog and logcat) and then handle appropriately
+(potentially storing the log to Flash or transmitting its contents to the MDM server). These log methods
+meet the logging requirements outlined by FAU_GEN.1 in PP_MDF_V3.3. Please see the Security audit
+section for further information and specifics.
+
+
+_1.4.1.2.2_ _Cryptographic support_
+
+
+The TOE includes multiple cryptographic libraries with CAVP 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,
+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 allowing application developers to ensure their application meets the
+required criteria to remain compliant to PP_MDF_V3.3 standards.
+
+
+_1.4.1.2.3_ _User data protection_
+
+
+The 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 TOEโs evaluated configuration
+supports Android Enterprise profiles to provide additional separation between application and
+application data belonging to the Enterprise profile. Please see the Admin Guide for additional details
+regarding how to set up and use Enterprise profiles.
+
+
+9 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+_1.4.1.2.4_ _Identification and authentication_
+
+
+The TOE supports a number of features related to identification and authentication. From a user
+perspective, except for FCC mandated (making phone calls to an emergency number) or non-sensitive
+functions (e.g., choosing the keyboard input method or taking screen shots), a password (i.e., Password
+Authentication Factor) must be correctly entered to unlock the TOE. Also, even when unlocked, the TOE
+requires the user re-enter the password to change the password. 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 up to 16 characters are supported. The TOE can also be configured to utilize a biometric
+authentication factor (fingerprints), to unlock the device (this only works after the password has been
+entered after the device powers on).
+
+
+The TOE can also serve as an 802.1X supplicant and can both use and validate X.509v3 certificates for
+EAP-TLS, TLS, and HTTPS exchanges.
+
+
+_1.4.1.2.5_ _Security 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 will remove Enterprise applications and remove MDM policies.
+
+
+_1.4.1.2.6_ _Protection of the TSF_
+
+
+The 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 through the use of the application processorโs hardware. The TOE disallows all
+read access to the Root Encryption Key (REK) and retains all keys derived from the REK within its Trusted
+Execution Environment (TEE). Application software can only use keys derived from the REK by reference
+and receive the result. The TEE is a Separate Execution Environment (SEE), running outside the Android
+operating system on the device.
+
+
+The TOE 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 to isolate the
+address spaces of applications from one another to protect those applications.
+
+
+The 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 as all applications must have signatures (even if self-signed).
+
+
+10 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+_1.4.1.2.7_ _TOE 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 administrator specified (using the TOEโs MDM API) advisory
+message (banner) when the user unlocks the TOE for the first use after reboot.
+
+
+The TOE is also able to attempt to connect to wireless networks as configured.
+
+
+_1.4.1.2.8_ _Trusted path/channels_
+
+
+The TOE supports the use of IEEE 802.11-2012, 802.1X, and EAP-TLS and TLS, HTTPS to secure
+communications channels between itself and other trusted network devices.
+
+
+1.4.2 TOE Documentation
+
+
+Google Pixel Phones on Android 15 Administrator Guidance Documentation, Version 1.0, April 4, 2025
+
+**[Admin Guide]**
+
+
+11 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+## 2 Conformance Claims
+
+
+This TOE is conformant to the following CC specifications:
+
+ - Common Criteria for Information Technology Security Evaluation Part 2: Security functional
+components, Version 3.1, Revision 5, April 2017.
+
+`o` Part 2 Extended
+
+ - Common Criteria for Information Technology Security Evaluation Part 3: Security assurance
+components, Version 3.1, Revision 5, April 2017.
+
+`o` Part 3 Extended
+
+ - PP-Configuration for Mobile Device Fundamentals, Biometric enrolment and verification โ for
+unlocking the device, Bluetooth, MDM Agents, and WLAN Clients, Version 1.0, 16 August 2023
+(CFG_MDF-BIO-BT-MDMA-WLANC_V1.0)
+
+`o` The PP-Configuration includes the following components:
+
+ - Base-PP: Protection Profile for Mobile Device Fundamentals, Version 3.3, 12
+September 2022 (PP_MDF_V3.3)
+
+ - PP-Module: collaborative PP-Module for Biometric enrolment and verification for unlocking the device - [BIOPP-Module], Version 1.1, September 12, 2022
+(MOD_BIO_V1.1)
+
+ - PP-Module: PP-Module for Bluetooth, Version 1.0, 15 April 2021
+(MOD_BT_V1.0)
+
+ - PP-Module: PP-Module for MDM Agents, Version 1.0, 25 April 2019
+(MOD_MDM_AGENT_V1.0)
+
+ - PP-Module: PP-Module for WLAN Clients, Version 1.0, 31 March 2022
+(MOD_WLANC_V1.0)
+
+ - Package Claims:
+
+`o` Functional Package for Transport Layer Security (TLS), Version 1.1, 1 March 2019
+
+(PKG_TLS_V1.1)
+
+ - Technical Decisions as of March 11, 2025:
+
+|TD Number|Applied|Rationale|
+|---|---|---|
+|TD0442 โ PKG_TLS_V1.1|Yes||
+|TD0469 โ PKG_TLS_V1.1|No|Product does not have a TLS server|
+|TD0497 โ MOD_MDM_AGENT_V1.0|Yes||
+|TD0499 โ PKG_TLS_V1.1|Yes||
+|TD0513 โ PKG_TLS_V1.1|Yes||
+|TD0600 โ MOD_BT_V1.0 &
MOD_MDM_AGENT_V1.0|No|Using later PP-Configuration|
+|TD0640 โ MOD_BT_V1.0|Yes||
+|TD0645 โ MOD_BT_V1.0|Yes||
+|TD0650 โ MOD_BT_V1.0 &
MOD_MDM_AGENT_V1.0|Yes||
+|TD0660 โ MOD_MDM_AGENT_V1.0|Yes||
+
+
+
+12 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+|TD Number|Applied|Rationale|
+|---|---|---|
+|TD0667 โ MOD_WLANC_V1.0|Yes||
+|TD0671 โ MOD_BT_V1.0|Yes||
+|TD0673 โ MOD_MDM_AGENT_V1.0|Yes||
+|TD0677 โ PP_MDF_V3.3|Yes||
+|TD0685 โ MOD_BT_V1.0|Yes||
+|TD0689 โ PP_MDF_V3.3|Yes||
+|TD0700 โ MOD_BIO_V1.1|Yes||
+|TD0703 โ MOD_WLANC_V1.0|Yes||
+|TD0704 โ PP_MDF_V3.3|Yes||
+|TD0707 โ MOD_BT_V1.0|Yes||
+|TD0710 โ MOD_WLANC_V1.0|Yes||
+|TD0714 โ MOD_BIO_V1.1|Yes||
+|TD0724 โ PP_MDF_V3.3|Yes||
+|TD0726 โ PKG_TLS_V1.1|No|Product does not have a TLS server|
+|TD0739 โ PKG_TLS_V1.1|Yes||
+|TD0755 โ MOD_MDM_AGENT_V1.0|Yes||
+|TD0770 โ PKG_TLS_V1.1|No|Product does not have a TLS Server|
+|TD0779 โ PKG_TLS_V1.1|No|Product does not have a TLS Server|
+|TD0797 โ MOD_WLANC_V1.0|Yes||
+|TD0837 โ MOD_WLANC_V1.0|Yes||
+|TD0844 โ PP_MDF_V3.3|Yes||
+|TD0871 โ PP_MDF_V3.3|Yes||
+|TD0892 โ MOD_BIO_V1.1|Yes||
+
+
+
+_**Table 3 - Technical Decisions**_
+
+### 2.1 Conformance Rationale
+
+
+The ST conforms to
+PP_MDF_V3.3/MOD_BT_V1.0/MOD_WLANC_V1.0/MOD_BIO_V1.1/PKG_TLS_V1.1/MOD_MDM_AGENT
+_V1.0. For simplicity, this shall be referenced as MDF/BT/WLANC/BIO/TLS/MDMA. As explained
+previously, the security problem definition, security objectives, and security requirements have been
+drawn from the PP.
+
+
+The ST claims conformance with the following Use Cases in the PP_MDF_V3.3:
+
+ - USE CASE 1 with the following exceptions:
+
+`o` For FCS_STC_EXT.1.2, โthe userโ is selected as Android will provide separate storage
+
+between the enterprise and personal space via the work profile, so โthe userโ can
+manage keys for the personal space while only the administrator can manage keys in
+the work profile
+
+`o` FPT_TUD_EXT.5 is not applicable for Android as applications are not signed in this
+
+manner
+
+ - USE CASE 2 with no exceptions
+
+
+13 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+## 3 Security Objectives
+
+
+The Security Problem Definition may be found in the MDF/BT/WLANC/BIO/TLS/MDMA and this section
+reproduces only the corresponding Security Objectives for operational environment for reader
+convenience. The MDF/BT/WLANC/BIO/TLS/MDMA offers additional information about the identified
+security objectives, but that has not been reproduced here and the MDF/BT/WLANC/BIO/TLS/MDMA
+should be consulted if there is interest in that material.
+
+
+In general, the MDF/BT/WLANC/BIO/TLS/MDMA has defined Security Objectives appropriate for mobile
+device and as such are applicable to the Google Pixel Devices on Android 15 TOE.
+
+### 3.1 Security Objectives for the Operational Environment
+
+
+**PP_MDF_V3.3**
+**OE.CONFIG** TOE administrators will configure the Mobile Device security functions correctly to create
+the intended security policy.
+
+
+**OE.NOTIFY** The Mobile User will immediately notify the administrator if the Mobile Device is lost or
+stolen.
+
+
+**OE.PRECAUTION** The Mobile User exercises precautions to reduce the risk of loss or theft of the Mobile
+Device.
+
+
+**OE.DATA_PROPER_USER** Administrators take measures to ensure that mobile device users are
+adequately vetted against malicious intent and are made aware of the expectations for appropriate use
+of the device.
+
+
+**MOD_WLANC_V1.0**
+**OE.NO_TOE_BYPASS** Information cannot flow between external and internal networks located in
+different enclaves without passing through the TOE.
+
+
+**OE.TRUSTED_ADMIN** TOE Administrators are trusted to follow and apply all administrator guidance in a
+trusted manner.
+
+
+**MOD_BIO_V1.1**
+**OE.Protection** The TOE environment shall provide the SEE to protect the TOE, the TOE configuration and
+biometric data during runtime and storage.
+
+
+**MOD_MDM_AGENT_V1.0**
+**OE.DATA_PROPER_ADMIN** TOE Administrators are trusted to follow and apply all administrator
+guidance in a trusted manner.
+
+
+**OE.DATA_PROPER_USER** Users of the mobile device are trained to securely use the mobile device and
+apply all guidance in a trusted manner.
+
+
+**OE.IT_ENTERPRISE** The Enterprise IT infrastructure provides security for a network that is available to
+the TOE and mobile devices that prevents unauthorized access.
+
+
+**OE.MOBILE_DEVICE_PLATFORM** The MDM Agent relies upon the trustworthy mobile platform and
+hardware to provide policy enforcement as well as cryptographic services and data protection. The
+mobile platform provides trusted updates and software integrity verification of the MDM Agent.
+
+
+14 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+**OE.WIRELESS_NETWORK** A wireless network will be available to the mobile devices.
+
+
+15 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+## 4 Extended Components Definition
+
+
+All of the extended requirements in this ST are drawn from the MDF/BT/WLANC/BIO/TLS/MDMA. The
+MDF/BT/WLANC/BIO/TLS/MDMA defines the following extended requirements and since they are not
+redefined in this ST, the MDF/BT/WLANC/BIO/TLS/MDMA should be consulted for more information
+about those CC extensions.
+
+|Extended SFR|Name|
+|---|---|
+|FCS_CKM_EXT.1|Cryptographic Key Support|
+|FCS_CKM_EXT.2|Cryptographic Key Random Generation|
+|FCS_CKM_EXT.3|Cryptographic Key Generation|
+|FCS_CKM_EXT.4|Key Destruction|
+|FCS_CKM_EXT.5|TSF Wipe|
+|FCS_CKM_EXT.6|Salt Generation|
+|FCS_HTTPS_EXT.1|HTTPS Protocol|
+|FCS_IV_EXT.1|Initialization Vector Generation|
+|FCS_RBG_EXT.1|Random Bit Generation|
+|FCS_SRV_EXT.1|Cryptographic Algorithm Services|
+|FCS_SRV_EXT.2|Cryptographic Algorithm Services|
+|FCS_STG_EXT.1|Cryptographic Key Storage|
+|FCS_STG_EXT.2|Encrypted Cryptographic Key Storage|
+|FCS_STG_EXT.3|Integrity of Encrypted Key Storage|
+|FDP_ACF_EXT.1|Security Access Control for System Services|
+|FDP_ACF_EXT.2|Security Access Control for System Resources|
+|FDP_DAR_EXT.1|Protected Data Encryption|
+|FDP_DAR_EXT.2|Sensitive Data Encryption|
+|FDP_IFC_EXT.1|Subset Information Flow Control|
+|FDP_STG_EXT.1|User Data Storage|
+|FDP_UPC_EXT.1/APPS|Inter-TSF User Data Transfer Protection (Applications)|
+|FDP_UPC_EXT.1/BLUETOOTH|Inter-TSF User Data Transfer Protection (Bluetooth)|
+|FIA_AFL_EXT.1|Authentication Failure Handling|
+|FIA_PMG_EXT.1|Password Management|
+|FIA_TRT_EXT.1|Authentication Throttling|
+|FIA_UAU_EXT.1|Authentication for Cryptographic Operation|
+|FIA_UAU_EXT.2|Timing of Authentication|
+|FIA_X509_EXT.1|Validation of Certificates|
+|FIA_X509_EXT.2|X509 Certificate Authentication|
+|FIA_X509_EXT.3|Request Validation of Certificates|
+|FMT_MOF_EXT.1|Management of Security Functions Behavior|
+|FMT_SMF_EXT.2|Specification of Remediation Actions|
+|FMT_SMF_EXT.3|Current Administrator|
+|FPT_AEX_EXT.1|Application Address Space Layout Randomization|
+|FPT_AEX_EXT.2|Memory Page Permissions|
+|FPT_AEX_EXT.3|Stack Overflow Protection|
+|FPT_AEX_EXT.4|Domain Isolation|
+|FPT_AEX_EXT.5|Kernel Address Space Layout Randomization|
+|FPT_BBD_EXT.1|Application Processor Mediation|
+
+
+
+16 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+|Extended SFR|Name|
+|---|---|
+|FPT_JTA_EXT.1|JTAG Disablement|
+|FPT_KST_EXT.1|Key Storage|
+|FPT_KST_EXT.2|No Key Transmission|
+|FPT_KST_EXT.3|No Plaintext Key Export|
+|FPT_NOT_EXT.1|Self-Test Notification|
+|FPT_TST_EXT.1|TSF Cryptographic Functionality Testing|
+|FPT_TST_EXT.2/PREKERNEL|TSF Integrity Checking (Pre-Kernel)|
+|FPT_TST_EXT.2/POSTKERNEL|TSF Integrity Checking (Post-Kernel)|
+|FPT_TUD_EXT.1|Trusted Update: TSF Version Query|
+|FPT_TUD_EXT.2|TSF Update Verification|
+|FPT_TUD_EXT.3|Application Signing|
+|FPT_TUD_EXT.6|Trusted Update Verification|
+|FTA_SSL_EXT.1|TSF- and User-initiated Locked State|
+|FTP_ITC_EXT.1|Trusted Channel Communication|
+
+
+
+_**Table 4 - PP_MDF_V3.3 Extended Components**_
+
+|Extended SFR|Name|
+|---|---|
+|FCS_CKM_EXT.8|Bluetooth Key Generation|
+|FIA_BLT_EXT.1|Bluetooth User Authorization|
+|FIA_BLT_EXT.2|Bluetooth Mutual Authentication|
+|FIA_BLT_EXT.3|Rejection of Duplicate Bluetooth Connections|
+|FIA_BLT_EXT.4|Secure Simple Pairing|
+|FIA_BLT_EXT.6|Trusted Bluetooth User Authorization|
+|FIA_BLT_EXT.7|Untrusted Bluetooth User Authorization|
+|FMT_SMF.1 [modified]|Specification of Management Functions|
+|FMT_SMF_EXT.1/BT|Specification of Management Functions|
+|FTP_BLT_EXT.1|Bluetooth Encryption|
+|FTP_BLT_EXT.2|Persistence of Bluetooth Encryption|
+|FTP_BLT_EXT.3/BR|Bluetooth Encryption Parameters (BR/EDR)|
+|FTP_BLT_EXT.3/LE|Bluetooth Encryption Parameters (LE)|
+
+
+
+_**Table 5 - MOD_BT_V1.0 Extended Components**_
+
+|Extended SFR|Name|
+|---|---|
+|FCS_TLSC_EXT.1/WLAN|TLS Client Protocol (EAP-TLS for WLAN)|
+|FCS_TLSC_EXT.2/WLAN|TLS Client Support for Supported Groups Extension (EAP-TLS
for WLAN)|
+|FCS_WPA_EXT.1|Supported WPA Versions|
+|FIA_PAE_EXT.1|Port Access Entity Authentication|
+|FIA_X509_EXT.1/WLAN|X.509 Certificate Validation|
+|FIA_X509_EXT.2/WLAN|X.509 Certificate Authentication (EAP-TLS for WLAN)|
+|FIA_X509_EXT.6|X.509 Certificate Storage and Management|
+|FPT_TST_EXT.3/WLAN|TSF Cryptographic Functionality Testing (WLAN Client)|
+|FTA_WSE_EXT.1|Wireless Network Access|
+
+
+
+_**Table 6 - MOD_WLANC_V1.0 Extended Components**_
+
+|Extended SFR|Name|
+|---|---|
+|FIA_MBE_EXT.1|Biometric enrolment|
+|FIA_MBE_EXT.2|Quality of biometric templates for biometric enrolment|
+
+
+
+17 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+|Extended SFR|Name|
+|---|---|
+|FIA_MBV_EXT.1/PBFPS|Biometric verification|
+|FIA_MBV_EXT.1/UDFPS|Biometric verification|
+|FIA_MBV_EXT.1/USFPS|Biometric verification|
+|FIA_MBV_EXT.2|Quality of biometric samples for biometric verification|
+|FIA_MBV_EXT.3|Presentation attack detection for biometric verification|
+|FPT_BDP_EXT.1|Biometric data processing|
+|FPT_KST_EXT.1 [modified]|Key Storage|
+|FPT_KST_EXT.2 [modified]|No Key Transmission|
+|FPT_PBT_EXT.1|Protection of biometric template|
+
+
+
+_**Table 7 - MOD_BIO_V1.1 Extended Components**_
+
+|Extended SFR|Name|
+|---|---|
+|FCS_TLS_EXT.1|TLS Protocol|
+|FCS_TLSC_EXT.1|TLS Client Protocol|
+|FCS_TLSC_EXT.2|TLS Client Support for Mutual Authentication|
+|FCS_TLSC_EXT.4|TLS Client Support for Renegotiation|
+|FCS_TLSC_EXT.5|TLS Client Support for Supported Groups Extension|
+
+
+
+_**Table 8 - PKG_TLS_V1.1 Extended Components**_
+
+|Extended SFR|Name|
+|---|---|
+|FAU_ALT_EXT.2|Alert Agents|
+|FCS_STG_EXT.4|Cryptographic Key Storage|
+|FIA_ENR_EXT.2|Agent Enrollment of Mobile Device into Management|
+|FMT_POL_EXT.2|Agent Trusted Policy Update|
+|FMT_SMF_EXT.4|Specification of Management Functions|
+|FMT_UNR_EXT.1|User Unenrollment Prevention|
+|FTP_ITC_EXT.1(2)|Trusted Channel Communication|
+
+
+
+_**Table 9 - MOD_MDM_AGENT_V1.0 Extended Components**_
+
+|Extended SAR|Name|
+|---|---|
+|ALC_TSU_EXT.1|Timely Security Updates|
+
+
+
+_**Table 10 - PP_MDF_V3.3 Extended Assurance Components**_
+
+
+18 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+## 5 Security Requirements
+
+
+This section defines the Security Functional Requirements (SFRs) and Security Assurance Requirements
+(SARs) that serve to represent the security functional claims for the Target of Evaluation (TOE) and to
+scope the evaluation effort.
+
+
+The SFRs are from the MDF/BT/WLANC/BIO/TLS/MDMA documents. The refinements and operations
+already performed in the MDF/BT/WLANC/BIO/TLS/MDMA are not identified (e.g., highlighted) here,
+rather the requirements have been copied from the MDF/BT/WLANC/BIO/TLS/MDMA and any residual
+operations have been completed herein. Of particular note, the MDF/BT/WLANC/BIO/TLS/MDMA made
+a number of refinements and completed some of the SFR operations defined in the Common Criteria
+(CC) and that PP should be consulted to identify those changes if necessary.
+
+
+The SARs are from the MDF/BT/WLANC/BIO/TLS/MDMA documents, and includes all the relevant SARs.
+The SARs are effectively refined since requirement-specific 'Evaluation Activities' are defined in the
+MDF/BT/WLANC/BIO/TLS/MDMA that serve to ensure corresponding evaluations will yield more
+practical and consistent assurance. The MDF/BT/WLANC/BIO/TLS/MDMA should be consulted for the
+assurance activity definitions.
+
+### 5.1 TOE Security Functional Requirements
+
+
+The following table identifies the SFRs that are satisfied by Google Pixel Devices on Android 15 TOE.
+
+
+
+
+
+|Requirement Class|PP|Requirement Component|
+|---|---|---|
+|FAU: Security Audit|MOD_MDM_AGENT_V1.0|FAU_ALT_EXT.2 Alert Agents|
+|FAU: Security Audit|PP_MDF_V3.3|FAU_GEN.1 Audit Data Generation|
+|FAU: Security Audit|MOD_BT_V1.0|FAU_GEN.1/BT Audit Data Generation (Bluetooth)|
+|FAU: Security Audit|MOD_WLANC_V1.0|FAU_GEN.1/WLAN Audit Data Generation (Wireless LAN)|
+|FAU: Security Audit|MOD_MDM_AGENT_V1.0|FAU_GEN.1(2) Audit Data Generation|
+|FAU: Security Audit|PP_MDF_V3.3|FAU_SAR.1 Audit Review|
+|FAU: Security Audit|MOD_MDM_AGENT_V1.0|FAU_SEL.1(2) Security Audit Event Selection|
+|FAU: Security Audit|PP_MDF_V3.3|FAU_STG.4 Prevention of Audit Data Loss|
+|FAU: Security Audit|PP_MDF_V3.3|FAU_STG.1 Audit Storage Protection|
+|FCS: Cryptographic
Support|PP_MDF_V3.3|FCS_CKM.1 Cryptographic Key Generation|
+|FCS: Cryptographic
Support|MOD_WLANC_V1.0|FCS_CKM.1/WPA Cryptographic Key Generation
(Symmetric Keys for WPA2/WPA3 Connections)|
+|FCS: Cryptographic
Support|PP_MDF_V3.3|FCS_CKM.2/UNLOCKED Cryptographic Key Establishment|
+|FCS: Cryptographic
Support|PP_MDF_V3.3|FCS_CKM.2/LOCKED Cryptographic Key Establishment|
+|FCS: Cryptographic
Support|MOD_WLANC_V1.0|FCS_CKM.2/WLAN Cryptographic Key Distribution (Group
Temporal Key for WLAN)|
+|FCS: Cryptographic
Support|PP_MDF_V3.3|FCS_CKM_EXT.1 Cryptographic Key Support|
+|FCS: Cryptographic
Support|PP_MDF_V3.3|FCS_CKM_EXT.2 Cryptographic Key Random Generation|
+|FCS: Cryptographic
Support|PP_MDF_V3.3|FCS_CKM_EXT.3 Cryptographic Key Generation|
+|FCS: Cryptographic
Support|PP_MDF_V3.3|FCS_CKM_EXT.4 Key Destruction|
+|FCS: Cryptographic
Support|PP_MDF_V3.3|FCS_CKM_EXT.5 TSF Wipe|
+|FCS: Cryptographic
Support|PP_MDF_V3.3|FCS_CKM_EXT.6 Salt Generation|
+|FCS: Cryptographic
Support|MOD_BT_V1.0|FCS_CKM_EXT.8 Bluetooth Key Generation|
+|FCS: Cryptographic
Support|PP_MDF_V3.3|FCS_COP.1/ENCRYPT Cryptographic operation|
+
+
+19 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+
+
+
+|Requirement Class|PP|Requirement Component|
+|---|---|---|
+||PP_MDF_V3.3|FCS_COP.1/HASH Cryptographic operation|
+||PP_MDF_V3.3|FCS_COP.1/SIGN Cryptographic operation|
+||PP_MDF_V3.3|FCS_COP.1/KEYHMAC Cryptographic operation|
+||PP_MDF_V3.3|FCS_COP.1/CONDITION Cryptographic operation|
+||PP_MDF_V3.3|FCS_HTTPS_EXT.1 HTTPS Protocol|
+||PP_MDF_V3.3|FCS_IV_EXT.1 Initialization Vector Generation|
+||PP_MDF_V3.3|FCS_RBG_EXT.1 Random Bit Generation|
+||PP_MDF_V3.3|FCS_SRV_EXT.1 Cryptographic Algorithm Services|
+||PP_MDF_V3.3|FCS_SRV_EXT.2 Cryptographic Algorithm Services|
+||PP_MDF_V3.3|FCS_STG_EXT.1 Cryptographic Key Storage|
+||PP_MDF_V3.3|FCS_STG_EXT.2 Encrypted Cryptographic Key Storage|
+||PP_MDF_V3.3|FCS_STG_EXT.3 Integrity of Encrypted Key Storage|
+||MOD_MDM_AGENT_V1.0|FCS_STG_EXT.4 Cryptographic Key Storage|
+||PKG_TLS_V1.1|FCS_TLS_EXT.1 TLS Protocol|
+||PKG_TLS_V1.1|FCS_TLSC_EXT.1 TLS Client Protocol|
+||PKG_TLS_V1.1|FCS_TLSC_EXT.4 TLS Client Support for Renegotiation|
+||PKG_TLS_V1.1|FCS_TLSC_EXT.2 TLS Client Support for Mutual
Authentication|
+||PKG_TLS_V1.1|FCS_TLSC_EXT.5 TLS Client Support for Supported Groups
Extension|
+||MOD_WLANC_V1.0|FCS_TLSC_EXT.1/WLAN TLS Client Protocol (EAP-TLS for
WLAN)|
+||MOD_WLANC_V1.0|FCS_TLSC_EXT.2/WLAN TLS Client Support for Supported
Groups Extension (EAP-TLS for WLAN)|
+||MOD_WLANC_V1.0|FCS_WPA_EXT.1 Supported WPA Versions|
+|FDP: User Data
Protection|PP_MDF_V3.3|FDP_ACF_EXT.1 Security Access Control for System Services|
+|FDP: User Data
Protection|PP_MDF_V3.3|FDP_ACF_EXT.2 Security Access Control for System
Resources|
+|FDP: User Data
Protection|PP_MDF_V3.3|FDP_DAR_EXT.1 Protected Data Encryption|
+|FDP: User Data
Protection|PP_MDF_V3.3|FDP_DAR_EXT.2 Sensitive Data Encryption|
+|FDP: User Data
Protection|PP_MDF_V3.3|FDP_IFC_EXT.1 Subset Information Flow Control|
+|FDP: User Data
Protection|PP_MDF_V3.3|FDP_STG_EXT.1 User Data Storage|
+|FDP: User Data
Protection|PP_MDF_V3.3|FDP_UPC_EXT.1/APPS Inter-TSF User Data Transfer
Protection (Applications)|
+|FDP: User Data
Protection|PP_MDF_V3.3|FDP_UPC_EXT.1/BLUETOOTH Inter-TSF User Data Transfer
Protection (Bluetooth)|
+|FIA: Identification &
Authentication|PP_MDF_V3.3|FIA_AFL_EXT.1 Authentication Failure Handling|
+|FIA: Identification &
Authentication|MOD_BT_V1.0|FIA_BLT_EXT.1 Bluetooth User Authorization|
+|FIA: Identification &
Authentication|MOD_BT_V1.0|FIA_BLT_EXT.2 Bluetooth Mutual Authentication|
+|FIA: Identification &
Authentication|MOD_BT_V1.0|FIA_BLT_EXT.3 Rejection of Duplicate Bluetooth
Connections|
+|FIA: Identification &
Authentication|MOD_BT_V1.0|FIA_BLT_EXT.4 Secure Simple Pairing|
+|FIA: Identification &
Authentication|MOD_BT_V1.0|FIA_BLT_EXT.6 Trusted Bluetooth User Authorization|
+|FIA: Identification &
Authentication|MOD_BT_V1.0|FIA_BLT_EXT.7 Untrusted Bluetooth User Authorization|
+|FIA: Identification &
Authentication|MOD_MDM_AGENT_V1.0|FIA_ENR_EXT.2 Agent Enrollment of Mobile Device into
Management|
+|FIA: Identification &
Authentication|MOD_BIO_V1.1|FIA_MBE_EXT.1 Biometric enrolment|
+
+
+20 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+
+
+
+|Requirement Class|PP|Requirement Component|
+|---|---|---|
+||MOD_BIO_V1.1|FIA_MBE_EXT.2 Quality of biometric templates for
biometric enrolment|
+||MOD_BIO_V1.1|FIA_MBV_EXT.1/PBFPS Biometric verification|
+||MOD_BIO_V1.1|FIA_MBV_EXT.1/UDFPS Biometric verification|
+||MOD_BIO_V1.1|FIA_MBV_EXT.1/USFPS Biometric verification|
+||MOD_BIO_V1.1|FIA_MBV_EXT.2 Quality of biometric samples for biometric
verification|
+||MOD_BIO_V1.1|FIA_MBV_EXT.3 Presentation attack detection for
biometric verification|
+||MOD_WLANC_V1.0|FIA_PAE_EXT.1 Port Access Entity Authentication|
+||PP_MDF_V3.3|FIA_PMG_EXT.1 Password Management|
+||PP_MDF_V3.3|FIA_TRT_EXT.1 Authentication Throttling|
+||PP_MDF_V3.3|FIA_UAU.5 Multiple Authentication Mechanisms|
+||PP_MDF_V3.3|FIA_UAU.6/CREDENTIAL Re-Authentication (Credential
Change)|
+||PP_MDF_V3.3|FIA_UAU.6/LOCKED Re-Authentication (TSF Lock)|
+||PP_MDF_V3.3|FIA_UAU.7 Protected Authentication Feedback|
+||PP_MDF_V3.3|FIA_UAU_EXT.1 Authentication for Cryptographic
Operation|
+||PP_MDF_V3.3|FIA_UAU_EXT.2 Timing of Authentication|
+||PP_MDF_V3.3|FIA_X509_EXT.1 Validation of Certificates|
+||PP_MDF_V3.3|FIA_X509_EXT.3 Request Validation of Certificates|
+||PP_MDF_V3.3|FIA_X509_EXT.2 X509 Certificate Authentication|
+||MOD_WLANC_V1.0|FIA_X509_EXT.1/WLAN X.509 Certificate Validation|
+||MOD_WLANC_V1.0|FIA_X509_EXT.2/WLAN X.509 Certificate Authentication
(EAP-TLS for WLAN)|
+||MOD_WLANC_V1.0|FIA_X509_EXT.6 X.509 Certificate Storage and
Management|
+|FMT: Security
Management|PP_MDF_V3.3|FMT_MOF_EXT.1 Management of Security Functions
Behavior|
+|FMT: Security
Management|MOD_MDM_AGENT_V1.0|FMT_POL_EXT.2 Agent Trusted Policy Update|
+|FMT: Security
Management|PP_MDF_V3.3|FMT_SMF.1 Specification of Management Functions|
+|FMT: Security
Management|MOD_BT_V1.0|FMT_SMF_EXT.1/BT Specification of Management
Functions|
+|FMT: Security
Management|MOD_WLANC_V1.0|FMT_SMF.1/WLAN Specification of Management Functions
(WLAN Client)|
+|FMT: Security
Management|PP_MDF_V3.3|FMT_SMF_EXT.2 Specification of Remediation Actions|
+|FMT: Security
Management|PP_MDF_V3.3|FMT_SMF_EXT.3 Current Administrator|
+|FMT: Security
Management|MOD_MDM_AGENT_V1.0|FMT_SMF_EXT.4 Specification of Management Functions|
+|FMT: Security
Management|MOD_MDM_AGENT_V1.0|FMT_UNR_EXT.1 User Unenrollment Prevention|
+|FPT: Protection of
the TSF|PP_MDF_V3.3|FPT_AEX_EXT.1 Application Address Space Layout
Randomization|
+|FPT: Protection of
the TSF|PP_MDF_V3.3|FPT_AEX_EXT.2 Memory Page Permissions|
+|FPT: Protection of
the TSF|PP_MDF_V3.3|FPT_AEX_EXT.3 Stack Overflow Protection|
+|FPT: Protection of
the TSF|PP_MDF_V3.3|FPT_AEX_EXT.4 Domain Isolation|
+|FPT: Protection of
the TSF|PP_MDF_V3.3|FPT_AEX_EXT.5 Kernel Address Space Layout
Randomization|
+
+
+21 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+
+
+
+|Requirement Class|PP|Requirement Component|
+|---|---|---|
+||PP_MDF_V3.3|FPT_BBD_EXT.1 Application Processor Mediation|
+||MOD_BIO_V1.1|FPT_BDP_EXT.1 Biometric data processing|
+||PP_MDF_V3.3|FPT_JTA_EXT.1 JTAG Disablement|
+||PP_MDF_V3.3 &
MOD_BIO_V1.1|FPT_KST_EXT.1 Key Storage|
+||PP_MDF_V3.3 &
MOD_BIO_V1.1|FPT_KST_EXT.2 No Key Transmission|
+||PP_MDF_V3.3|FPT_KST_EXT.3 No Plaintext Key Export|
+||PP_MDF_V3.3|FPT_NOT_EXT.1 Self-Test Notification|
+||MOD_BIO_V1.1|FPT_PBT_EXT.1 Protection of biometric template|
+||PP_MDF_V3.3|FPT_STM.1 Reliable time stamps|
+||PP_MDF_V3.3|FPT_TST_EXT.1 TSF Cryptographic Functionality Testing|
+||PP_MDF_V3.3|FPT_TST_EXT.2/PREKERNEL TSF Integrity Checking (Pre-
Kernel)|
+||PP_MDF_V3.3|FPT_TST_EXT.2/POSTKERNEL TSF Integrity Checking (Post-
Kernel)|
+||MOD_WLANC_V1.0|FPT_TST_EXT.3/WLAN TSF Cryptographic Functionality
Testing (WLAN Client)|
+||PP_MDF_V3.3|FPT_TUD_EXT.1 Trusted Update: TSF Version Query|
+||PP_MDF_V3.3|FPT_TUD_EXT.2 TSF Update Verification|
+||PP_MDF_V3.3|FPT_TUD_EXT.3 Application Signing|
+||PP_MDF_V3.3|FPT_TUD_EXT.6 Trusted Update Verification|
+|FTA: TOE Access|PP_MDF_V3.3|FTA_SSL_EXT.1 TSF- and User-initiated Locked State|
+|FTA: TOE Access|PP_MDF_V3.3|FTA_TAB.1 Default TOE Access Banners|
+|FTA: TOE Access|MOD_WLANC_V1.0|FTA_WSE_EXT.1 Wireless Network Access|
+|FTP: Trusted
Path/Channels|MOD_BT_V1.0|FTP_BLT_EXT.1 Bluetooth Encryption|
+|FTP: Trusted
Path/Channels|MOD_BT_V1.0|FTP_BLT_EXT.2 Persistence of Bluetooth Encryption|
+|FTP: Trusted
Path/Channels|MOD_BT_V1.0|FTP_BLT_EXT.3/BR Bluetooth Encryption Parameters
(BR/EDR)|
+|FTP: Trusted
Path/Channels|MOD_BT_V1.0|FTP_BLT_EXT.3/LE Bluetooth Encryption Parameters (LE)|
+|FTP: Trusted
Path/Channels|MOD_WLANC_V1.0|FTP_ITC.1/WLAN Trusted Channel Communication
(Wireless LAN)|
+|FTP: Trusted
Path/Channels|PP_MDF_V3.3|FTP_ITC_EXT.1 Trusted Channel Communication|
+|FTP: Trusted
Path/Channels|MOD_MDM_AGENT_V1.0|FTP_ITC_EXT.1(2) Trusted Channel Communication|
+|FTP: Trusted
Path/Channels|MOD_MDM_AGENT_V1.0|FTP_TRP.1(2) Trusted Path (for Enrollment)|
+
+
+_**Table 11 - TOE Security Functional Components**_
+
+
+
+5.1.1 Security Audit (FAU)
+
+
+_5.1.1.1_ _MOD_MDM_AGENT_V1.0:FAU_ALT_EXT.2 Agent Alerts_
+
+
+**FAU_ALT_EXT.2.1**
+
+The MDM Agent shall provide an alert via the trusted channel to the MDM Server in the
+event of any of the following audit events:
+
+ - successful application of policies to a mobile device,
+
+ - [ _**receiving**_ ] periodic reachability events,
+
+
+22 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+ - [ _**no other events**_ ].
+**FAU_ALT_EXT.2.2**
+
+The MDM Agent shall queue alerts if the trusted channel is not available.
+
+
+_5.1.1.2_ _PP_MDF_V3.3:FAU_GEN.1 Audit Data Generation_
+
+
+**FAU_GEN.1.1**
+
+The TSF shall be able to generate an audit record of the following auditable events:
+1. Start-up and shutdown of the audit functions
+2. All auditable events for the [ _not selected_ ] level of audit
+_3._ [ _All administrative actions_
+_4._ _Start-up and shutdown of the OS_
+_5._ _Insertion or removal of removable media_
+_6._ _Specifically defined auditable events in Table 2 of the PP_MDF_V3.3_
+7. [ _**no additional auditable events**_ ]
+
+
+
+
+
+
+
+|Requirement|Audit Event|Content|
+|---|---|---|
+|FAU_GEN.1|Start-up and shutdown of the
audit functions||
+|FAU_GEN.1|All administrative actions||
+|FAU_GEN.1|Start-up and shutdown of the Rich
OS||
+|FAU_GEN.1|||
+|FAU_SAR.1|||
+|FAU_STG.1|||
+|FAU_STG.4|||
+|FCS_CKM.1|[**_None_**].||
+|FCS_CKM.2/UNLOCKED|||
+|FCS_CKM.2/LOCKED|||
+|FCS_CKM_EXT.1|[**_None_**]||
+|FCS_CKM_EXT.2|||
+|FCS_CKM_EXT.3|||
+|FCS_CKM_EXT.4|||
+|FCS_CKM_EXT.5|[**_None_**]||
+|FCS_CKM_EXT.6|||
+|FCS_COP.1/ENCRYPT|||
+|FCS_COP.1/HASH|||
+|FCS_COP.1/SIGN|||
+|FCS_COP.1/KEYHMAC|||
+|FCS_COP.1/CONDITION|||
+|FCS_IV_EXT.1|||
+|FCS_SRV_EXT.1|||
+|FCS_STG_EXT.1|Import or destruction of key.|Identity of key. Role and identity
of requestor.|
+|FCS_STG_EXT.1|[**_None_**]||
+|FCS_STG_EXT.2|||
+
+
+23 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+|Requirement|Audit Event|Content|
+|---|---|---|
+|FCS_STG_EXT.3|Failure to verify integrity of stored
key.|Identity of key being verified.|
+|FDP_ACF_EXT.1|||
+|FDP_DAR_EXT.1|[**_None_**]||
+|FDP_DAR_EXT.2|[**_None_**]||
+|FDP_IFC_EXT.1|||
+|FDP_STG_EXT.1|Addition or removal of certificate
from Trust Anchor Database.|Subject name of certificate.|
+|FIA_PMG_EXT.1|||
+|FIA_TRT_EXT.1|||
+|FIA_UAU.5|||
+|FIA_UAU.7|||
+|FIA_UAU_EXT.1|||
+|FIA_X509_EXT.1|Failure to validate X.509v3
certificate.|Reason for failure of validation.|
+|FIA_X509_EXT.2|||
+|FMT_MOF_EXT.1|||
+|FPT_AEX_EXT.1|||
+|FPT_AEX_EXT.2|||
+|FPT_AEX_EXT.3|||
+|FPT_JTA_EXT.1|||
+|FPT_KST_EXT.1|||
+|FPT_KST_EXT.2|||
+|FPT_KST_EXT.3|||
+|FPT_NOT_EXT.1|[**_None_**]|[**_No additional information_**]|
+|FPT_STM.1|||
+|FPT_TST_EXT.1|Initiation of self-test.||
+|FPT_TST_EXT.1|Failure of self-test.|[**_No additional information_**]|
+|FPT_TST_EXT.2/PREKERNEL|Start-up of TOE.||
+|FPT_TST_EXT.2/PREKERNEL|[**_None_**]|[**_No additional information_**]|
+|FPT_TUD_EXT.1|||
+|FTA_SSL_EXT.1|||
+|FTA_TAB.1|||
+
+
+
+_**Table 12 - PP_MDF_V3.3 Audit Events**_
+
+
+**FAU_GEN.1.2**
+
+The TSF shall record within each audit record at least the following information:
+1. Date and time of the event
+2. Type of event
+3. Subject identity
+4. The outcome (success or failure) of the event
+5. Additional information in Table 12 - PP_MDF_V3.3 Audit Events from Table 2 (of the
+
+PP_MDF_V3.3)
+6. [ _**no additional information**_ ]
+(TD0724 applied)
+
+
+24 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+_5.1.1.3_ _MOD_BT_V1.0:FAU_GEN.1/BT Audit Data Generation (Bluetooth)_
+
+
+**FAU_GEN.1.1/BT**
+
+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
+c. [ _Specifically defined auditable events in the Auditable Events table (of the_
+
+_MOD_BT_V1.0 shown in Table 13 - MOD_BT_V1.0 Audit Events)_ ]
+
+
+
+
+
+
+
+
+
+|Requirement|Audit Event|Content|
+|---|---|---|
+|FCS_CKM_EXT.8|||
+|FIA_BLT_EXT.1|Failed user authorization of
Bluetooth device.|User authorization decision (e.g.,
user rejected connection,
incorrect pin entry).|
+|FIA_BLT_EXT.1|Failed user authorization for local
Bluetooth Service.|[_last [2] octets of the_] BD_ADDR
and [**_no other information_**].
Bluetooth profile. Identity of local
service with [**_service ID_**].|
+|FIA_BLT_EXT.2|Initiation of Bluetooth connection.|[_last [2] octets of the_] BD_ADDR
and [**_no other information_**].|
+|FIA_BLT_EXT.2|Failure of Bluetooth connection.|Reason for failure.|
+|FIA_BLT_EXT.4|||
+|FIA_BLT_EXT.6|||
+|FIA_BLT_EXT.7|||
+|FTP_BLT_EXT.1|||
+|FTP_BLT_EXT.2|||
+|FTP_BLT_EXT.3/BR|||
+|FTP_BLT_EXT.3/LE|||
+
+
+_**Table 13 - MOD_BT_V1.0 Audit Events**_
+
+
+**FAU_GEN.1.2/BT**
+
+The TSF shall record within each audit record at least the following information:
+a. Date and time of the event
+b. Type of event
+c. Subject identity
+d. The outcome (success or failure) of the event
+e. For each audit event type, based on the auditable event definitions of the functional
+
+components included in the PP/ST, [ _Additional information in the Auditable Events_
+_table (of the MOD_BT_V1.0)_ ]
+(TD0707 & TD0645 applied)
+
+
+_5.1.1.4_ _MOD_WLANC_V1.0:FAU_GEN.1/WLAN Audit Data Generation (Wireless LAN)_
+
+
+**FAU_GEN.1.1/WLAN**
+
+The TSF shall [ _**invoke platform-provided functionality**_ ] to generate an audit record of
+the following auditable events:
+
+
+25 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+a. Startup and shutdown of the audit functions;
+b. All auditable events for the [ _not specified_ ] level of audit; and
+c. [ _all auditable events for mandatory SFRs specified in Table 2 and selected SFRs in_
+
+_Table 5 (of the MOD_WLANC_V1.0 shown in Table 14 - MOD_WLANC_V1.0 Audit_
+_Events)_ ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+|Requirement|Audit Event|Content|
+|---|---|---|
+|FAU_GEN.1/WLAN|||
+|FCS_CKM.1/WPA|||
+|FCS_CKM.2/WLAN|||
+|FCS_TLSC_EXT.1/WLAN|Failure to establish an EAP-TLS
session.|Reason for failure.
Non-TOE endpoint of connection.|
+|FCS_TLSC_EXT.1/WLAN|Establishment/termination of an
EAP-TLS session.|Non-TOE endpoint of connection.|
+|FCS_TLSC_EXT.2/WLAN|||
+|FCS_WPA_EXT.1|||
+|FIA_PAE_EXT.1|||
+|FIA_X509_EXT.1/WLAN|Failure to validate X.509v3
certificate.|Reason for failure of validation.|
+|FIA_X509_EXT.2/WLAN|||
+|FIA_X509_EXT.6|Attempts to load certificates.||
+|FIA_X509_EXT.6|Attempts to revoke certificates.||
+|FMT_SMF.1/WLAN|||
+|FPT_TST_EXT.3/WLAN|Execution of this set of TSF self-
tests.|(Done as part of FPT_TST_EXT.1)|
+|FPT_TST_EXT.3/WLAN|[**_None_**].|[**_None_**].|
+|FTA_WSE_EXT.1|All attempts to connect to access
points.|For each access point record the
[**_Complete SSID and MAC_**] of the
MAC Address
Success and failures (including
reason for failure).|
+|FTP_ITC.1/WLAN|All attempts to establish a trusted
channel.|Identification of the non-TOE
endpoint of the channel.|
+
+
+_**Table 14 - MOD_WLANC_V1.0 Audit Events**_
+
+
+**FAU_GEN.1.2/WLAN**
+
+The [ _**TOE Platform**_ ] shall record within each audit record at least the following
+information:
+a. Date and time of the event, type of event, subject identity, (if relevant) 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-Module/ST, [ _Additional Audit Record Contents as_
+_specified in Table 2 and Table 5 (of the MOD_WLANC_V1.0 shown in Table 14 -_
+_MOD_WLANC_V1.0 Audit Events)_ ]
+
+
+26 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+_5.1.1.5_ _MOD_MDM_AGENT_V1.0:FAU_GEN.1(2) Audit Data Generation (MDM Agent)_
+
+
+**FAU_GEN.1.1(2)**
+
+**Refinement:** The MDM Agent shall [ _**invoke platform-provided functionality**_ ] to
+generate an MDM Agent audit record of the following auditable events:
+a. Startup and shutdown of the MDM Agent;
+b. All auditable events for [ _not specified_ ] level of audit; and
+c. [ _MDM policy updated, any modification commanded by the MDM Server, specifically_
+
+_defined auditable events listed in Table 1 (of the MOD_MDM_AGENT_V1.0 shown in_
+_Table 15 - MOD_MDM_AGENT_V1.0 Audit Events, and [_ _**no other events**_ _]_ ].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+|Requirement|Auditable Events|Additional Audit Record Contents|
+|---|---|---|
+|FAU_ALT_EXT.2|Success/failure of sending alert.|No additional information.|
+|FAU_GEN.1(2)|None.|N/A|
+|FAU_SEL.1(2)|All modifications to the audit
configuration that occur while the
audit collection functions are
operating.|No additional information.|
+|FCS_STG_EXT.4/
FCS_STG_EXT.1(2)|None.||
+|FCS_TLSC_EXT.1|Failure to establish a TLS session.|Reason for failure.|
+|FCS_TLSC_EXT.1|Failure to verify presented
identifier.|Presented identifier and reference
identifier.|
+|FCS_TLSC_EXT.1|Establishment/termination of a
TLS session.|Non-TOE endpoint of connection.|
+|FIA_ENR_EXT.2|Enrollment in management.|Reference identifier of MDM
Server.|
+|FMT_POL_EXT.2|Failure of policy validation.|Reason for failure of validation.|
+|FMT_SMF_EXT.4|Outcome (Success/failure) of
function.|No additional information.|
+|FMT_UNR_EXT.1.1|[**_Attempt to unenroll_**]|No additional information.|
+|FTP_ITC_EXT.1(2)|Initiation and termination of
trusted channel.|Trusted channel protocol. Non-
TOE endpoint of connection.|
+
+
+_**Table 15 - MOD_MDM_AGENT_V1.0 Audit Events**_
+
+
+**FAU_GEN.1.2(2)**
+
+**Refinement:** The [ _**TOE platform**_ ] shall record within each MDM Agent audit record at
+least the following information:
+a. Date and time of the event, type of event, subject identity, (if relevant) the outcome
+
+(success or failure) of the event, and additional information in Table 1 ( _of the_
+_MOD_MDM_AGENT_V1.0 shown in Table 15 - MOD_MDM_AGENT_V1.0 Audit_
+_Events)_ ; and
+b. For each audit event type, based on the auditable event definitions of the functional
+
+components included in the PP-Module/ST, [ _no other information_ ].
+(TD0660 applied)
+
+
+27 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+_5.1.1.6_ _PP_MDF_V3.3:FAU_SAR.1 Audit Review_
+
+
+**FAU_SAR.1.1**
+
+The TSF shall provide [the administrator] with the capability to read [all audited events
+and record contents] from the audit records.
+**FAU_SAR.1.2**
+
+The TSF shall provide the audit records in a manner suitable for the user to interpret the
+information.
+
+
+_5.1.1.7_ _MOD_MDM_AGENT_V1.0:FAU_SEL.1(2) Security Audit Event Selection_
+
+
+**FAU_SEL.1.1(2)**
+
+**Refinement:** The TSF shall [ _**invoke platform-provided functionality**_ ] to select the set of
+events to be audited from the set of all auditable events based on the following
+attributes:
+a. [ _event type_ ]
+b. [ _success of auditable security events, failure of auditable security events, [no other_
+
+_attributes]_ ].
+
+
+_5.1.1.8_ _PP_MDF_V3.3:FAU_STG.1 Audit Storage Protection_
+
+
+**FAU_STG.1.1**
+
+The TSF shall protect the stored audit records in the audit trail from unauthorized
+deletion.
+**FAU_STG.1.2**
+
+The TSF shall be able to [prevent] unauthorized modifications to the stored audit
+records in the audit trail.
+
+
+_5.1.1.9_ _PP_MDF_V3.3:FAU_STG.4 Prevention of Audit Data Loss_
+
+
+**FAU_STG.4.1**
+
+The TSF shall [overwrite the oldest stored audit records] if the audit trail is full.
+
+
+5.1.2 Cryptographic Support (FCS)
+
+
+_5.1.2.1_ _PP_MDF_V3.3:FCS_CKM.1 Cryptographic Key Generation_
+
+
+**FCS_CKM.1.1**
+
+The TSF shall generate asymmetric cryptographic keys in accordance with a specified
+cryptographic key generation algorithm [
+
+ - _**RSA schemes using cryptographic key sizes of [2048, 3072 or 4096 bits] that meet**_
+
+_**[FIPS PUB 186-5, โDigital Signature Standard (DSS)โ, Appendix B.3],**_
+
+ - _**ECC schemes using [โNIST curvesโ P-384 and [P-256, P-521] that meet the**_
+_**following: [FIPS PUB 186-5, โDigital Signature Standard (DSS)โ, Appendix B.4]]**_
+].
+(TD0871 applied)
+
+
+28 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+_5.1.2.2_ _MOD_WLANC_V1.0:FCS_CKM.1/WPA Cryptographic Key Generation (Symmetric Keys_
+_for WPA2/WPA3 Connections)_
+
+
+**FCS_CKM.1.1/WPA**
+
+The TSF shall generate symmetric cryptographic keys in accordance with a specified
+cryptographic key generation algorithm [ _**PRF-384 and [PRF-512, PRF-704] (as defined in**_
+_**IEEE 802.11-2012)**_ ] and specified key sizes [ _**256 bits and [128 bits, 192 bits]**_ ] using a
+Random Bit Generator as specified in FCS_RBG_EXT.1.
+
+
+_5.1.2.3_ _PP_MDF_V3.3:FCS_CKM.2/UNLOCKED Cryptographic Key Establishment_
+
+
+**FCS_CKM.2.1/UNLOCKED**
+
+The TSF shall perform cryptographic key establishment in accordance with a specified
+cryptographic key establishment method [
+
+ - _**[RSA-based key establishment schemes] that meet the following [**_
+
+`o` _**NIST Special Publication 800-56B, โRecommendation for Pair-Wise Key**_
+
+_**Establishment Schemes Using Integer Factorization Cryptographyโ]**_
+
+ - _**[Elliptic curve-based key establishment schemes] that meet the following: [NIST**_
+_**Special Publication 800-56A Revision 3, โRecommendation for Pair-Wise Key**_
+_**Establishment Schemes Using Discrete Logarithm Cryptographyโ]**_
+].
+
+
+_5.1.2.4_ _PP_MDF_V3.3:FCS_CKM.2/LOCKED Cryptographic Key Establishment_
+
+
+**FCS_CKM.2.1/LOCKED**
+
+The TSF shall perform cryptographic key establishment in accordance with a specified
+cryptographic key establishment method: [
+
+ - _**[RSA-based key establishment schemes] that meet the following: [NIST Special**_
+_**Publication 800-56B, โRecommendation for Pair-Wise Key Establishment Schemes**_
+_**Using Integer Factorization Cryptographyโ]**_
+] for the purposes of encrypting sensitive data received while the device is locked.
+
+
+_5.1.2.5_ _MOD_WLANC_V1.0:FCS_CKM.2/WLAN Cryptographic Key Distribution (Group_
+_Temporal Key for WLAN)_
+
+
+**FCS_CKM.2.1/WLAN**
+
+
+The TSF shall decrypt Group Temporal Key in accordance with a specified cryptographic
+key distribution method [ _AES Key Wrap (as defined in RFC 3394) in an EAPOL-Key frame_
+_(as defined in IEEE 802.11-2012 for the packet format and timing considerations_ ] and
+does not expose the cryptographic keys.
+
+
+_5.1.2.6_ _PP_MDF_V3.3:FCS_CKM_EXT.1 Cryptographic Key Support_
+
+
+**FCS_CKM_EXT.1.1**
+
+The TSF shall support [ _**immutable hardware**_ ] REKs with a [ _**symmetric**_ ] key of strength
+
+[ _**256 bits**_ ].
+
+
+29 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+**FCS_CKM_EXT.1.2**
+
+Each REK shall be hardware-isolated from the OS on the TSF in runtime.
+**FCS_CKM_EXT.1.3**
+
+Each REK shall be generated by an RBG in accordance with FCS_RBG_EXT.1.
+
+
+_5.1.2.7_ _PP_MDF_V3.3:FCS_CKM_EXT.2 Cryptographic Key Random Generation_
+
+
+**FCS_CKM_EXT.2.1**
+
+All DEKs shall be [
+
+ - _**randomly generated**_
+] with entropy corresponding to the security strength of AES key sizes of [ _**256**_ ] bits.
+
+
+_5.1.2.8_ _PP_MDF_V3.3:FCS_CKM_EXT.3 Cryptographic Key Generation_
+
+
+**FCS_CKM_EXT.3.1**
+
+The TSF shall use [
+
+ - _**asymmetric KEKs of [128 bits] security strength,**_
+
+ - _**symmetric KEKs of [256-bit] security strength corresponding to at least the security**_
+_**strength of the keys encrypted by the KEK**_
+].
+**FCS_CKM_EXT.3.2**
+
+The TSF shall generate all KEKs using one of the following methods:
+
+ - Derive the KEK from a Password Authentication Factor according to
+FCS_COP.1.1/CONDITION and
+
+[
+
+ - _**Generate the KEK using an RBG that meets this profile (as specified in**_
+_**FCS_RBG_EXT.1)**_
+
+ - _**Generate the KEK using a key generation scheme that meets this profile (as**_
+_**specified in FCS_CKM.1)**_
+
+ - _**Combine the KEK from other KEKs in a way that preserves the effective entropy of**_
+_**each factor by [concatenating the keys and using a KDF (as described in SP 800-**_
+_**108), encrypting one key with another]**_
+].
+
+
+_5.1.2.9_ _PP_MDF_V3.3:FCS_CKM_EXT.4 Key Destruction_
+
+
+**FCS_CKM_EXT.4.1**
+
+The TSF shall destroy cryptographic keys in accordance with the specified cryptographic
+key destruction methods:
+
+ - by clearing the KEK encrypting the target key
+
+ - in accordance with the following rules
+
+`o` For volatile memory, the destruction shall be executed by a single direct
+
+overwrite [ _**consisting of zeroes**_ ].
+
+
+30 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+`o` For non-volatile EEPROM, the destruction shall be executed by a single direct
+
+overwrite consisting of a pseudo random pattern using the TSF's RBG (as
+specified in FCS_RBG_EXT.1), followed by a read-verify.
+
+`o` For non-volatile flash memory, that is not wear-leveled, the destruction shall be
+
+executed [ _**by a block erase that erases the reference to memory that stores**_
+_**data as well as the data itself**_ ].
+
+`o` For non-volatile flash memory, that is wear-leveled, the destruction shall be
+
+executed [ _**by a block erase**_ ].
+
+`o` For non-volatile memory other than EEPROM and flash, the destruction shall be
+
+executed by a single direct overwrite with a random pattern that is changed
+before each write.
+**FCS_CKM_EXT.4.2**
+
+The TSF shall destroy all plaintext keying material and critical security parameters when
+no longer needed.
+
+
+_5.1.2.10_ _PP_MDF_V3.3:FCS_CKM_EXT.5 TSF Wipe_
+
+
+**FCS_CKM_EXT.5.1**
+
+The TSF shall wipe all protected data by [
+
+ - _**Cryptographically erasing the encrypted DEKs or the KEKs in non-volatile memory**_
+_**by following the requirements in FCS_CKM_EXT.4.1**_
+
+ - _**Overwriting all PD according to the following rules:**_
+
+`o` _**For EEPROM, the destruction shall be executed by a single direct overwrite**_
+
+_**consisting of a pseudo random pattern using the TSF's RBG (as specified in**_
+_**FCS_RBG_EXT.1), followed by a read-verify.**_
+
+`o` _**For flash memory, that is not wear-leveled, the destruction shall be executed**_
+
+_**[by a block erase that erases the reference to memory that stores data as well**_
+_**as the data itself].**_
+
+`o` _**For flash memory, that is wear-leveled, the destruction shall be executed [by a**_
+
+_**block erase].**_
+
+`o` _**For non-volatile memory other than EEPROM and flash, the destruction shall**_
+
+_**be executed by a single direct overwrite with a random pattern that is**_
+_**changed before each write.**_ ].
+**FCS_CKM_EXT.5.2**
+
+The TSF shall perform a power cycle on conclusion of the wipe procedure.
+
+
+_5.1.2.11_ _PP_MDF_V3.3:FCS_CKM_EXT.6 Salt Generation_
+
+
+**FCS_CKM_EXT.6.1**
+
+The TSF shall generate all salts using an RBG that meets FCS_RBG_EXT.1.
+
+
+_5.1.2.12_ _MOD_BT_V1.0:FCS_CKM_EXT.8 Bluetooth Key Generation_
+
+
+**FCS_CKM_EXT.8.1**
+
+The TSF shall generate public/private ECDH key pairs every [ **time a connection between**
+**devices is established** ].
+
+
+31 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+_5.1.2.13_ _PP_MDF_V3.3:FCS_COP.1/ENCRYPT Cryptographic operation_
+
+
+**FCS_COP.1.1/ENCRYPT**
+
+The TSF shall perform [encryption/decryption] in accordance with a specified
+cryptographic algorithm:
+
+ - AES-CBC (as defined in FIPS PUB 197, and NIST SP 800-38A) mode
+
+ - AES-CCMP (as defined in FIPS PUB 197, NIST SP 800-38C and IEEE 802.11-2012), and
+
+ - [
+
+`o` _**AES Key Wrap (KW) (as defined in NIST SP 800-38F)**_
+
+`o` _**AES-GCM (as defined in NIST SP 800-38D)**_
+
+`o` _**AES-XTS (as defined in NIST SP 800-38E) mode**_
+
+`o` _**AES-GCMP-256 (as defined in NIST SP800-38D and IEEE 802.11ac-2013)**_
+]
+and cryptographic key sizes [128-bit key sizes and [ _**256-bit key sizes**_ ]].
+
+
+_5.1.2.14_ _PP_MDF_V3.3:FCS_COP.1/HASH Cryptographic operation_
+
+
+**FCS_COP.1.1/HASH**
+
+The TSF shall perform [cryptographic hashing] in accordance with a specified
+cryptographic algorithm [SHA-1 and [ _**SHA-256, SHA-384, SHA-512**_ ]] and message digest
+sizes [160 and [ _**256 bits, 384 bits, 512 bits**_ ]] that meet the following: [FIPS Pub 180-4].
+
+
+_5.1.2.15_ _PP_MDF_V3.3:FCS_COP.1/SIGN Cryptographic operation_
+
+
+**FCS_COP.1.1/SIGN**
+
+The TSF shall perform [cryptographic signature services (generation and verification)] in
+accordance with a specified cryptographic algorithm [
+
+ - _**[RSA schemes] using cryptographic key sizes of [2048-bit or greater] that meet the**_
+_**following: [FIPS PUB 186-5, โDigital Signature Standard (DSS)โ, Section 4]**_
+
+ - _**[ECDSA schemes] using [โNIST curvesโ P-384 and [P-256, P-521]] that meet the**_
+_**following: [FIPS PUB 186-5, โDigital Signature Standard (DSS)โ, Section 5]**_
+].
+(TD0871 applied)
+
+
+_5.1.2.16_ _PP_MDF_V3.3:FCS_COP.1/KEYHMAC Cryptographic operation_
+
+
+**FCS_COP.1.1/KEYHMAC**
+
+The TSF shall perform [keyed-hash message authentication] in accordance with a
+specified cryptographic algorithm [HMAC-SHA-1 and [ _**HMAC-SHA-256, HMAC-SHA-384,**_
+_**HMAC-SHA-512**_ ]] and cryptographic key sizes [ **160, 256, 384, 512** ] and message digest
+sizes 160 and [ _**256, 384, 512**_ ] bits that meet the following: [FIPS Pub 198-1, โThe KeyedHash Message Authentication Codeโ, and FIPS Pub 180-4, โSecure Hash Standardโ].
+
+
+_5.1.2.17_ _PP_MDF_V3.3:FCS_COP.1/CONDITION Cryptographic operation_
+
+
+**FCS_COP.1.1/CONDITION**
+
+
+32 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+The TSF shall perform conditioning in accordance with a specified cryptographic
+algorithm HMAC-[ _**SHA-256**_ ] using a salt, and [ _**[key stretching with scrypt]**_ ] and output
+cryptographic key sizes [ _**256**_ ] that meet the following: [ _**no standard**_ ].
+
+
+_5.1.2.18_ _PP_MDF_V3.3:FCS_HTTPS_EXT.1 HTTPS Protocol_
+
+
+**FCS_HTTPS_EXT.1.1**
+
+The TSF shall implement the HTTPS protocol that complies with RFC 2818.
+**FCS_HTTPS_EXT.1.2**
+
+The TSF shall implement HTTPS using TLS as defined in [the Functional Package for
+Transport Layer Security (TLS), version 1.1].
+**FCS_HTTPS_EXT.1.3**
+
+The TSF shall notify the application and [ _**not establish the connection**_ ] if the peer
+certificate is deemed invalid.
+
+
+_5.1.2.19_ _PP_MDF_V3.3:FCS_IV_EXT.1 Initialization Vector Generation_
+
+
+**FCS_IV_EXT.1.1**
+
+The TSF shall generate IVs in accordance with [Table 11: References and IV
+Requirements for NIST-approved Cipher Modes].
+
+
+_5.1.2.20_ _PP_MDF_V3.3:FCS_RBG_EXT.1 Random Bit Generation_
+
+
+**FCS_RBG_EXT.1.1**
+
+The TSF shall perform all deterministic random bit generation services in accordance
+with NIST Special Publication 800-90A using [ _**HMAC_DRBG (any), CTR_DRBG (AES)**_ ].
+**FCS_RBG_EXT.1.2**
+
+The deterministic RBG shall be seeded by an entropy source that accumulates entropy
+from [ _**TSF-hardware-based noise source**_ ] with a minimum of [ _**256 bits**_ ] of entropy at
+least equal to the greatest security strength (according to NIST SP 800-57) of the keys
+and hashes that it will generate.
+**FCS_RBG_EXT.1.3**
+
+The TSF shall be capable of providing output of the RBG to applications running on the
+TSF that request random bits.
+
+
+_5.1.2.21_ _PP_MDF_V3.3:FCS_SRV_EXT.1 Cryptographic Algorithm Services_
+
+
+**FCS_SRV_EXT.1.1**
+
+The TSF shall provide a mechanism for applications to request the TSF to perform the
+following cryptographic operations: [
+
+ - All mandatory and [ _**selected algorithms**_ ] in FCS_CKM.2/LOCKED
+
+ - The following algorithms in FCS_COP.1/ENCRYPT: AES-CBC, [ _**AES-GCM**_ ]
+
+ - All selected algorithms in FCS_COP.1/SIGN
+
+ - All mandatory and selected algorithms in FCS_COP.1/HASH
+
+ - All mandatory and selected algorithms in FCS_COP.1/KEYHMAC
+
+ - [ _**All mandatory and [selected algorithms] in FCS_CKM.1**_ ]
+
+
+33 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+].
+
+
+_5.1.2.22_ _PP_MDF_V3.3:FCS_SRV_EXT.2 Cryptographic Algorithm Services_
+
+
+**FCS_SRV_EXT.2.1**
+
+The TSF shall provide a mechanism for applications to request the TSF to perform the
+following cryptographic operations: [
+
+ - Algorithms in FCS_COP.1/ENCRYPT
+
+ - Algorithms in FCS_COP.1/SIGN
+] by keys stored in the secure key storage.
+
+
+_5.1.2.23_ _PP_MDF_V3.3:FCS_STG_EXT.1 Cryptographic Key Storage_
+
+
+**FCS_STG_EXT.1.1**
+
+The TSF shall provide [ _**mutable hardware**_ _**[2]**_ _**, software-based**_ ] secure key storage for
+asymmetric private keys and [ _**symmetric keys, persistent secrets**_ ].
+**FCS_STG_EXT.1.2**
+
+The TSF shall be capable of importing keys or secrets into the secure key storage upon
+request of [ _**the user, the administrator**_ ] and [ _**applications running on the TSF**_ ].
+**FCS_STG_EXT.1.3**
+
+The TSF shall be capable of destroying keys or secrets in the secure key storage upon
+request of [ _**the user, the administrator**_ ].
+**FCS_STG_EXT.1.4**
+
+The TSF shall have the capability to allow only the application that imported the key or
+secret the use of the key or secret. Exceptions may only be explicitly authorized by [ _**a**_
+_**common application developer**_ ].
+**FCS_STG_EXT.1.5**
+
+The TSF shall allow only the application that imported the key or secret to request that
+the key or secret be destroyed. Exceptions may only be explicitly authorized by [ _**a**_
+_**common application developer**_ ].
+
+
+_5.1.2.24_ _PP_MDF_V3.3:FCS_STG_EXT.2 Encrypted Cryptographic Key Storage_
+
+
+**FCS_STG_EXT.2.1**
+
+The TSF shall encrypt all DEKs, KEKs, [ **WPA2/WPA3 PSK, Bluetooth Keys** ] and [ _**all**_
+_**software-based key storage**_ ] by KEKs that are [
+
+ - _**Protected by the REK with [**_
+
+`o` _**encryption by a KEK chaining from a REK**_
+
+`o` _**encryption by a KEK that is derived from a REK]**_
+
+ - _**Protected by the REK and the password with [**_
+
+`o` _**encryption by a KEK chaining to a REK and the password-derived or biometric-**_
+
+_**unlocked KEK**_
+
+
+2 Does not apply to the Pixel 6 Pro/6/6a
+
+34 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+`o` _**encryption by a KEK that is derived from a REK and the password-derived or**_
+
+_**biometric-unlocked KEK]**_
+].
+**FCS_STG_EXT.2.2**
+
+DEKs, KEKs, [ **WPA2/WPA3 PSK, Bluetooth Keys** ] and [ _**all software-based key storage**_ ]
+shall be encrypted using one of the following methods: [
+
+ - _**using a SP800-56B key establishment scheme**_
+
+ - _**using AES in the [GCM, CCM mode]**_
+].
+
+
+_5.1.2.25_ _PP_MDF_V3.3:FCS_STG_EXT.3 Integrity of Encrypted Key Storage_
+
+
+**FCS_STG_EXT.3.1**
+
+The TSF shall protect the integrity of any encrypted DEKs and KEKs and [ _**long-term**_
+_**trusted channel key material, all software-based key storage**_ ] by [
+
+ - _**[GCM, CCM] cipher mode for encryption according to FCS_STG_EXT.2**_
+].
+**FCS_STG_EXT.3.2**
+
+The TSF shall verify the integrity of the [ _**MAC**_ ] of the stored key prior to use of the key.
+
+
+_5.1.2.26_ _MOD_MDM_AGENT_V1.0:FCS_STG_EXT.4 Cryptographic Key Storage_
+
+
+**FCS_STG_EXT.4.1**
+
+The MDM Agent shall use the platform provided key storage for all persistent secret and
+private keys.
+
+
+_5.1.2.27_ _PKG_TLS_V1.1:FCS_TLS_EXT.1 TLS Protocol_
+
+
+**FCS_TLS_EXT.1.1**
+
+The product shall implement [
+
+ - _**TLS as a client**_
+].
+
+
+_5.1.2.28_ _PKG_TLS_V1.1:FCS_TLSC_EXT.1 TLS Client Protocol_
+
+
+**FCS_TLSC_EXT.1.1**
+
+The product shall implement TLS 1.2 (RFC 5246) and [ _**no earlier TLS versions**_ ] as a client
+that supports the cipher suites [
+
+ - _**TLS_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288,**_
+
+ - _**TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288,**_
+
+ - _**TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289,**_
+
+ - _**TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289,**_
+
+ - _**TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289,**_
+
+ - _**TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289**_
+] and also supports functionality for [
+
+
+35 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+ - _**mutual authentication**_
+
+ - _**session renegotiation**_
+].
+**FCS_TLSC_EXT.1.2**
+
+The TSF shall verify that the presented identifier matches the reference identifier
+according to RFC 6125.
+**FCS_TLSC_EXT.1.3**
+
+The TSF shall not establish a trusted channel if the server certificate is invalid [
+
+ - _**with no exceptions**_
+].
+(TD0442 applied)
+
+
+_5.1.2.29_ _PKG_TLS_V1.1:FCS_TLSC_EXT.2 TLS Client Support for Mutual Authentication_
+
+
+**FCS_TLSC_EXT.2.1**
+
+The product shall support mutual authentication using X.509v3 certificates.
+
+
+_5.1.2.30_ _PKG_TLS_V1.1:FCS_TLSC_EXT.4 TLS Client Support for Renegotiation_
+
+
+**FCS_TLSC_EXT.4.1**
+
+The product shall support secure renegotiation through use of the โrenegotiation_infoโ
+TLS extension in accordance with RFC 5746.
+
+
+_5.1.2.31_ _PKG_TLS_V1.1:FCS_TLSC_EXT.5 TLS Client Support for Supported Groups Extension_
+
+
+**FCS_TLSC_EXT.5.1**
+
+The product shall present the Supported Groups Extension in the Client Hello with the
+supported groups [
+
+ - _**secp256r1,**_
+
+ - _**secp384r1**_
+].
+
+
+_5.1.2.32_ _MOD_WLANC_V1.0:FCS_TLSC_EXT.1/WLAN TLS Client Protocol (EAP-TLS for WLAN)_
+
+
+**FCS_TLSC_EXT.1.1/WLAN**
+
+The product shall implement TLS 1.2 (RFC 5246) and [ _**TLS 1.1 (RFC 4346)**_ ] in support of
+the EAP-TLS protocol as specified in RFC 5216 supporting the following cipher suites: [
+
+ - _**TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 5246,**_
+
+ - _**TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288,**_
+
+ - _**TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289,**_
+
+ - _**TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289,**_
+
+ - _**TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289,**_
+
+ - _**TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289**_
+].
+
+
+36 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+**FCS_TLSC_EXT.1.2/WLAN**
+
+The TSF shall generate random values used in the EAP-TLS exchange using the RBG
+specified in FCS_RBG_EXT.1.
+**FCS_TLSC_EXT.1.3/WLAN**
+
+The TSF shall use X509 v3 certificates as specified in FIA_X509_EXT.1/WLAN.
+**FCS_TLSC_EXT.1.4/WLAN**
+
+The TSF shall verify that the server certificate presented includes the Server
+Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage
+field.
+**FCS_TLSC_EXT.1.5/WLAN**
+
+The TSF shall allow an authorized administrator to configure the list of CAs that are
+allowed to sign authentication server certificates that are accepted by the TOE.
+
+
+_5.1.2.33_ _MOD_WLANC_V1.0:FCS_TLSC_EXT.2/WLAN TLS Client Support for Supported Groups_
+_Extension (EAP-TLS for WLAN)_
+
+
+**FCS_TLSC_EXT.2.1/WLAN**
+
+The TSF shall present the Supported Groups Extension in the Client Hello with the
+following NIST curves: [ _**secp256r1, secp384r1**_ ].
+
+
+_5.1.2.34_ _MOD_WLANC_V1.0:FCS_WPA_EXT.1 Supported WPA Versions_
+
+
+**FCS_WPA_EXT.1.1**
+
+The TSF shall support WPA3 and [ _**WPA2**_ ] security type.
+
+
+5.1.3 User Data Protection (FDP)
+
+
+_5.1.3.1_ _PP_MDF_V3.3:FDP_ACF_EXT.1 Security Access Control for System Services_
+
+
+**FDP_ACF_EXT.1.1**
+
+The TSF shall provide a mechanism to restrict the system services that are accessible to
+an application.
+**FDP_ACF_EXT.1.2**
+
+The TSF shall provide an access control policy that prevents [ _**application, groups of**_
+_**applications**_ ] from accessing [ _**all**_ ] data stored by other [ _**application, groups of**_
+_**applications**_ ]. Exceptions may only be explicitly authorized for such sharing by [ _**a**_
+_**common application developer (for sharing between applications), no one (for sharing**_
+_**between personal and enterprise profiles)**_ ].
+
+
+_5.1.3.2_ _PP_MDF_V3.3:FDP_ACF_EXT.2 Security Access Control for System Resources_
+
+
+**FDP_ACF_EXT.2.1**
+
+The TSF shall provide a separate [ _**address book, calendar, [keychain]**_ ] for each
+application group and only allow applications within that process group to access the
+resource. Exceptions may only be explicitly authorized for such sharing by [ _**the**_
+_**administrator (for address book), no one (for calendar, keychain)**_ ].
+
+
+37 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+_5.1.3.3_ _PP_MDF_V3.3:FDP_DAR_EXT.1 Protected Data Encryption_
+
+
+**FDP_DAR_EXT.1.1**
+
+Encryption shall cover all protected data.
+**FDP_DAR_EXT.1.2**
+
+Encryption shall be performed using DEKs with AES in the [ _**XTS**_ ] mode with key size [ _**256**_ ]
+bits.
+
+
+_5.1.3.4_ _PP_MDF_V3.3:FDP_DAR_EXT.2 Sensitive Data Encryption_
+
+
+**FDP_DAR_EXT.2.1**
+
+The TSF shall provide a mechanism for applications to mark data and keys as sensitive.
+**FDP_DAR_EXT.2.2**
+
+The TSF shall use an asymmetric key scheme to encrypt and store sensitive data
+received while the product is locked.
+**FDP_DAR_EXT.2.3**
+
+The TSF shall encrypt any stored symmetric key and any stored private key of the
+asymmetric keys used for the protection of sensitive data according to
+
+[FCS_STG_EXT.2.1 selection 2].
+**FDP_DAR_EXT.2.4**
+
+The TSF shall decrypt the sensitive data that was received while in the locked state upon
+transitioning to the unlocked state using the asymmetric key scheme and shall reencrypt that sensitive data using the symmetric key scheme.
+
+
+_5.1.3.5_ _PP_MDF_V3.3:FDP_IFC_EXT.1 Subset Information Flow Control_
+
+
+**FDP_IFC_EXT.1.1**
+
+The TSF shall [ _**provide an interface which allows a VPN client to protect all IP traffic**_
+_**using IPsec**_ ] with the exception of IP traffic needed to manage the VPN connection, and
+
+[ _**traffic needed to determine if the network connection has connectivity to the internet**_
+_**and responses to local ICMP echo requests on the local subnet**_ ], when the VPN is
+enabled.
+
+
+_5.1.3.6_ _PP_MDF_V3.3:FDP_STG_EXT.1 User Data Storage_
+
+
+**FDP_STG_EXT.1.1**
+
+The TSF shall provide protected storage for the Trust Anchor Database.
+
+
+_5.1.3.7_ _PP_MDF_V3.3:FDP_UPC_EXT.1/APPS Inter-TSF User Data Transfer Protection_
+_(Applications)_
+
+
+**FDP_UPC_EXT.1.1/APPS**
+
+The TSF shall provide a means for non-TSF applications executing on the TOE to use [
+
+ - Mutually authenticated TLS as defined in the Functional Package for Transport Layer
+Security (TLS), version 1.1,
+
+ - HTTPS
+and [
+
+
+38 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+ - _**no other protocol**_
+]] to provide a protected communication channel between the non-TSF application and
+another IT product that is logically distinct from other communication channels,
+provides assured identification of its end points, protects channel data from disclosure,
+and detects modification of the channel data.
+**FDP_UPC_EXT.1.2/APPS**
+
+The TSF shall permit the non-TSF applications to initiate communication via the trusted
+channel.
+
+
+_5.1.3.8_ _PP_MDF_V3.3:FDP_UPC_EXT.1/BLUETOOTH Inter-TSF User Data Transfer Protection_
+_(Bluetooth)_
+
+
+**FDP_UPC_EXT.1.1/BLUETOOTH**
+
+The TSF shall provide a means for non-TSF applications executing on the TOE to use [
+
+ - Bluetooth BR/EDR in accordance with the PP-Module for Bluetooth, version 1.0,
+and [
+
+ - _**Bluetooth LE in accordance with the PP-Module for Bluetooth, version 1.0**_
+]] to provide a protected communication channel between the non-TSF application and
+another IT product that is logically distinct from other communication channels,
+provides assured identification of its end points, protects channel data from disclosure,
+and detects modification of the channel data.
+**FDP_UPC_EXT.1.2/BLUETOOTH**
+
+The TSF shall permit the non-TSF applications to initiate communication via the trusted
+channel.
+
+
+5.1.4 Identification and Authentication (FIA)
+
+
+_5.1.4.1_ _PP_MDF_V3.3:FIA_AFL_EXT.1 Authentication Failure Handling_
+
+
+**FIA_AFL_EXT.1.1**
+
+The TSF shall consider password and [ _**no other mechanism**_ ] as critical authentication
+mechanisms.
+**FIA_AFL_EXT.1.2**
+
+The TSF shall detect when a configurable positive integer within [ **0 and 50** ] of [ _**non-**_
+_**unique**_ ] unsuccessful authentication attempts occur related to last successful
+authentication for each authentication mechanism.
+**FIA_AFL_EXT.1.3**
+
+The TSF shall maintain the number of unsuccessful authentication attempts that have
+occurred upon power off.
+**FIA_AFL_EXT.1.4**
+
+When the defined number of unsuccessful authentication attempts has exceeded the
+maximum allowed for a given authentication mechanism, all future authentication
+attempts will be limited to other available authentication mechanisms, unless the given
+mechanism is designated as a critical authentication mechanism.
+**FIA_AFL_EXT.1.5**
+
+
+39 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+When the defined number of unsuccessful authentication attempts for the last available
+authentication mechanism or single critical authentication mechanism has been
+surpassed, the TSF shall perform a wipe of all protected data.
+**FIA_AFL_EXT.1.6**
+
+The TSF shall increment the number of unsuccessful authentication attempts prior to
+notifying the user that the authentication was unsuccessful.
+
+
+_5.1.4.2_ _MOD_BT_V1.0:FIA_BLT_EXT.1 Bluetooth User Authorization_
+
+
+**FIA_BLT_EXT.1.1**
+
+The TSF shall require explicit user authorization before pairing with a remote Bluetooth
+device.
+
+
+_5.1.4.3_ _MOD_BT_V1.0:FIA_BLT_EXT.2 Bluetooth Mutual Authentication_
+
+
+**FIA_BLT_EXT.2.1**
+
+The TSF shall require Bluetooth mutual authentication between devices prior to any
+data transfer over the Bluetooth link.
+
+
+_5.1.4.4_ _MOD_BT_V1.0:FIA_BLT_EXT.3 Rejection of Duplicate Bluetooth Connections_
+
+
+**FIA_BLT_EXT.3.1**
+
+The TSF shall discard pairing and session initialization attempts from a Bluetooth device
+address (BD_ADDR) to which an active session already exists.
+
+
+_5.1.4.5_ _MOD_BT_V1.0:FIA_BLT_EXT.4 Secure Simple Pairing_
+
+
+**FIA_BLT_EXT.4.1**
+
+The TOE shall support Bluetooth Secure Simple Pairing, both in the host and the
+controller.
+**FIA_BLT_EXT.4.2**
+
+The TOE shall support Secure Simple Pairing during the pairing process.
+
+
+_5.1.4.6_ _MOD_BT_V1.0:FIA_BLT_EXT.6 Trusted Bluetooth User Authorization_
+
+
+**FIA_BLT_EXT.6.1**
+
+The TSF shall require explicit user authorization before granting trusted remote devices
+access to services associated with the following Bluetooth profiles: [ _**OPP, MAP**_ ].
+
+
+_5.1.4.7_ _MOD_BT_V1.0:FIA_BLT_EXT.7 Untrusted Bluetooth User Authorization_
+
+
+**FIA_BLT_EXT.7.1**
+
+The TSF shall require explicit user authorization before granting untrusted remote
+devices access to services associated with the following Bluetooth profiles: [ _**OPP, MAP**_ ].
+
+
+_5.1.4.8_ _MOD_MDM_AGENT_V1.0:FIA_ENR_EXT.2 Agent Enrollment of Mobile Device into_
+_Management_
+
+
+**FIA_ENR_EXT.2.1**
+
+
+40 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+The MDM Agent shall record the reference identifier of the MDM Server during the
+enrollment process.
+
+
+_5.1.4.9_ _MOD_BIO_V1.1:FIA_MBE_EXT.1 Biometric enrolment_
+
+
+**FIA_MBE_EXT.1.1**
+
+The TSF shall provide a mechanism to enrol an authenticated user to the biometric
+system.
+(TD0714 applied)
+
+
+_5.1.4.10_ _MOD_BIO_V1.1:FIA_MBE_EXT.2 Quality of biometric templates for biometric_
+_enrolment_
+
+
+**FIA_MBE_EXT.2.1**
+
+The TSF shall only use biometric samples of sufficient quality for enrolment. Sufficiency
+of sample data shall be determined by measuring sample with [ _**the ability to meet the**_
+_**Android 15 CDD Class 3 biometric requirements**_ ].
+
+
+_5.1.4.11_ _MOD_BIO_V1.1:FIA_MBV_EXT.1/PBFPS Biometric verification_
+
+
+This applies to the Pixel 9 Pro Fold, Tablet, Fold devices.
+**FIA_MBV_EXT.1.1/PBFPS**
+
+The TSF shall provide a biometric verification mechanism using [ _**fingerprint**_ ].
+**FIA_MBV_EXT.1.2/PBFPS**
+
+The TSF shall provide a biometric verification mechanism with the [ _**FAR**_ ] not exceeding
+
+[ **1:50,000** ] for the upper bound of [ **95%** ] confidence interval and, [ _**FRR**_ ] not exceeding
+
+[ **3%** ] for the upper bound of [ **95%** ] confidence interval.
+
+
+_5.1.4.12_ _MOD_BIO_V1.1:FIA_MBV_EXT.1/UDFPS Biometric verification_
+
+
+This applies to the Pixel 8 Pro/8/8a, 7 Pro/7/7a, 6 Pro/6/6a devices.
+**FIA_MBV_EXT.1.1/UDFPS**
+
+The TSF shall provide a biometric verification mechanism using [ _**fingerprint**_ ].
+**FIA_MBV_EXT.1.2/UDFPS**
+
+The TSF shall provide a biometric verification mechanism with the [ _**FAR**_ ] not exceeding
+
+[ **1:50,000** ] for the upper bound of [ **95%** ] confidence interval and, [ _**FRR**_ ] not exceeding
+
+[ **3%** ] for the upper bound of [ **95%** ] confidence interval.
+
+
+_5.1.4.13_ _MOD_BIO_V1.1:FIA_MBV_EXT.1/USFPS Biometric verification_
+
+
+This applies to the Pixel 9 Pro XL/9 Pro/9 devices.
+**FIA_MBV_EXT.1.1/USFPS**
+
+The TSF shall provide a biometric verification mechanism using [ _**fingerprint**_ ].
+**FIA_MBV_EXT.1.2/USFPS**
+
+The TSF shall provide a biometric verification mechanism with the [ _**FAR**_ ] not exceeding
+
+[ **1:50,000** ] for the upper bound of [ **95%** ] confidence interval and, [ _**FRR**_ ] not exceeding
+
+[ **3%** ] for the upper bound of [ **95%** ] confidence interval.
+
+
+41 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+_5.1.4.14_ _MOD_BIO_V1.1:FIA_MBV_EXT.2 Quality of biometric samples for biometric_
+_verification_
+
+
+**FIA_MBV_EXT.2.1**
+
+The TSF shall only use biometric samples of sufficient quality for verification. Sufficiency
+of sample data shall be determined by measuring sample with [ _**the ability to meet**_ _**the**_
+_**Android 15 CDD Class 3 biometric requirements**_ ].
+
+
+_5.1.4.15_ _MOD_BIO_V1.1:FIA_MBV_EXT.3 Presentation attack detection for biometric_
+_verification_
+
+
+**FIA_MBV_EXT.3.1**
+
+The TSF shall provide a biometric verification mechanism with the IAPAR not exceeding
+
+[ **7%** ] to prevent use of artificial presentation attack instruments from being successfully
+verified.
+
+
+_5.1.4.16_ _MOD_WLANC_V1.0:FIA_PAE_EXT.1 Port Access Entity Authentication_
+
+
+**FIA_PAE_EXT.1.1**
+
+The TSF shall conform to IEEE Standard 802.1X for a Port Access Entity (PAE) in the
+โSupplicantโ role.
+
+
+_5.1.4.17_ _PP_MDF_V3.3:FIA_PMG_EXT.1 Password Management_
+
+
+**FIA_PMG_EXT.1.1**
+
+The TSF shall support the following for the Password Authentication Factor:
+1. Passwords shall be able to be composed of any combination of _**[upper and lower**_
+
+_**case letters**_ ], numbers, and special characters: [ _**! @ # $ % ^ & * ( ) [= + - _ ` ~ \ | ] } [**_
+_**{ โ โ ; : / ? . >, < ]**_ ]
+2. Password length up to [ _**16**_ ] characters shall be supported.
+
+
+_5.1.4.18_ _PP_MDF_V3.3:FIA_TRT_EXT.1 Authentication Throttling_
+
+
+**FIA_TRT_EXT.1.1**
+
+The TSF shall limit automated user authentication attempts by [ _**enforcing a delay**_
+_**between incorrect authentication attempts**_ ] for all authentication mechanisms selected
+in FIA_UAU.5.1. The minimum delay shall be such that no more than 10 attempts can be
+attempted per 500 milliseconds.
+
+
+_5.1.4.19_ _PP_MDF_V3.3:FIA_UAU.5 Multiple Authentication Mechanisms_
+
+
+**FIA_UAU.5.1**
+
+The TSF shall provide password and [ _**biometric in accordance with the Biometric**_
+_**Enrollment and Verification, version 1.1**_ ] to support user authentication.
+**FIA_UAU.5.2**
+
+The TSF shall authenticate any user's claimed identity according to the [ _**following rules:**_
+_**To authenticate unlocking the device immediately after boot (first unlock after**_
+_**reboot):**_
+
+
+42 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+ - _**User passwords are required after reboot to unlock the user's Credential encrypted**_
+_**(CE files) and keystore keys. Biometric authentication is disabled immediately after**_
+_**boot.**_
+_**To authenticate unlocking the device after device lock (not following a reboot):**_
+
+ - _**The TOE verifies user credentials (password or fingerprint) via the gatekeeper or**_
+_**fingerprint trusted application (running inside the Trusted Execution Environment,**_
+_**TEE), which compares the entered credential to a derived value or template.**_
+_**To change protected settings or issue certain commands:**_
+
+ - _**The TOE requires password after a reboot, when changing settings (Screen lock,**_
+_**Fingerprint, and Smart Lock settings), and when factory resetting.**_
+].
+
+
+_5.1.4.20_ _PP_MDF_V3.3:FIA_UAU.6/CREDENTIAL Re-Authentication (Credential Change)_
+
+
+**FIA_UAU.6.1/CREDENTIAL**
+
+The TSF shall re-authenticate the user via the Password Authentication Factor under the
+conditions [attempted change to any supported authentication mechanisms].
+
+
+_5.1.4.21_ _PP_MDF_V3.3:FIA_UAU.6/LOCKED Re-Authentication (TSF Lock)_
+
+
+**FIA_UAU.6.1/LOCKED**
+
+The TSF shall re-authenticate the user via an authentication factor defined in
+FIA_UAU.5.1 under the conditions TSF-initiated lock, user-initiated lock, [ **no other**
+**conditions** ].
+
+
+_5.1.4.22_ _PP_MDF_V3.3:FIA_UAU.7 Protected Authentication Feedback_
+
+
+**FIA_UAU.7.1**
+
+The TSF shall provide only [obscured feedback to the device's display] to the user while
+the authentication is in progress.
+
+
+_5.1.4.23_ _PP_MDF_V3.3:FIA_UAU_EXT.1 Authentication for Cryptographic Operation_
+
+
+**FIA_UAU_EXT.1.1**
+
+The TSF shall require the user to present the Password Authentication Factor prior to
+decryption of protected data and encrypted DEKs, KEKs and [ _**all software-based key**_
+_**storage**_ ] at startup.
+
+
+_5.1.4.24_ _PP_MDF_V3.3:FIA_UAU_EXT.2 Timing of Authentication_
+
+
+**FIA_UAU_EXT.2.1**
+
+The TSF shall allow **[** _**[**_
+
+ - _**Take screen shots (stored internally)**_
+
+ - _**Make emergency calls**_
+
+ - _**Receive calls**_
+
+ - _**Take pictures (stored internally) - unless the camera was disabled**_
+
+ - _**Turn the TOE off**_
+
+
+43 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+ - _**Restart the TOE**_
+
+ - _**Place TOE into lockdown mode**_
+
+ - _**Adjust screen brightness**_
+
+ - _**See notifications (note that some notifications identify actions, for example to**_
+_**view a screenshot; however, selecting those notifications highlights the password**_
+_**prompt and require the password to access that data)**_
+
+ - _**Configure sound, vibrate, or mute**_
+
+ - _**Change keyboard input method**_
+
+ - _**Access widgets (without authentication):**_
+
+`o` _**Internet toggle (Wi-Fi and Mobile/Cellular data)**_
+
+`o` _**Bluetooth toggle**_
+
+`o` _**Airplane Mode toggle**_
+
+`o` _**Flashlight toggle**_
+
+`o` _**Do not disturb toggle**_
+
+`o` _**Auto rotate toggle**_
+
+`o` _**Sound (on, mute, vibrate)**_
+
+`o` _**Night light filter toggle**_
+
+`o` _**Live captions toggle**_
+
+`o` _**Battery Saver toggle**_
+
+`o` _**Hotspot toggle (using what has already been configured)**_
+
+`o` _**Color inversion toggle**_
+
+`o` _**Data Saver toggle**_
+
+`o` _**Dark Theme toggle**_
+
+`o` _**One-handed mode toggle**_
+
+`o` _**Extra dim toggle**_
+
+`o` _**Font Size toggle**_
+
+`o` _**Screen saver toggle**_
+
+`o` _**Color correction toggle**_
+
+`o` _**Calculator app**_
+_**]**_ ] on behalf of the user to be performed before the user is authenticated.
+**FIA_UAU_EXT.2.2**
+
+The TSF shall require each user to be successfully authenticated before allowing any
+other TSF-mediated actions on behalf of that user.
+
+
+_5.1.4.25_ _PP_MDF_V3.3:FIA_X509_EXT.1 Validation of Certificates_
+
+
+**FIA_X509_EXT.1.1**
+
+The TSF shall validate certificates in accordance with the following rules:
+
+ - RFC 5280 certificate validation and certificate path validation.
+
+ - The certificate path must terminate with a certificate in the Trust Anchor Database.
+
+
+44 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+ - The TSF shall validate a certificate path by ensuring the presence of the
+basicConstraints extension, that the CA flag is set to TRUE for all CA certificates, and
+that any path constraints are met.
+
+ - The TSF shall validate that any CA certificate includes caSigning purpose in the key
+usage field.
+
+ - The TSF shall validate the revocation status of the certificate using [ _**OCSP as**_
+_**specified in RFC 6960**_ ].
+
+ - The TSF shall validate the extendedKeyUsage field according to the following rules:
+
+`o` Certificates used for trusted updates and executable code integrity verification
+
+shall have the Code Signing purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3) in the
+extendedKeyUsage field
+
+`o` Server certificates presented for TLS shall have the Server Authentication
+
+purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field.
+
+`o` Server certificates presented for EST shall have the CMC Registration Authority
+
+(RA) purpose (id-kp-cmcRA with OID 1.3.6.1.5.5.7.3.28) in the
+extendedKeyUsage field. [conditional]
+
+`o` Client certificates presented for TLS shall have the Client Authentication purpose
+
+(id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field.
+
+`o` OCSP certificates presented for OCSP responses shall have the OCSP Signing
+
+purpose (id-dp 9 with OID 1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field.
+
+[conditional]
+**FIA_X509_EXT.1.2**
+
+The TSF shall only treat a certificate as a CA certificate if the basicConstraints extension
+is present and the CA flag is set to TRUE.
+
+
+_5.1.4.26_ _PP_MDF_V3.3:FIA_X509_EXT.2 X509 Certificate Authentication_
+
+
+**FIA_X509_EXT.2.1**
+
+The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication
+for [mutually authenticated TLS as defined in the Package for Transport Layer Security
+(TLS), version 1.1, HTTPS, [ _**no other protocol**_ ]] and [ _**no additional uses**_ ].
+**FIA_X509_EXT.2.2**
+
+When the TSF cannot establish a connection to determine the revocation status of a
+certificate, the TSF shall [ _**not accept the certificate**_ ].
+
+
+_5.1.4.27_ _PP_MDF_V3.3:FIA_X509_EXT.3 Request Validation of Certificates_
+
+
+**FIA_X509_EXT.3.1**
+
+The TSF shall provide a certificate validation service to applications.
+**FIA_X509_EXT.3.2**
+
+The TSF shall respond to the requesting application with the success or failure of the
+validation.
+
+
+_5.1.4.28_ _MOD_WLANC_V1.0:FIA_X509_EXT.1/WLAN X.509 Certificate Validation_
+
+
+**FIA_X509_EXT.1.1/WLAN**
+
+45 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+The TSF shall validate certificates for EAP-TLS in accordance with the following rules:
+
+ - RFC 5280 certificate validation and certificate path validation
+
+ - The certificate path must terminate with a certificate in the Trust Anchor Database
+
+ - The TSF shall validate a certificate path by ensuring the presence of the
+basicConstraints extension and that the CA flag is set to TRUE for all CA certificates
+
+ - The TSF shall validate the extendedKeyUsage field according to the following rules:
+
+`o` Server certificates presented for TLS shall have the Server Authentication
+
+purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field
+
+`o` Client certificates presented for TLS shall have the Client Authentication purpose
+
+(id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field.
+**FIA_X509_EXT.1.2/WLAN**
+
+The TSF shall only treat a certificate as a CA certificate if the basicConstraints extension
+is present and the CA flag is set to TRUE.
+
+
+_5.1.4.29_ _MOD_WLANC_V1.0:FIA_X509_EXT.2/WLAN X.509 Certificate Authentication (EAP-TLS_
+_for WLAN)_
+
+
+**FIA_X509_EXT.2.1/WLAN**
+
+The TSF shall use X.509v3 certificates as defined by RFC 5280 to support [ _[authentication_
+_for EAP-TLS exchanges]_ ].
+
+
+_5.1.4.30_ _MOD_WLANC_V1.0:FIA_X509_EXT.6 Certificate Storage and Management_
+
+
+**FIA_X509_EXT.6.1**
+
+The TSF shall [ _**invoke [software-based key storage] to store and protect**_ ] certificate(s)
+from unauthorized deletion and modification.
+**FIA_X509_EXT.6.2**
+
+The TSF shall [ _**rely on [the TOE certificate management system] to load X.509v3**_
+_**certificates into [software-based key storage]**_ ] for use by the TSF.
+
+
+5.1.5 Security management (FMT)
+
+
+_5.1.5.1_ _PP_MDF_V3.3:FMT_MOF_EXT.1 Management of Security Functions Behavior_
+
+
+**FMT_MOF_EXT.1.1**
+
+The TSF shall restrict the ability to perform the functions in [column 4 of Table 16 Security Management Functions] to the user.
+**FMT_MOF_EXT.1.2**
+
+The TSF shall restrict the ability to perform the functions [in column 6 of Table 16 Security Management Functions] to the administrator when the device is enrolled and
+according to the administrator-configured policy.
+
+
+_5.1.5.2_ _MOD_MDM_AGENT_V1.0:FMT_POL_EXT.2 Agent Trusted Policy Update_
+
+
+**FMT_POL_EXT.2.1**
+
+The MDM Agent shall only accept policies and policy updates that are digitally signed by
+a private key that has been authorized for policy updates by the MDM Server.
+
+46 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+**FMT_POL_EXT.2.2**
+
+The MDM Agent shall not install policies if the signature check fails.
+(TD0755 applied)
+
+
+_5.1.5.3_ _PP_MDF_V3.3:FMT_SMF.1 Specification of Management Functions_
+
+
+**FMT_SMF.1.1**
+
+The TSF shall be capable of performing the following management functions:
+
+(In the last four columns, M = Mandatory and I = Implemented, to denote which options are available
+for any management function.)
+
+
+
+
+
+|#|Management Function|Implemented|User Only|Admin|Admin Only|
+|---|---|---|---|---|---|
+|1.|configure password policy:
โข
Minimum password length
โข
Minimum password complexity
โข
Maximum password lifetime
The administrator can configure the required password characteristics (minimum
length, complexity, and lifetime) using the Android MDM APIs.
Length: an integer value of characters (password range is 4-16 characters, values
below that range are treated as 4, values above that range are treated as 16)
Complexity:
โข
Unspecified, Something โ no specific requirements for the password
โข
Numeric โ numbers are required in the password (can be all numbers, or
anything that has numbers in it)
โข
Numeric_Complex โ same as Numeric, but no repeating or sequential
numeric characters above 3 are allowed (e.g. 4444, 1234, 2468)
โข
Alphabetic โ letters or symbols are required in the password (can be all
letters, or anything with letters/symbols in it)
โข
Alphanumeric โ letters/symbols and numbers are required in the password
โข
Complex โ enables the admin to set specific constraints on the password
requirements (minimum/maximum letters, symbols, numbers and length)
Lifetime: an integer value of seconds (0 = no maximum).|M|-|M|M|
+
+
+47 of 100
+
+
+
+
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+|#|Management Function|Implemented|User Only|Admin|Admin Only|
+|---|---|---|---|---|---|
+|2.|configure session locking policy:
โข
Screen-lock enabled/disabled
โข
Screen lock timeout
โข
Number of authentication failures
The administrator can configure the session locking policy using the Android MDM
APIs.
Screen lock timeout: an integer number of milliseconds before the TOE locks. An
integer number (-9,223,372,036,854,775,808 to 9,223,372,036,854,775,807 [negative
integers and zero means no lockout]).
Authentication failures: an integer number (-2,147,483,648 to 2,147,483,648
[negative integers and zero means no limit]) of failures before a wipe action is
initiated. This only applies to password authentication, biometric attempts do not
increment this counter.|M|-|M|M|
+|3.|enable/disable the VPN protection:
โข
Across device
โข
[**_on a per-group of applications processes basis_**]
Both users (using the TOEโs settings UI) and administrator (using the TOEโs MDM
APIs) can configure a third-party VPN client and then enable the VPN client to protect
traffic. The User can set up VPN protection, but if an admin enables VPN protection,
the user cannot disable it.
The administrator (using the TOEโs MDM APIs) can configure a VPN client for a group
of applications through the creation of a work profile. The VPN client for the work
profile will be associated with all the applications included in the work profile.|M|-|I|I|
+|4.|enable/disable [**Bluetooth, NFC**]
enable/disable [**Wi-Fi, cellular**]
The administrator (using the TOEโs MDM APIs) can manage Bluetooth radio. The user
cannot override the administrator setting.
The NFC, Wi-Fi and cellular radios can be disabled by the administrator (using the
TOEโs MDM APIs), but the user (using the TOEโs settings UI) is able to override this
and turn the radios back on.
The TOEโs radios operate at frequencies of 2.4 GHz (NFC/Bluetooth), 2.4/5 GHz (Wi-
Fi) and 850, 900, 1800, 1900 MHz (4G/LTE).
The radios are initialized during the initial power-up sequence. If the radio is
supposed to be off (by setting), it will be turned off after the initial check.|M
M|-
I|I
-|I
-|
+
+
+
+48 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+
+
+
+
+
+
+
+
+
+
+
+|#|Management Function|Implemented|User Only|Admin|Admin Only|
+|---|---|---|---|---|---|
+|5.|enable/disable [**microphone, camera**]:
โข
Across device,
โข
[**_on a per-app basis_**]
An administrator can enable/disable the deviceโs microphone via an MDM API. Once
the microphone has been disabled, the user cannot re-enable it until the
administrator enables it.
In the userโs settings, a user can view a permission by type (i.e. camera, microphone).
The user can access this by going to the settings UI (`Settings -> Privacy ->`
`Permission manager -> `) and revoking any
applications.|
M
M|
-
-|
I
-|
I
-|
+|6.|transition to the locked state
Both users (using the TOEโs settings UI) and administrators (using the TOEโs MDM
APIs) can transition the TOE into a locked state.|M|-|M|-|
+|7.|TSF wipe of protected data
Both users (using the TOEโs settings UI) and administrators (using the TOEโs MDM
APIs) can force the TOE to perform a full wipe (factory reset) of data.|M|-|M|-|
+|8.|configure application installation policy by: [
โข
**_restricting the sources of applications,_**
โข
**_denying installation of applications_**]
The administrator (using the TOEโs MDM APIs) can configure the TOE so that
applications cannot be installed and can also block the use of the Google Market
Place.|M|-|M|M|
+|9.|import keys or secrets into the secure key storage
Both users (using the TOEโs settings UI) and administrators (using the TOEโs MDM
APIs) can import secret keys into the secure key storage.|M|-|I|-|
+|10.|destroy imported keys or secrets and [**_no other keys or secrets_**] in the secure key
storage
Both users and administrators (using the TOEโs MDM APIs) can destroy secret keys in
the secure key storage.|M|-|I|-|
+|11.|import X.509v3 certificates into the Trust Anchor Database
Both users (using the TOEโs settings UI) and administrators (using the TOEโs MDM
APIs) can import X.509v3 certificates into the Trust Anchor Database.|M|-|M|-|
+
+
+49 of 100
+
+
+
+
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+
+
+
+|#|Management Function|Implemented|User Only|Admin|Admin Only|
+|---|---|---|---|---|---|
+|12.|remove imported X.509v3 certificates and [**_no other X.509v3 certificates_**] in the Trust
Anchor Database
Both users (using the TOEโs settings UI) and administrators (using the TOEโs MDM
APIs) can remove imported X.509v3 certificates from the Trust Anchor Database as
well as disable any of the TOEโs default Root CA certificates (in the latter case, the CA
certificate still resides in the TOEโs read-only system partition; however, the TOE will
treat that Root CA certificate and any certificate chaining to it as untrusted).|M|-|I|-|
+|13.|enroll the TOE in management
TOE users can enroll the TOE in management according to the instructions specific to
a given MDM. Presumably any enrollment would involve at least some user functions
(e.g., install an MDM agent application) on the TOE prior to enrollment.|M|-|-|-|
+|14.|remove applications
Both users (using the TOEโs settings UI) and administrators (using the TOEโs MDM
APIs) can uninstall user and administrator installed applications (and the associated
application data) on the TOE.|M|-|M|-|
+|15.|update system software
Users can check for updates and cause the device to update if an update is available.
An administrator can use MDM APIs to query the version of the TOE and query the
installed applications and an MDM agent on the TOE could issue pop-ups, initiate
updates, block communication, etc. until any necessary updates are completed.|M|-|M|-|
+|16.|install applications
Both users and administrators (using the TOEโs MDM APIs) can install applications on
the TOE.|M|-|M|-|
+|17.|remove Enterprise applications
An administrator (using the TOEโs MDM APIs) can uninstall Enterprise installed
applications on the TOE.|M|-|M|-|
+|18.|enable/disable display notification in the locked state of: [
โข
**_all notifications_**]
Notifications can be configured to display in the following formats:
โข
Users & administrators: show all notification content
โข
Users: hide sensitive content
โข
Users & administrators: hide notifications entirely
If the administrator sets any of the above settings, the user cannot change it.|M|-|I|I|
+|19.|enable data-at rest protection
The TOE always encrypts its user data storage.|M|-|-|-|
+
+
+50 of 100
+
+
+
+
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+
+
+
+
+
+
+
+|#|Management Function|Implemented|User Only|Admin|Admin Only|
+|---|---|---|---|---|---|
+|20.|enable removable mediaโs data-at-rest protection
The device does not support internally installed removable media.|M|-|-|-|
+|21.|enable/disable location services:
โข
Across device
โข
[**_no other method_**]
The administrator (using the TOEโs MDM APIs) can enable or disable location services.
An additional MDM API can prohibit TOE usersโ ability to enable and disable location
services.|M|-|I|I|
+|22.|enable/disable the use of [**_Biometric Authentication Factor_**]
The administrator (using the TOEโs MDM APIs) can enable or disable the biometric
services (individually for each possible supported modality).|I|-|I|I|
+|23.|configure whether to allow or disallow establishment of [**assignment**: _configurable_
_trusted channel in FTP_ITC_EXT.1.1 or FDP_UPC_EXT.1.1/APPS_] if the peer or server
certificate is deemed invalid.|||||
+|24.|enable/disable all data signaling over [**assignment:**_list of externally accessible_
_hardware ports_]|||||
+|25.|enable/disable [**Bluetooth tethering**]
The administrator (using the TOEโs MDM APIs) can enable/disable all tethering
methods (i.e. all or none disabled).
The TOE acts as a server (acting as an access point, a USB Ethernet adapter, and as a
Bluetooth Ethernet adapter respectively) in order to share its network connection
with another device.|I|-|I|I|
+|26.|enable/disable developer modes
The administrator (using the TOEโs MDM APIs) can disable Developer Mode.
Unless disabled by the administrator, TOE users can enable and disable Developer
Mode.|I|-|I|I|
+|27.|enable/disable bypass of local user authentication
N/A โ It is not possible to bypass local user auth for this TOE|||||
+|28.|wipe Enterprise data
An administrator (using the TOEโs MDM APIs) can remove Enterprise applications and
their data. The user can factory reset the device to remove all Enterprise applications
and associated data.|I|-|I|-|
+|29.|approve [**selection**: _import, removal_] by applications of X.509v3 certificates in the
Trust Anchor Database|||||
+|30.|configure whether to allow or disallow establishment of a trusted channel if the TSF
cannot establish a connection to determine the validity of a certificate|||||
+
+
+51 of 100
+
+
+
+
+
+
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+|#|Management Function|Implemented|User Only|Admin|Admin Only|
+|---|---|---|---|---|---|
+|31.|enable/disable the cellular protocols used to connect to cellular network base
stations
An administrator or user is able to block the ability to use 2G networks.|I|-|I|-|
+|32.|read audit logs kept by the TSF
Only the administrator is able to read the SecurityLog, but events tracked through
logcat may be read by a user (based on the setting in #26).|I|-|I|-|
+|33.|configure [**selection**: _certificate, public-key_] used to validate digital signature on
applications|||||
+|34.|approve exceptions for shared use of keys or secrets by multiple applications|||||
+|35.|approve exceptions for destruction of keys or secrets by applications that did not
import the key or secret|||||
+|36.|configure the unlock banner
The administrator (using the TOEโs MDM APIs) can specify text to always be shown on
the lock screen (up to 120 characters can be displayed).|M|-|I|-|
+|37.|configure the auditable items|||||
+|38.|retrieve TSF-software integrity verification values|||||
+|39.|enable/disable [
โข
**_USB mass storage mode_**]
The administrator (using the TOEโs MDM APIs) can specify whether the device can
have its storage mounted as USB storage available for read/write (when the device is
unlocked) to another device (such as a computer). The user can also specify to block
access to USB storage in the TOEโs settings UI.|I|-|I|-|
+|40.|enable/disable backup to [selection: all applications, selected applications, selected
groups of applications, configuration data] to [selection: locally connected system,
remote system]|||||
+|41.|enable/disable [
โข
**_Hotspot functionality authenticated by [pre-shared key],_**
โข
**_USB tethering authenticated by [no authentication]]_**
The administrator (using the TOEโs MDM APIs) can disable the Wi-Fi hotspot and USB
tethering.
Unless disabled by the administrator, TOE users can configure the Wi-Fi hotspot with
a pre-shared key and can configure USB tethering (with no authentication, though the
device must be unlocked to establish the initial tethering connection).|I|-|I|I|
+|42.|approve exceptions for sharing data between [**_groups of application_**]
The administrator (using the TOEโs MDM APIs) can specify grouping of applications to
restrict sharing data between the groups.|I|-|I|I|
+|43.|place applications into application process groups based on [**assignment**: _enterprise_
_configuration settings_]|||||
+
+
+52 of 100
+
+
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+
+
+
+
+
+
+
+
+
+|#|Management Function|Implemented|User Only|Admin|Admin Only|
+|---|---|---|---|---|---|
+|44.|unenroll the TOE from management
The administrator (using the TOEโs MDM APIs) or the user (using the TOEโs settings
UI) can choose to remove the TOE from management.|I|-|I|-|
+|45.|enable/disable the Always On VPN protection
โข
Across device
โข
[**_no other method_**]
The administrator (using the TOEโs MDM APIs) can specify whether a VPN connection
is required for the device to access any network services. The configuration would
specify the VPN connection(s) required.|I|-|I|I|
+|46.|revoke Biometric template|||||
+|47.|[**assignment**: _list of other management functions to be provided by the TSF_]|||||
+
+
+_**Table 16 - Security Management Functions**_
+
+
+_5.1.5.4_ _MOD_BT_V1.0:FMT_SMF_EXT.1/BT Specification of Management Functions_
+
+
+**FMT_SMF_EXT.1.1/BT**
+
+The TSF shall be capable of performing the following **Bluetooth** management functions:
+
+
+
+
+
+
+
+
+
+
+
+|#|Management Function|Implemented|User Only|Admin|Admin Only|
+|---|---|---|---|---|---|
+|BT-1.|Configure the Bluetooth trusted channel.
โข
Disable/enable the Discoverable (for BR/EDR) and Advertising (for LE)
modes;|M|I|||
+|BT-2.|Change the Bluetooth device name (separately for BR/EDR and LE);|||||
+|BT-3.|Provide separate controls for turning the BR/EDR and LE radios on and off;|||||
+|BT-4.|Allow/disallow the following additional wireless technologies to be used with
Bluetooth: [**selection**: _Wi-Fi, NFC, [_**_assignment_**_: other wireless technologies]_];|||||
+|BT-5.|Configure allowable methods of Out of Band pairing (for BR/EDR and LE);|||||
+|BT-6.|Disable/enable the Discoverable (for BR/EDR) and Advertising (for LE) modes
separately;|||||
+|BT-7.|Disable/enable the Connectable mode (for BR/EDR and LE);|||||
+|BT-8.|Disable/enable the Bluetooth [**assignment**: list of Bluetooth service and/or profiles
available on the OS (for BR/EDR and LE)]:|||||
+|BT-9.|Specify minimum level of security for each pairing (for BR/EDR and LE);|||||
+
+
+_**Table 17 - Bluetooth Security Management Functions**_
+
+
+
+53 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+_5.1.5.5_ _MOD_WLANC_V1.0:FMT_SMF.1/WLAN Specification of Management Functions_
+_(WLAN Client)_
+
+
+**FMT_SMF_EXT.1.1/WLAN**
+
+The TSF shall be capable of performing the following management functions:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+|#|Management Function|Implemented|Admin|User|
+|---|---|---|---|---|
+|WL-1.|configure security policy for each wireless network:
โข
[**_specify the CA(s) from which the TSF will accept WLAN authentication_**
**_server certificate(s)_**]
โข
security type
โข
authentication protocol
โข
client credentials to be used for authentication|M|M||
+|WL-2.|specify wireless networks (SSIDs) to which the TSF may connect;
An administrator can specify a list of wireless networks to which the TOE may
connect and can restrict the TOE to only allow a connection to the specified
networks.|M|M||
+|WL-3.|enable/disable disable wireless network bridging capability (for example, bridging a
connection between the WLAN and cellular radios to function as a hotspot)
authenticated by [**_pre-shared key_**]|M|M||
+|WL-4.|enable/disable certificate revocation list checking;||||
+|WL-5.|disable ad hoc wireless client-to-client connection capability||||
+|WL-6.|disable roaming capability;||||
+|WL-7.|enable/disable IEEE 802.1X pre-authentication;||||
+|WL-8.|loading X.509 certificates into the TOE||||
+|WL-9.|revoke X.509 certificates loaded into the TOE||||
+|WL-10.|
enable/disable and configure PMK caching:
โข
set the amount of time (in minutes) PMK entries are cached;
โข
set the maximum number of PMK entries that can be cached.||||
+|WL-11.|configure security policy for each wireless network: set wireless frequency band to
[**selection**: _2.4 GHz, 5 GHz, 6 GHz_]||||
+
+
+
+_**Table 18 - WLAN Security Management Functions**_
+
+
+(TD0667 applied)
+
+
+_5.1.5.6_ _PP_MDF_V3.3:FMT_SMF_EXT.2 Specification of Remediation Actions_
+
+
+**FMT_SMF_EXT.2.1**
+
+The TSF shall offer [ _**wipe of protected data, wipe of sensitive data, remove Enterprise**_
+_**applications, remove all device-stored Enterprise resource data**_ ] upon un-enrollment
+and [ _**factory reset**_ ].
+
+
+_5.1.5.7_ _PP_MDF_V3.3:FMT_SMF_EXT.3 Current Administrator_
+
+
+**FMT_SMF_EXT.3.1**
+
+
+54 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+The TSF shall provide a mechanism that allows users to view a list of currently
+authorized administrators and the management functions that each administrator is
+authorized to perform.
+
+
+_5.1.5.8_ _MOD_MDM_AGENT_V1.0:FMT_SMF_EXT.4 Specification of Management Functions_
+
+
+**FMT_SMF_EXT.4.1**
+
+The MDM Agent shall be capable of interacting with the platform to perform the
+following functions:
+
+ - [ _**import the server public key**_ ],
+
+ - [ _**administrator-provided management functions in MDF PP**_ ],
+
+ - [ _**no additional functions**_ ].
+**FMT_SMF_EXT.4.2**
+
+The MDM Agent shall be capable of performing the following functions:
+
+ - Enroll in management
+
+ - Configure whether users can unenroll from management
+
+ - [ _**no other functions**_ ].
+(TD0755 applied)
+
+
+_5.1.5.9_ _MOD_MDM_AGENT_V1.0:FMT_UNR_EXT.1 User Unenrollment Prevention_
+
+
+**FMT_UNR_EXT.1.1**
+
+The MDM Agent shall provide a mechanism to enforce the following behavior upon an
+attempt to unenroll the mobile device from management: [ _**prevent the unenrollment**_
+_**from occurring,**_ _**apply remediation actions**_ ].
+
+
+5.1.6 Protection of the TSF (FPT)
+
+
+_5.1.6.1_ _PP_MDF_V3.3:FPT_AEX_EXT.1 Application Address Space Layout Randomization_
+
+
+**FPT_AEX_EXT.1.1**
+
+The TSF shall provide address space layout randomization ASLR to applications.
+**FPT_AEX_EXT.1.2**
+
+The base address of any user-space memory mapping will consist of at least 8
+unpredictable bits.
+
+
+_5.1.6.2_ _PP_MDF_V3.3:FPT_AEX_EXT.2 Memory Page Permissions_
+
+
+**FPT_AEX_EXT.2.1**
+
+The TSF shall be able to enforce read, write, and execute permissions on every page of
+physical memory.
+
+
+_5.1.6.3_ _PP_MDF_V3.3:FPT_AEX_EXT.3 Stack Overflow Protection_
+
+
+**FPT_AEX_EXT.3.1**
+
+TSF processes that execute in a non-privileged execution domain on the application
+processor shall implement stack-based buffer overflow protection.
+
+
+55 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+_5.1.6.4_ _PP_MDF_V3.3:FPT_AEX_EXT.4 Domain Isolation_
+
+
+**FPT_AEX_EXT.4.1**
+
+The TSF shall protect itself from modification by untrusted subjects.
+**FPT_AEX_EXT.4.2**
+
+The TSF shall enforce isolation of address space between applications.
+
+
+_5.1.6.5_ _PP_MDF_V3.3:FPT_AEX_EXT.5 Kernel Address Space Layout Randomization_
+
+
+**FPT_AEX_EXT.5.1**
+
+The TSF shall provide address space layout randomization (ASLR) to the kernel.
+**FPT_AEX_EXT.5.2**
+
+The base address of any kernel-space memory mapping will consist of [ **13-25** ]
+unpredictable bits.
+
+
+_5.1.6.6_ _PP_MDF_V3.3:FPT_BBD_EXT.1 Application Processor Mediation_
+
+
+**FPT_BBD_EXT.1.1**
+
+The TSF shall prevent code executing on any baseband processor (BP) from accessing
+application processor (AP) resources except when mediated by the AP.
+
+
+_5.1.6.7_ _MOD_BIO_V1.1:FPT_BDP_EXT.1 Biometric data processing_
+
+
+**FPT_BDP_EXT.1.1**
+
+Processing of plaintext biometric data shall be inside the SEE in runtime.
+**FPT_BDP_EXT.1.2**
+
+Transmission of plaintext biometric data between the capture sensor and the SEE shall
+be isolated from the main computer operating system on the TSF in runtime.
+
+
+_5.1.6.8_ _PP_MDF_V3.3:FPT_JTA_EXT.1 JTAG Disablement_
+
+
+**FPT_JTA_EXT.1.1**
+
+The TSF shall [ _**control access by a signing key**_ ] to JTAG.
+
+
+_5.1.6.9_ _PP_MDF_V3.3 & MOD_BIO_V1.1:FPT_KST_EXT.1 Key Storage_
+
+
+**FPT_KST_EXT.1.1**
+
+The TSF shall not store any plaintext key material **or biometric data** in readable nonvolatile memory.
+
+
+_5.1.6.10_ _PP_MDF_V3.3 & MOD_BIO_V1.1:FPT_KST_EXT.2 No Key Transmission_
+
+
+**FPT_KST_EXT.2.1**
+
+The TSF shall not transmit any plaintext key material **or biometric data** outside the
+security boundary of the TOE.
+
+
+_5.1.6.11_ _PP_MDF_V3.3:FPT_KST_EXT.3 No Plaintext Key Export_
+
+
+**FPT_KST_EXT.3.1**
+
+The TSF shall ensure it is not possible for the TOE users to export plaintext keys.
+
+
+56 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+_5.1.6.12_ _PP_MDF_V3.3:FPT_NOT_EXT.1 Self-Test Notification_
+
+
+**FPT_NOT_EXT.1.1**
+
+The TSF shall transition to non-operational mode and [ _**no other actions**_ ] when the
+following types of failures occur:
+
+ - failures of the self-tests
+
+ - TSF software integrity verification failures
+
+ - [ _**no other failures**_ ]
+
+
+_5.1.6.13_ _MOD_BIO_V1.1:FPT_PBT_EXT.1 Protection of biometric template_
+
+
+**FPT_PBT_EXT.1.1**
+
+The TSF shall protect the biometric template [ _**using a password as an additional factor**_ ].
+(TD0714 applied)
+
+
+_5.1.6.14_ _PP_MDF_V3.3:FPT_STM.1 Reliable time stamps_
+
+
+**FPT_STM.1.1**
+
+The TSF shall be able to provide reliable time stamps for its own use.
+
+
+_5.1.6.15_ _PP_MDF_V3.3:FPT_TST_EXT.1 TSF Cryptographic Functionality Testing_
+
+
+**FPT_TST_EXT.1.1**
+
+The TSF shall run a suite of self-tests during initial start-up (on power on) to
+demonstrate the correct operation of all cryptographic functionality.
+
+
+_5.1.6.16_ _PP_MDF_V3.3:FPT_TST_EXT.2/PREKERNEL TSF Integrity Checking (Pre-Kernel)_
+
+
+**FPT_TST_EXT.2.1/PREKERNEL**
+
+The TSF shall verify the integrity of [the bootchain up through the Application Processor
+OS kernel] stored in mutable media prior to its execution through the use of [ _**an**_
+_**immutable hardware hash of an asymmetric key**_ ].
+
+
+_5.1.6.17_ _PP_MDF_V3.3:FPT_TST_EXT.2/POSTKERNEL TSF Integrity Checking (Post-Kernel)_
+
+
+**FPT_TST_EXT.2.1/POSTKERNEL**
+
+The TSF shall verify the integrity of [ _**[executable code stored in the /system and /vendor**_
+_**partitions]**_ ], stored in mutable media prior to its execution through the use of [ _**an**_
+_**immutable hardware hash of an asymmetric key**_ ].
+
+
+_5.1.6.18_ _MOD_WLANC_V1.0:FPT_TST_EXT.3/WLAN TSF Cryptographic Functionality Testing_
+_(WLAN Client)_
+
+
+**FPT_TST_EXT.3.1/WLAN**
+
+The [ _**TOE platform**_ ] shall run a suite of self-tests during initial start-up (on power on) to
+demonstrate the correct operation of the TSF.
+**FPT_TST_EXT.3.2/WLAN**
+
+
+57 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+The [ _**TOE platform**_ ] shall provide the capability to verify the integrity of stored TSF
+executable code when it is loaded for execution through the use of the TSF-provided
+cryptographic services.
+
+
+_5.1.6.19_ _PP_MDF_V3.3:FPT_TUD_EXT.1 Trusted Update: TSF Version Query_
+
+
+**FPT_TUD_EXT.1.1**
+
+The TSF shall provide authorized users the ability to query the current version of the
+TOE firmware/software.
+**FPT_TUD_EXT.1.2**
+
+The TSF shall provide authorized users the ability to query the current version of the
+hardware model of the device.
+**FPT_TUD_EXT.1.3**
+
+The TSF shall provide authorized users the ability to query the current version of
+installed mobile applications.
+
+
+_5.1.6.20_ _PP_MDF_V3.3:FPT_TUD_EXT.2 TSF Update Verification_
+
+
+**FPT_TUD_EXT.2.1**
+
+The TSF shall verify software updates to the Application Processor system software and
+
+[ _**[baseband processor]**_ ] using a digital signature verified by the manufacturer trusted
+key prior to installing those updates.
+**FPT_TUD_EXT.2.2**
+
+The TSF shall [ _**update only by verified software**_ ] the TSF boot integrity [ _**key**_ ].
+**FPT_TUD_EXT.2.3**
+
+The TSF shall verify that the digital signature verification key used for TSF updates
+
+[ _**matches an immutable hardware public key**_ ].
+
+
+_5.1.6.21_ _PP_MDF_V3.3:FPT_TUD_EXT.3 Application Signing_
+
+
+**FPT_TUD_EXT.3.1**
+
+The TSF shall verify mobile application software using a digital signature mechanism
+prior to installation.
+
+
+_5.1.6.22_ _PP_MDF_V3.3:FPT_TUD_EXT.6 Trusted Update Verification_
+
+
+**FPT_TUD_EXT.6.1**
+
+The TSF shall verify that software updates to the TSF are a current or later version than
+the current version of the TSF.
+
+
+5.1.7 TOE Access (FTA)
+
+
+_5.1.7.1_ _PP_MDF_V3.3:FTA_SSL_EXT.1 TSF- and User-initiated Locked State_
+
+
+**FTA_SSL_EXT.1.1**
+
+The TSF shall transition to a locked state after a time interval of inactivity.
+**FTA_SSL_EXT.1.2**
+
+
+58 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+The TSF shall transition to a locked state after initiation by either the user or the
+administrator.
+**FTA_SSL_EXT.1.3**
+
+The TSF shall, upon transitioning to the locked state, perform the following operations:
+
+ - Clearing or overwriting display devices, obscuring the previous contents;
+
+ - [ _**no other actions**_ ].
+
+
+_5.1.7.2_ _PP_MDF_V3.3:FTA_TAB.1 Default TOE Access Banners_
+
+
+**FTA_TAB.1.1**
+
+Before establishing a user session, the TSF shall display an advisory warning message
+regarding unauthorized use of the TOE.
+
+
+_5.1.7.3_ _MOD_WLANC_V1.0:FTA_WSE_EXT.1 Wireless Network Access_
+
+
+**FTA_WSE_EXT.1.1**
+
+The TSF shall be able to attempt connections only to wireless networks specified as
+acceptable networks as configured by the administrator in FMT_SMF.1.1/WLAN.
+
+
+5.1.8 Trusted Path/Channels (FTP)
+
+
+_5.1.8.1_ _MOD_BT_V1.0:FTP_BLT_EXT.1 Bluetooth Encryption_
+
+
+**FTP_BLT_EXT.1.1**
+
+The TSF shall enforce the use of encryption when transmitting data over the Bluetooth
+trusted channel for BR/EDR and [ _**LE**_ ].
+**FTP_BLT_EXT.1.2**
+
+The TSF shall use key pairs per FCS_CKM_EXT.8 for Bluetooth encryption.
+
+
+_5.1.8.2_ _MOD_BT_V1.0:FTP_BLT_EXT.2 Persistence of Bluetooth Encryption_
+
+
+**FTP_BLT_EXT.2.1**
+
+The TSF shall [ _**terminate the connection**_ ] if the remote device stops encryption while
+connected to the TOE.
+
+
+_5.1.8.3_ _MOD_BT_V1.0:FTP_BLT_EXT.3/BR Bluetooth Encryption Parameters (BR/EDR)_
+
+
+**FTP_BLT_EXT.3.1/BR**
+
+The TSF shall set the minimum encryption key size to [ **128 bits** ] for [ _BR/EDR_ ] and not
+negotiate encryption key sizes smaller than the minimum size.
+
+
+_5.1.8.4_ _MOD_BT_V1.0:FTP_BLT_EXT.3/LE Bluetooth Encryption Parameters (LE)_
+
+
+**FTP_BLT_EXT.3.1/LE**
+
+The TSF shall set the minimum encryption key size to [ **128 bits** ] for [ _LE_ ] and not
+negotiate encryption key sizes smaller than the minimum size.
+
+
+_5.1.8.5_ _MOD_WLANC_V1.0:FTP_ITC.1/WLAN Trusted Channel Communication (Wireless LAN)_
+
+
+**FTP_ITC.1.1/WLAN**
+
+
+59 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+The TSF shall use 802.11-2012, 802.1X, and EAP-TLS to provide a trusted communication
+channel between itself and a wireless access point that is logically distinct from other
+communication channels and provides assured identification of its end points and
+protection of the channel data from modification or disclosure.
+**FTP_ITC.1.2/WLAN**
+
+The TSF shall permit [the TSF] to initiate communication via the trusted channel.
+**FTP_ITC.1.3/WLAN**
+
+The TSF shall initiate communication via the trusted channel for [wireless access point
+connections].
+
+
+_5.1.8.6_ _PP_MDF_V3.3:FTP_ITC_EXT.1 Trusted Channel Communication_
+
+
+**FTP_ITC_EXT.1.1**
+
+The TSF shall use
+
+ - 802.11-2012 in accordance with the [PP-Module for Wireless LAN Clients, version
+1.0],
+
+ - 802.1X in accordance with the [PP-Module for Wireless LAN Clients, version 1.0],
+
+ - EAP-TLS in accordance with the [PP-Module for Wireless LAN Clients, version 1.0],
+
+ - mutually authenticated TLS in accordance with [the Functional Package for
+Transport Layer Security (TLS), version 1.1]
+and [
+
+ - _**HTTPS**_
+] protocols to provide a communication channel between itself and another trusted IT
+product that is logically distinct from other communication channels, provides assured
+identification of its end points, protects channel data from disclosure, and detects
+modification of the channel data.
+**FTP_ITC_EXT.1.2**
+
+The TSF shall permit the TSF to initiate communication via the trusted channel.
+**FTP_ITC_EXT.1.3**
+
+The TSF shall initiate communication via the trusted channel for wireless access point
+connections, administrative communication, configured enterprise connections, and
+
+[ _**OTA updates**_ ].
+
+
+_5.1.8.7_ _MOD_MDM_AGENT_V1.0:FTP_ITC_EXT.1(2) Trusted Channel Communication_
+
+
+**FTP_ITC_EXT.1.1(2)**
+
+**Refinement:** The TSF shall use [ _**HTTPS**_ ] to provide a communication channel between
+itself and another trusted IT product that is logically distinct from other communication
+channels, provides assured identification of its end points, protects channel data from
+disclosure, and detects modification of the channel data.
+**FTP_ITC_EXT.1.2(2)**
+
+**Refinement:** The TSF shall permit the TSF and the MDM Server and [ _**no other IT entities**_ ]
+to initiate communication via the trusted channel
+**FTP_ITC_EXT.1.3(2)**
+
+
+60 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+**Refinement:** The TSF shall initiate communication via the trusted channel for all
+communication between the MDM Agent and the MDM Server and [ _**no other**_
+_**communication**_ ].
+
+
+_5.1.8.8_ _MOD_MDM_AGENT_V1.0:FTP_TRP.1(2) Trusted Path (for Enrollment)_
+
+
+**FTP_TRP.1.1(2)**
+
+**Refinement:** The TSF shall use [ _**HTTPS**_ ] to provide a trusted communication path
+between itself and another trusted IT product that is logically distinct from other
+communication paths and provides assured identification of its endpoints and
+protection of the communicated data from disclosure and detection of modification of
+the communicated data from [ _modification, disclosure_ ].
+**FTP_TRP.1.2(2)**
+
+**Refinement:** The TSF shall permit MD users to initiate communication via the trusted
+path.
+**FTP_TRP.1.3(2)**
+
+**Refinement:** The TSF shall require the use of the trusted path for [ _[all MD user actions]_ ].
+
+### 5.2 TOE Security Assurance Requirements
+
+
+The SARs for the TOE are the components as specified in Part 3 of the Common Criteria. Note that the
+SARs have effectively been refined with the assurance activities explicitly defined in association with
+both the SFRs and SARs.
+
+|Requirement Class|Requirement Component|
+|---|---|
+|ADV: Development|ADV_FSP.1: Basic Functional Specification|
+|AGD: Guidance documents|AGD_OPE.1: Operational User Guidance|
+|AGD: Guidance documents|AGD_PRE.1: Preparative Procedures|
+|ALC: Life-cycle support|ALC_CMC.1: Labelling of the TOE|
+|ALC: Life-cycle support|ALC_CMS.1: TOE CM Coverage|
+|ALC: Life-cycle support|ALC_TSU_EXT.1: Timely Security Updates|
+|ATE: Tests|ATE_IND.1: Independent Testing - Conformance|
+|AVA: Vulnerability assessment|AVA_VAN.1: Vulnerability Survey|
+
+
+
+_**Table 19 - Assurance Components**_
+
+
+5.2.1 Development (ADV)
+
+
+_5.2.1.1_ _ADV_FSP.1 Basic Functional Specification_
+
+
+**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.
+**ADV_FSP.1.1C**
+
+The functional specification shall describe the purpose and method of use for each SFRenforcing and SFR-supporting TSFI.
+**ADV_FSP.1.2C**
+
+
+61 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+The functional specification shall identify all parameters associated with each SFRenforcing and SFR-supporting TSFI.
+**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.
+**ADV_FSP.1.1E**
+
+The evaluator shall confirm that the information provided meets all requirements for
+content and presentation of evidence.
+**ADV_FSP.1.2E**
+
+The evaluator shall determine that the functional specification is an accurate and
+complete instantiation of the SFRs.
+
+
+5.2.2 Guidance Documents (AGD)
+
+
+_5.2.2.1_ _AGD_OPE.1 Operational User Guidance_
+
+
+**AGD_OPE.1.1D**
+
+The developer shall provide operational user guidance.
+**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, in particular 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 measures
+to be followed in order to fulfill the security objectives for the operational environment
+as described in the ST.
+
+
+62 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+**AGD_OPE.1.7C**
+
+The operational user guidance shall be clear and reasonable.
+**AGD_OPE.1.1E**
+
+The evaluator shall confirm that the information provided meets all requirements for
+content and presentation of evidence.
+
+
+_5.2.2.2_ _AGD_PRE.1 Preparative Procedures_
+
+
+**AGD_PRE.1.1D**
+
+The developer shall provide the TOE, including its preparative procedures.
+**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.
+**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.3 Life-cycle support (ALC)
+
+
+_5.2.3.1_ _ALC_CMC.1 Labeling of the TOE_
+
+
+**ALC_CMC.1.1D**
+
+The developer shall provide the TOE and a reference for the TOE.
+**ALC_CMC.1.1C**
+
+The TOE shall be labelled with its unique reference.
+**ALC_CMC.1.1E**
+
+The evaluator shall confirm that the information provided meets all requirements for
+content and presentation of evidence.
+
+
+_5.2.3.2_ _ALC_CMS.1 TOE CM Coverage_
+
+
+**ALC_CMS.1.1D**
+
+The developer shall provide a configuration list for the TOE.
+**ALC_CMS.1.1C**
+
+The configuration list shall include the following: the TOE itself; and the evaluation
+evidence required by the SARs.
+**ALC_CMS.1.2C**
+
+The configuration list shall uniquely identify the configuration items.
+**ALC_CMS.1.1E**
+
+
+63 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+The evaluator shall confirm that the information provided meets all requirements for
+content and presentation of evidence.
+
+
+_5.2.3.3_ _ALC_TSU_EXT.1 Timely Security Updates_
+
+
+**ALC_TSU_EXT.1.1D**
+
+The developer shall provide a description in the TSS of how timely security updates are
+made to the TOE.
+**ALC_TSU_EXT.1.1C**
+
+The description shall include the process for creating and deploying security updates for
+the TOE software.
+**ALC_TSU_EXT.1.2C**
+
+The description shall express the time window as the length of time, in days, between
+public disclosure of a vulnerability and the public availability of security updates to the
+TOE.
+**ALC_TSU_EXT.1.3C**
+
+The description shall include the mechanisms publicly available for reporting security
+issues pertaining to the TOE.
+**ALC_TSU_EXT.1.4C**
+
+The description shall include where users can seek information about the availability of
+new updates including details (e.g. CVE identifiers) of the specific public vulnerabilities
+corrected by each update.
+**ALC_TSU_EXT.1.1E**
+
+The evaluator shall confirm that the information provided meets all requirements for
+content and presentation of evidence.
+
+
+5.2.4 Tests (ATE)
+
+
+_5.2.4.1_ _ATE_IND.1 Independent Testing - Conformance_
+
+
+**ATE_IND.1.1D**
+
+The developer shall provide the TOE for testing.
+**ATE_IND.1.1C**
+
+The TOE shall be suitable for testing.
+**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.5 Vulnerability assessment (AVA)
+
+
+_5.2.5.1_ _AVA_VAN.1 Vulnerability Survey_
+
+
+**AVA_VAN.1.1D**
+
+The developer shall provide the TOE for testing.
+
+
+64 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+**AVA_VAN.1.1C**
+
+The TOE shall be suitable for testing.
+**AVA_VAN.1.1E**
+
+The evaluator shall confirm that the information provided meets all requirements for
+content and presentation 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 possessing Basic attack potential.
+
+
+65 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+## 6 TOE Summary Specification
+
+
+This chapter describes the security functions:
+
+ - Security audit
+
+ - Cryptographic support
+
+ - User data protection
+
+ - Identification and authentication
+
+ - Security management
+
+ - Protection of the TSF
+
+ - TOE access
+
+ - Trusted path/channels
+
+### 6.1 Security audit
+
+
+**MOD_MDM_AGENT_V1.0:FAU_ALT_EXT.2:**
+The TOE utilizes a server-initiated communications mechanism for communications to the MDM Server.
+Once the TOE starts, the Device Policy application (the MDM Agent service) will connect to the server to
+register its availability and will then only connect again based on notifications from the MDM Server.
+When a policy is retrieved, the Device Policy application will send a notification to be delivered back to
+the MDM Server to register the successful (or unsuccessful) application of the policy.
+
+
+If the connection to the MDM Server is not available when the Device Policy application attempts to
+send a policy status update, the notification will be queued until connectivity is restored at which time
+the notification will be delivered. A policy status update includes the current status of all policies that
+are applied (so a single update would include the current status of all the settings included in the policy).
+If the current status of a policy changes (for example, a password was not in compliance at the time the
+policy was applied but then the user later changes the password to bring it into compliance), the policy
+status update will be changed to note that the current status is now compliant.
+
+
+The policy status update does not have any specific storage constraints as there is only a single policy
+status update that maintains the current status of all policies. The queue on a per-policy basis is one,
+such that only the current status of the policy is maintained (so if a policy was listed as compliant, then
+non-compliant and then again compliant, only the current state, in this case compliant, would be
+reported in the queue).
+
+
+All connections are made over a trusted channel. If the trusted channel is not available, notifications will
+be cached until it is available (such as going offline after downloading a policy).
+
+
+**PP_MDF_V3.3:FAU_GEN.1:**
+**MOD_BT_V1.0:FAU_GEN.1/BT:**
+**MOD_WLANC_V1.0:FAU_GEN.1/WLAN:**
+**MOD_MDM_AGENT_V1.0:FAU_GEN.1(2):**
+The TOE uses different forms of logs to meet all the required management logging events specified in
+Table 2 and Table 3 of the PP_MDF_V3.3, Table 2 of the MOD_BT_V1.0 and Table 2 of the
+MOD_WLANC_V1.0:
+
+66 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+1. SecurityLog events
+2. Logcat events
+Each of the above logging methods are described below.
+
+ - _SecurityLog events_ : A full list of all auditable events can be found here:
+[https://developer.android.com/reference/android/app/admin/SecurityLog#constants_1. Values](https://developer.android.com/reference/android/app/admin/SecurityLog#constants_1)
+found in this list represent SecurityLog keywords used in this logging function along with a
+description of what the log means and any additional information/variables present in the audit
+record. Additionally, the following link provides the additional information that can be grabbed
+when an MDM requests a copy of the logs:
+[https://developer.android.com/reference/android/app/admin/SecurityLog.SecurityEvent. Each](https://developer.android.com/reference/android/app/admin/SecurityLog.SecurityEvent)
+log contains a keyword or phrase describing the event, the date and time of the event, and
+further event-specific values that provide success, failure, and other information relevant to the
+event.
+
+ - _Logcat events:_ Similar to SecurityLog events, logcat events contain date, time, and further evenspecific values within the logs. In addition, logcat events provide a value that maps to a user ID
+to identify which user caused the event that generated the log. Finally, logcat events are
+descriptive and do not require the administrator to know the template of the log to understand
+its values. Logcat events cannot be exported but can be viewed by an administrator via an
+MDM agent.
+The logs, when full, wrap around and overwrite the oldest log (as the start of the buffer).
+
+
+The Device Policy application (MDM Agent service) has sufficient permissions to allow it to write events
+to Logcat. The WLAN client components are integrated into the operating system and write directly to
+the SecurityLog and Logcat (as needed).
+
+
+The following tables enumerate the events that the TOE audits:
+
+|Protection Profile|Table|
+|---|---|
+|PP_MDF_V3.3|Mandatory - Table 12 - PP_MDF_V3.3 Audit Events|
+|MOD_BT_V1.0|Table 13 - MOD_BT_V1.0 Audit Events|
+|MOD_WLANC_V1.0|Table 14 - MOD_WLANC_V1.0 Audit Events|
+|MOD_MDM_AGENT_V1.0|Table 15 - MOD_MDM_AGENT_V1.0 Audit Events|
+
+
+
+_**Table 20 - Audit Event Table References**_
+
+
+The details of the events audited are included in section 9 of the Admin Guide.
+
+
+Some audit records, while logged, are unavailable to the administrator due to a number of reasons. Such
+audits and their explanations are identified below:
+
+ - (ALL) FAU_GEN.1 โ Shutdown of the audit functions: Upon log shutdown, the security log buffer
+is deallocated and no longer available to be read, rendering the viewing of such an audit
+unavailable for the administrator to view.
+
+ - PP_MDF_V3.3:FAU_GEN.1 โ Shutdown of the Rich OS: Since security logs are stored in memory,
+a shutdown of the system clears the audit record that is generated stating that the system is
+shutting down.
+
+ - PP_MDF_V3.3:FPT_TST_EXT.1 โ Failure of self-test: Self-tests take place prior to the initialization
+of audit records. While the self-test success/failure audit is queued up to be logged upon
+
+67 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+security logs being initialized, when a self-test failure occurs the boot process is halted prior to
+security logs being initialized.
+**PP_MDF_V3.3:FAU_SAR.1:**
+The TOE provides an MDM API to allow a Device-Owner MDM agent to read the security logs.
+
+
+**MOD_MDM_AGENT_V1.0:FAU_SEL.1(2):**
+The TOE always logs all events into the available services, the SecurityLog or Logcat as specified in
+FAU_GEN.1. This ensures that events are always available for review where they can be filtered by the
+logging service of the MDM Server.
+
+
+**PP_MDF_V3.3:FAU_STG.1:**
+For security logs, the TOE stores all audit records in memory, making it only accessible to the logd
+daemon, and only device owner applications can call the MDM API to retrieve a copy of the logs.
+Additionally, only new logs can be added. There is no designated method allowing for the deletion or
+modification of logs already present in memory, but reading the security logs clears the buffer at the
+time of the read.
+
+
+The TOE stores logcat events in memory and only allows access by an administrator via an MDM Agent.
+The TOE prevents deletion of these logs by any method other than USB debugging (and enabling USB
+Debugging takes the phone out of the evaluated configuration).
+
+
+**PP_MDF_V3.3:FAU_STG.4:**
+The SecurityLog and logcat are stored in memory in a circular log buffer of 10KB/64KB, respectively.
+Logcat storage is configurable, able to be set by an MDM API. There is no limit to the size that the logcat
+buffer can be configured to and it is limited to the size of the systemโs memory. Once the log is full, it
+begins overwriting the oldest message in its respective buffer and continues overwriting the oldest
+message with each new auditable event. These logs persist until either they are overwritten or the
+device is restarted.
+
+### 6.2 Cryptographic support
+
+
+**PP_MDF_V3.3:FCS_CKM.1:**
+The TOE provides generation of asymmetric keys including:
+
+|Algorithm|Key/Curve Sizes|Usage|
+|---|---|---|
+|RSA, FIPS 186-5|2048/3072/4096|API/Application & Sensitive Data Protection
(FDP_DAR_EXT.2)|
+|ECDSA, FIPS 186-5|P-256/384/521|API/Application|
+|ECDHE keys (not domain parameters)|P-256/384|TLS KeyEx (WPA2/WPA3 w/ EAP-TLS & HTTPS)|
+
+
+
+_**Table 21 - Asymmetric Key Generation**_
+
+
+The TOEโs cryptographic algorithm implementations have received NIST algorithm certificates (see the
+tables in FCS_COP.1 for all of the TOEโS algorithm certificates). The TOE itself does not generate any
+RSA/ECDSA authentication key pairs for TOE functionality (the user or administrator must load
+certificates for use with WPA2/WPA3 with EAP-TLS authentication); however, the TOE provides key
+generation APIs to mobile applications to allow them to generate RSA/ECDSA key pairs. The TOE
+generates only ECDH key pairs (as BoringSSL does not support DH/DHE cipher suites) and does not
+generate domain parameters (curves) for use in TLS Key Exchange.
+
+
+68 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+The TOE will provide a library for application developers to use for Sensitive Data Protection (SDP). This
+library (class) generates asymmetric RSA keys for use to encrypt and decrypt data that comes to the
+device while in a locked state. Any data received for a specified application (that opts into SDP via this
+library), is encrypted using the public key and stored until the device is unlocked. The public key stays in
+memory no matter the state of the device (locked or unlocked). However, when the device is locked, the
+private key is evicted from memory and unavailable for use until the device is unlocked. Upon unlock,
+the private key is re-derived and used to decrypt data received and encrypted while locked.
+
+
+**MOD_WLANC_V1.0:FCS_CKM.1/WPA:**
+The TOE adheres to IEEE 802.11-2012 for key generation. The TOEโs wpa_supplicant provides PRF384,
+PRF512 and PRF704 for derivation of 128-bit, 192-bit and 256-bit AES Temporal Keys (using the HMAC
+implementation provided by BoringSSL) and employs its BoringSSL AES-256 DRBG when generating
+random values used in the EAP-TLS and 802.11 4-way handshake. The TOE supports the AES-128 CCMP
+and AES-192/AES-256 GCMP encryption modes. The TOE has successfully completed certification
+(including WPA2/WPA3 Enterprise) and received Wi-Fi CERTIFIED Interoperability Certificates from the
+Wi-Fi Alliance. The Wi-Fi Alliance maintains a website providing further information about the testing
+[program: http://www.wi-fi.org/certification.](http://www.wi-fi.org/certification)
+
+|Device Name|Model Number|Wi-Fi Alliance Certificate Numbers|
+|---|---|---|
+|Pixel 9 Pro XL|GZC4K, GQ57S, GGX8B|WFA131513|
+|Pixel 9 Pro|GEC77, GWVK6, GR83Y|WFA131514|
+|Pixel 9|GUR25, G1B60, G2YBB|WFA129269|
+|Pixel 9 Pro Fold|GGH2X, GC15S|WFA131515|
+|Pixel 9a|GXQ96, GTF7P, G3Y12|WFA132581|
+|Pixel 8 Pro|G1NMW, GC3VE|WFA125104|
+|Pixel 8|GKWS6, G9BQD|WFA127396|
+|Pixel 8a|G5760D, G6GPR, G8HHN|WFA127250|
+|Pixel Tablet|GTU8P|WFA117213|
+|Pixel Fold|G9FPL, G0B96|WFA124381|
+|Pixel 7 Pro|GVU6C, G03Z5, GQML3|WFA119877, WFA119869|
+|Pixel 7|GE2AE, GFE4J, GP4BC|WFA119878, WFA119753|
+|Pixel 7a|GWKK3, GHL1X, G82U8, G0DZQ|WFA120585, WFA124403|
+|Pixel 6 Pro|GF5KQ, G8V0U, GLU0G|WFA113888, WFA113887|
+|Pixel 6|GR1YH, GB7N6, G9S9B|WFA113889, WFA111718|
+|Pixel 6a|GX7AS, GB62Z, G1AZG, GB17L|WFA117809, WFA117592|
+
+
+
+_**Table 22 - Wi-Fi Alliance Certificates**_
+
+
+**PP_MDF_V3.3:FCS_CKM.2/UNLOCKED:**
+The TOE performs key establishment as a client during EAP-TLS and TLS session establishment. Table 21 Asymmetric Key Generation enumerates the TOEโs supported key establishment implementations
+(RSA/ECDH for TLS/EAP-TLS). The RSA key exchange mechanism used in the TLS handshake process
+undergoes TLS compatibility testing during TOE development to ensure correct implementation.
+
+
+**PP_MDF_V3.3:FCS_CKM.2.1/LOCKED:**
+The TOE provides an SDP library for applications that uses a hybrid crypto scheme based on 4096-bit
+RSA based key establishment. Applications can utilize this library to implement SDP that encrypts
+incoming data received while the phone is locked in a manner compliant with this requirement.
+
+
+**MOD_WLANC_V1.0:FCS_CKM.2/WLAN:**
+
+69 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+The TOE adheres to RFC 3394 and 802.11-2012 standards and unwraps the GTK (sent encrypted with the
+WPA2/WPA3 KEK using AES Key Wrap in an EAPOL-Key frame). The TOE, upon receiving an EAPOL
+frame, will subject the frame to a number of checks (frame length, EAPOL version, frame payload size,
+EAPOL-Key type, key data length, EAPOL-Key CCMP descriptor version, and replay counter) to ensure a
+proper EAPOL message and then decrypt the GTK using the KEK, thus ensuring that it does not expose
+the Group Temporal Key (GTK).
+
+
+**PP_MDF_V3.3:FCS_CKM_EXT.1:**
+The TOE includes a Root Encryption Key (REK) stored in a 256-bit fuse bank within the application
+processor. The TOE generates the REK/fuse value during manufacturing using its hardware DRBG. The
+application processor protects the REK by preventing any direct observation of the value and prohibiting
+any ability to modify or update the value. The application processor loads the fuse value into an internal
+hardware crypto register and the Trusted Execution Environment (TEE) provides trusted applications the
+ability to derive KEKs from the REK (using an SP 800-108 KDF to combine the REK with a salt).
+Additionally, the when the REK is loaded, the fuses for the REK become locked, preventing any further
+changing or loading of the REK value. The TEE does not allow trusted applications to use the REK for
+encryption or decryption, only the ability to derive a KEK from the REK. The TOE includes a TEE
+application that calls into the TEE in order to derive a KEK from the 256-bit REK/fuse value and then only
+permits use of the derived KEK for encryption and decryption as part of the TOE key hierarchy. More
+[information regarding Trusted Execution Environments may be found at the GlobalPlatform website.](https://globalplatform.org/)
+
+
+**PP_MDF_V3.3:FCS_CKM_EXT.2:**
+The TOE utilizes its approved RBGs to generate DEKs. When generating AES keys for itself (for example,
+the TOEโs sensitive data encryption keys or for the Secure Key Storage), the TOE utilizes the
+RAND_bytes() API call from its BoringSSL AES-256 CTR_DRBG to generate a 256-bit AES key. The TOE
+also utilizes that same DRBG when servicing API requests from mobile applications wishing to generate
+AES keys (either 128 or 256-bit).
+
+
+In all cases, the TOE generates DEKs using a compliant RBG seeded with sufficient entropy so as to
+ensure that the generated key cannot be recovered with less work than a full exhaustive search of the
+key space.
+
+
+**PP_MDF_V3.3:FCS_CKM_EXT.3:**
+The TOE takes the user-entered password and conditions/stretches this value before combining the
+factor with other KEK.
+
+
+The TOE generates all non-derived KEKs using the RAND_bytes() API call from its BoringSSL AES-256
+CTR_DRBG to ensure a full 128/256-bits of strength for asymmetric/symmetric keys, respectively. And
+the TOE combines KEKs by encrypting one KEK with the other so as to preserve entropy.
+
+
+**PP_MDF_V3.3:FCS_CKM_EXT.4:**
+The TOE clears sensitive cryptographic material (plaintext keys, authentication and biometric data, and
+other security parameters) from memory when no longer needed or when transitioning to the deviceโs
+locked state (in the case of the Sensitive Data Protection keys). Public keys (such as the one used for
+Sensitive Data Protection) can remain in memory when the phone is locked, but all crypto-related
+private keys are evicted from memory upon device lock. No plaintext cryptographic material resides in
+the TOEโs Flash as the TOE encrypts all keys stored in Flash. When performing a full wipe of protected
+data, the TOE cryptographically erases the protected data by clearing the Data-At-Rest DEK. Because the
+
+
+70 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+Android Keystore of the TOE resides within the user data partition, the TOE effectively cryptographically
+erases those keys when clearing the Data-At-Rest DEK. In turn, the TOE clears the Data-At-Rest DEK and
+Secure Key Storage SEK through a secure direct overwrite (BLKSECDISCARD ioctl) of the wear-leveled
+Flash memory containing the key followed by a read-verify.
+
+
+**PP_MDF_V3.3:FCS_CKM_EXT.5:**
+The TOE stores all protected data in encrypted form within the user data partition (either protected data
+or sensitive data). Upon request, the TOE cryptographically erases the Data-At-Rest DEK protecting the
+user data partition and the SDP Primary KEK protecting sensitive data files in the user data partition,
+clears those keys from memory, reformats the partition, and then reboots. The TOEโs clearing of the
+keys follows the requirements of FCS_CKM_EXT.4.
+
+
+**PP_MDF_V3.3:FCS_CKM_EXT.6:**
+The TOE generates salt nonces (which are just salt values used in WPA2/WPA3) using its /dev/urandom.
+
+|Salt value and size|RBG origin|Salt storage location|
+|---|---|---|
+|User password salt (128-bit)|BoringSSLโs AES-256 CTR_DRBG|Flash filesystem|
+|TLS client_random (256-bit)|BoringSSLโs AES-256 CTR_DRBG|N/A (ephemeral)|
+|TLS pre_master_secret (384-bit)|BoringSSLโs AES-256 CTR_DRBG|N/A (ephemeral)|
+|WPA2/WPA3 4-way handshake supplicant nonce
(SNonce)|BoringSSLโs AES-256 CTR_DRBG|N/A (ephemeral)|
+
+
+
+_**Table 23 - Salt Nonces**_
+
+
+**MOD_BT_V1.0:FCS_CKM_EXT.8**
+The TOE generates new ECDH key pairs every time a connection with a Bluetooth device is established.
+
+
+**PP_MDF_V3.3:FCS_COP.1/ENCRYPT:**
+**PP_MDF_V3.3:FCS_COP.1/HASH:**
+**PP_MDF_V3.3:FCS_COP.1/SIGN:**
+**PP_MDF_V3.3:FCS_COP.1/KEYHMAC:**
+**PP_MDF_V3.3:FCS_COP.1/CONDITION:**
+The TOE implements cryptographic algorithms in accordance with the following NIST standards and has
+received the following CAVP algorithm certificates. These algorithms are in software and hardware,
+depending on the implementation.
+
+
+The TOEโs BoringSSL Library (version 20240805 with both Processor Algorithm Accelerators (PAA) and
+without PAA) provides the following algorithms as validated on Android 15:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+|SFR|Algorithm|Keys|NIST Standard|Cert#|
+|---|---|---|---|---|
+|FCS_CKM.1|RSA IFC Key Generation|2048,
3072,
4096|FIPS 186-5, RSA|A6134|
+|FCS_CKM.1|ECDSA ECC Key Generation|P256,
P384,
P521|FIPS 186-5, ECDSA|FIPS 186-5, ECDSA|
+|FCS_CKM.2|RSA-based Key Exchange||Tested with known good
implementation.|Tested with known good
implementation.|
+|FCS_CKM.2|ECC-based Key Exchange|P256,
P384,
P521|SP 800-56A, CVL KAS ECC|SP 800-56A, CVL KAS ECC|
+
+
+
+71 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+
+
+
+
+
+
+
+
+
+|SFR|Algorithm|Keys|NIST Standard|Cert#|
+|---|---|---|---|---|
+|FCS_COP.1/ENCRYPT|AES CBC, GCM, KW|128/256|FIPS 197, SP 800-38A/D/F||
+|FCS_COP.1/HASH|SHA Hashing|1/256/
384/512|FIPS 180-4|FIPS 180-4|
+|FCS_COP.1/SIGN|RSA Sign/Verify|2048,
3072,
4096|FIPS 186-5, RSA|FIPS 186-5, RSA|
+|FCS_COP.1/SIGN|ECDSA Sign/Verify|P256,
P384,
P521|FIPS 186-5, ECDSA|FIPS 186-5, ECDSA|
+|FCS_COP.1/KEYHMAC|HMAC-SHA 1/256/384/512|1/256/
384/512|FIPS 198-1 & 180-4|FIPS 198-1 & 180-4|
+|FCS_RBG_EXT.1|DRBG Bit Generation|256|SP 800-90A (Counter)|SP 800-90A (Counter)|
+
+
+_**Table 24 - BoringSSL Cryptographic Algorithms**_
+
+
+The TOEโs BoringSSL library has been tested on supported processors for both 64-bit and 32-bit
+applications, based on support that is enabled on the Pixel device. The Pixel 8 and 9 series devices (all
+Tensor G3 and Tensor G4 devices) only support 64-bit applications while all other devices support both
+64-bit and 32-bit applications.
+
+
+Androidโs LockSettings service (version 77561fc30db9aedc1f50f5b07504aa65b4268b88) as validated on
+Android 15 provides the TOEโs SP 800-108 key based key derivation function for deriving KEKs.
+
+|SFR|Algorithm|Keys|NIST Standard|Cert#|
+|---|---|---|---|---|
+|FCS_CKM_EXT.2 &
FCS_CKM_EXT.3|LockSettings service KBKDF|256|SP 800-108|A2168|
+
+
+
+_**Table 25 - LockSettings Service KDF Cryptographic Algorithms**_
+
+
+The following algorithms used in the TOE are provided by hardware components of the device. As these
+algorithms are implemented solely in hardware, they do not utilize Android 15 as their operating
+environment, but provide lower-level services upon which some of the security functionality rests.
+
+
+The Pixel devices in Table 26 include a Titan security chip, which provides cryptographic algorithm
+implementations within a secure microprocessor supporting the Android Keystore StrongBox HAL. Table
+26 provides a list of the supported chips in the devices (devices not listed do not support the StrongBox
+HAL). Titan security chips support the Android Keystore StrongBox hardware abstraction layer, and as
+such, provides secure key generation, digital signatures, and other cryptographic functions in a mutual
+hardware Keystore.
+
+|Device|Chip|Hardware|Firmware|
+|---|---|---|---|
+|Pixel 9 Pro XL/9
Pro/9/9 Pro Fold/9a|Titan M2|H1D3M|1.5.1|
+|Pixel 8 Pro/8/8a|Titan M2|H1D3M|1.3.10|
+|Pixel Tablet/Fold/
7 Pro/7/7a|Titan M2|H1D3M|1.2.10|
+
+
+
+_**Table 26 - Titan Security Chipsets**_
+
+|SFR|Algorithm|Keys|NIST Standard|Cert#|
+|---|---|---|---|---|
+|FCS_CKM.1|RSA IFC Key Generation|2048|FIPS 186-5, RSA|A6054|
+|FCS_CKM.1|ECDSA ECC Key Generation|P256|FIPS 186-5, ECDSA|FIPS 186-5, ECDSA|
+
+
+
+72 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+|SFR|Algorithm|Keys|NIST Standard|Cert#|
+|---|---|---|---|---|
+|FCS_COP.1/ENCRYPT|AES CBC, GCM|128/256|FIPS 197, SP 800-38A/D||
+|FCS_COP.1/HASH|SHA Hashing|256|FIPS 180-4|FIPS 180-4|
+|FCS_COP.1/SIGN|RSA Sign/Verify|2048|FIPS 186-5, RSA|FIPS 186-5, RSA|
+|FCS_COP.1/SIGN|ECDSA Sign/Verify|P256|FIPS 186-5, ECDSA|FIPS 186-5, ECDSA|
+|FCS_COP.1/KEYHMAC|HMAC-SHA|256|FIPS 198-1 & 180-4|FIPS 198-1 & 180-4|
+|FCS_RBG_EXT.1|DRBG Bit Generation|256|SP 800-90A (HMAC)|SP 800-90A (HMAC)|
+|FCS_CKM_EXT.2 &
FCS_CKM_EXT.3|KBKDF|256|SP 800-108|SP 800-108|
+
+
+
+_**Table 27 - Titan M2 with v1.5.1 Firmware Cryptographic Algorithms**_
+
+
+
+|SFR|Algorithm|Keys|NIST Standard|Cert#|
+|---|---|---|---|---|
+|FCS_CKM.1|RSA IFC Key Generation|2048|FIPS 186-5, RSA|A4707|
+|FCS_CKM.1|ECDSA ECC Key Generation|P256|FIPS 186-5, ECDSA|FIPS 186-5, ECDSA|
+|FCS_COP.1/ENCRYPT|AES CBC, GCM|128/256|FIPS 197, SP 800-38A/D|FIPS 197, SP 800-38A/D|
+|FCS_COP.1/HASH|SHA Hashing|256|FIPS 180-4|FIPS 180-4|
+|FCS_COP.1/SIGN|RSA Sign/Verify|2048|FIPS 186-5, RSA|FIPS 186-5, RSA|
+|FCS_COP.1/SIGN|ECDSA Sign/Verify|P256|FIPS 186-5, ECDSA|FIPS 186-5, ECDSA|
+|FCS_COP.1/KEYHMAC|HMAC-SHA|256|FIPS 198-1 & 180-4|FIPS 198-1 & 180-4|
+|FCS_RBG_EXT.1|DRBG Bit Generation|256|SP 800-90A (HMAC)|SP 800-90A (HMAC)|
+|FCS_CKM_EXT.2 &
FCS_CKM_EXT.3|KBKDF|256|SP 800-108|SP 800-108|
+
+
+_**Table 28 - Titan M2 with v1.3.10 Firmware Cryptographic Algorithms**_
+
+
+
+
+
+
+
+|SFR|Algorithm|Keys|NIST Standard|Cert#|
+|---|---|---|---|---|
+|FCS_CKM.1|RSA IFC Key Generation|2048|FIPS 186-5, RSA|A2951|
+|FCS_CKM.1|ECDSA ECC Key Generation|P256|FIPS 186-5, ECDSA|FIPS 186-5, ECDSA|
+|FCS_COP.1/ENCRYPT|AES CBC, GCM|128/256|FIPS 197, SP 800-38A/D|FIPS 197, SP 800-38A/D|
+|FCS_COP.1/HASH|SHA Hashing|256|FIPS 180-4|FIPS 180-4|
+|FCS_COP.1/SIGN|RSA Sign/Verify|2048|FIPS 186-5, RSA|FIPS 186-5, RSA|
+|FCS_COP.1/SIGN|ECDSA Sign/Verify|P256|FIPS 186-5, ECDSA|FIPS 186-5, ECDSA|
+|FCS_COP.1/KEYHMAC|HMAC-SHA|256|FIPS 198-1 & 180-4|FIPS 198-1 & 180-4|
+|FCS_RBG_EXT.1|DRBG Bit Generation|256|SP 800-90A (HMAC)|SP 800-90A (HMAC)|
+|FCS_CKM_EXT.2 &
FCS_CKM_EXT.3|KBKDF|256|SP 800-108|SP 800-108|
+
+
+_**Table 29 - Titan M2 with v1.2.10 Firmware Cryptographic Algorithms**_
+
+
+The devices have unique Wi-Fi chipsets. All Wi-Fi chipsets provide encryption to meet
+FCS_COP.1/ENCRYPT.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+|Device|Wi-Fi Chipset|Algorithm|Keys|NIST Standard|Cert#|
+|---|---|---|---|---|---|
+|Pixel 9 Pro XL/9
Pro/9/9 Pro Fold/9a|BCM4390|AES-CCMP|128/256|FIPS 197, SP
800-38C|A4158, A4159|
+|Pixel 8 Pro/8/8a|BCM4398|BCM4398|BCM4398|BCM4398|A2442, A2509|
+|
Pixel Tablet|
BCM4389|
BCM4389|
BCM4389|
BCM4389|
AES 5926, AES
5927, AES
5952, AES
5953|
+|
Pixel Fold|
Pixel Fold|
Pixel Fold|
Pixel Fold|
Pixel Fold|
Pixel Fold|
+|
Pixel 7 Pro/7|
Pixel 7 Pro/7|
Pixel 7 Pro/7|
Pixel 7 Pro/7|
Pixel 7 Pro/7|
Pixel 7 Pro/7|
+|
Pixel 6 Pro/6/6a|
Pixel 6 Pro/6/6a|
Pixel 6 Pro/6/6a|
Pixel 6 Pro/6/6a|
Pixel 6 Pro/6/6a|
Pixel 6 Pro/6/6a|
+|
Pixel 7a|QC6740|QC6740|QC6740|QC6740|AES 5663|
+
+
+
+73 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+_**Table 30 - Wi-Fi Chipsets**_
+
+
+The Pixel 9 Pro XL/9 Pro/9/9 Pro Fold/9a application processor (Google Tensor G4) provides
+cryptographic algorithms (marked as SoC). The Google Tensor UFS Inline Storage Engine is version 1.2.1
+with hardware sf_crypt_fmp_fx8_v4.2.1 (4.2.1). The Google Trusty TEE is version 12128783 (marked as
+TEE).
+
+|SFR|Component|Algorithm|Keys|NIST Standard|Cert#|
+|---|---|---|---|---|---|
+|FCS_COP.1/ENCRYPT|Storage|AES XTS|256|FIPS 197, SP 800-38E|A4645|
+|FCS_COP.1/HASH|Storage|SHA Hashing|256|FIPS 180-4|A6282|
+|FCS_COP.1/KEYHMAC|Storage|HMAC-SHA|256|FIPS 198-1 & 180-4|FIPS 198-1 & 180-4|
+|FCS_COP.1/ENCRYPT|SoC|AES CBC|128/256|FIPS 197, SP 800-38A|A5649|
+|FCS_COP.1/HASH|SoC|SHA Hashing|256|FIPS 180-4|FIPS 180-4|
+|FCS_COP.1/KEYHMAC|SoC|HMAC-SHA|256|FIPS 198-1 & 180-4|FIPS 198-1 & 180-4|
+|FCS_CKM_EXT.2 &
FCS_CKM_EXT.3|TEE|KBKDF|256|SP 800-108|A5792|
+|FCS_COP.1/ENCRYPT|TEE|AES GCM|128/256|FIPS 197, SP 800-38D|FIPS 197, SP 800-38D|
+|FCS_COP.1/HASH|TEE|SHA Hashing|256|FIPS 180-4|FIPS 180-4|
+|FCS_COP.1/KEYHMAC|TEE|HMAC-SHA|256|FIPS 198-1 & 180-4|FIPS 198-1 & 180-4|
+
+
+
+_**Table 31 - Google Tensor G4 Hardware Cryptographic Algorithms**_
+
+
+The Pixel 8 Pro/8 application processor (Google Tensor G3) provides cryptographic algorithms (marked
+as SoC). The Google Tensor UFS Inline Storage Engine is version 1.2.0 with hardware
+sf_crypt_fmp_fx8_v4.2.1 (4.2.1). The Google Trusty TEE is version 10588524 (marked as TEE).
+
+|SFR|Component|Algorithm|Keys|NIST Standard|Cert#|
+|---|---|---|---|---|---|
+|FCS_COP.1/ENCRYPT|Storage|AES XTS|256|FIPS 197, SP 800-38E|A4645|
+|FCS_COP.1/HASH|Storage|SHA Hashing|256|FIPS 180-4|A4644|
+|FCS_COP.1/KEYHMAC|Storage|HMAC-SHA|256|FIPS 198-1 & 180-4|FIPS 198-1 & 180-4|
+|FCS_COP.1/ENCRYPT|SoC|AES CBC|128/256|FIPS 197, SP 800-38A|A4656|
+|FCS_COP.1/HASH|SoC|SHA Hashing|256|FIPS 180-4|FIPS 180-4|
+|FCS_COP.1/KEYHMAC|SoC|HMAC-SHA|256|FIPS 198-1 & 180-4|FIPS 198-1 & 180-4|
+|FCS_CKM_EXT.2 &
FCS_CKM_EXT.3|TEE|KBKDF|256|SP 800-108|A4402|
+|FCS_COP.1/ENCRYPT|TEE|AES GCM|128/256|FIPS 197, SP 800-38D|FIPS 197, SP 800-38D|
+|FCS_COP.1/HASH|TEE|SHA Hashing|256|FIPS 180-4|FIPS 180-4|
+|FCS_COP.1/KEYHMAC|TEE|HMAC-SHA|256|FIPS 198-1 & 180-4|FIPS 198-1 & 180-4|
+
+
+
+_**Table 32 - Google Tensor G3 Hardware Cryptographic Algorithms**_
+
+
+The Pixel Tablet, Fold and 7 Pro/7/7a application processor (Google Tensor G2) provides cryptographic
+algorithms (marked as SoC). The Google Tensor UFS Inline Storage Engine is version 1.0.0 with hardware
+sf_crypt_fmp_fx8_v4.1.0 (4.1.0). The Google Trusty TEE is version 9004426 (marked as TEE).
+
+|SFR|Component|Algorithm|Keys|NIST Standard|Cert#|
+|---|---|---|---|---|---|
+|FCS_COP.1/ENCRYPT|Storage|AES XTS|128/256|FIPS 197, SP 800-38E|A2937|
+|FCS_COP.1/HASH|Storage|SHA Hashing|256|FIPS 180-4|A2938|
+|FCS_COP.1/KEYHMAC|Storage|HMAC-SHA|256|FIPS 198-1 & 180-4|FIPS 198-1 & 180-4|
+|FCS_COP.1/ENCRYPT|SoC|AES CBC|128/256|FIPS 197, SP 800-38A|A2923|
+|FCS_COP.1/HASH|SoC|SHA Hashing|256|FIPS 180-4|FIPS 180-4|
+|FCS_COP.1/KEYHMAC|SoC|HMAC-SHA|256|FIPS 198-1 & 180-4|FIPS 198-1 & 180-4|
+
+
+
+74 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+|SFR|Component|Algorithm|Keys|NIST Standard|Cert#|
+|---|---|---|---|---|---|
+|FCS_CKM_EXT.2 &
FCS_CKM_EXT.3|TEE|KBKDF|256|SP 800-108|A2928|
+|FCS_COP.1/ENCRYPT|TEE|AES GCM|128/256|FIPS 197, SP 800-38D|FIPS 197, SP 800-38D|
+|FCS_COP.1/HASH|TEE|SHA Hashing|256|FIPS 180-4|FIPS 180-4|
+|FCS_COP.1/KEYHMAC|TEE|HMAC-SHA|256|FIPS 198-1 & 180-4|FIPS 198-1 & 180-4|
+
+
+
+_**Table 33 - Google Tensor G2 Hardware Cryptographic Algorithms**_
+
+
+The Pixel 6 Pro/6/6a application processor (Google Tensor) provides cryptographic algorithms (marked
+as SoC). The Google Tensor UFS Inline Storage Engine is version de8b6c8621; the Hash and Keyed Hash
+functions are implemented in software, not hardware (marked as Storage). The Google Trusty TEE is
+version 7623683 (marked as TEE).
+
+|SFR|Component|Algorithm|Keys|NIST Standard|Cert#|
+|---|---|---|---|---|---|
+|FCS_COP.1/ENCRYPT|Storage|AES XTS|128/256|FIPS 197, SP 800-38E|A1981|
+|FCS_COP.1/HASH|Storage|SHA Hashing|256|FIPS 180-4|FIPS 180-4|
+|FCS_COP.1/KEYHMAC|Storage|HMAC-SHA|256|FIPS 198-1 & 180-4|FIPS 198-1 & 180-4|
+|FCS_COP.1/ENCRYPT|SoC|AES CBC|128/256|FIPS 197, SP 800-38A|A1980|
+|FCS_COP.1/HASH|SoC|SHA Hashing|256|FIPS 180-4|FIPS 180-4|
+|FCS_COP.1/KEYHMAC|SoC|HMAC-SHA|256|FIPS 198-1 & 180-4|FIPS 198-1 & 180-4|
+|FCS_RBG_EXT.1|SoC|DRBG Bit Generation|256|SP 800-90A (Counter)|SP 800-90A (Counter)|
+|FCS_CKM_EXT.2 &
FCS_CKM_EXT.3|TEE|KBKDF|256|SP 800-108|A1982|
+|FCS_COP.1/ENCRYPT|TEE|AES GCM|128/256|FIPS 197, SP 800-38D|FIPS 197, SP 800-38D|
+|FCS_COP.1/HASH|TEE|SHA Hashing|256|FIPS 180-4|FIPS 180-4|
+|FCS_COP.1/KEYHMAC|TEE|HMAC-SHA|256|FIPS 198-1 & 180-4|FIPS 198-1 & 180-4|
+
+
+
+_**Table 34 - Google Tensor Hardware Cryptographic Algorithms**_
+
+
+The TOEโs application processor includes a source of hardware entropy that the TOE distributes
+throughout, and the TOEโs RBGs make use of that entropy when seeding/instantiating themselves.
+
+
+The TOEโs BoringSSL library supports the TOEโs cryptographic Android Runtime (ART) methods (through
+Android's conscrypt JNI provider) afforded to mobile applications and supports Android user-space
+processes and daemons (e.g., wpa_supplicant). The TOEโs Application Processor provides hardware
+accelerated cryptography utilized in Data-At-Rest (DAR) encryption of the user data partition.
+
+
+The TOE stretches the userโs password to create a password-derived key. The TOE stretching function
+uses a series of steps to increase the memory required for key derivation (thus thwarting GPUacceleration, off-line brute force, and precomputed dictionary attacks) and ensure proper conditioning
+and stretching of the userโs password.
+
+
+The TOE conditions the userโs password using two iterations of PBKDFv2 w HMAC-SHA-256 in addition
+to some ROMix operations in an algorithm named scrypt. Scrypt consists of one iteration of PBKDFv2,
+followed by a series of ROMix operations, and finished with a final iteration of PBKDFv2. The ROMix
+operations increase the memory required for key derivation, thus thwarting GPU-acceleration (which
+can greatly decrease the time needed to brute force PBKDFv2 alone) and other custom hardware-based
+brute force attacks.
+
+
+The password-derived key is combined with the hardware REK in storage, preventing the ability to
+perform offline attacks, and online attacks are limited due to the TOEโs configuration of the maximum
+
+
+75 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+no more than 50 incorrect password attempts (with at least 4 character passwords). The use of the
+password derivation function in combination with the device configuration forces the attacker to only
+be able to perform an exhaustive key search to unlock the device without access to the password, and
+then subject to the configured limit of 50 or less attempts before the device is wiped.
+
+
+The following scrypt diagram shows how the password and salt are used with PBKDFv2 and ROMix to
+fulfil the requirements for password conditioning.
+
+
+_**Figure 1 - Password Conditioning**_
+
+
+The resulting derived key from this operation is used to decrypt the FBE and to derive the User Keystore
+Daemon Value.
+
+
+As part of the TLS, the TOE uses SHA with ciphersuites and digital signatures. The TLS ciphersuites
+support using SHA-1, SHA-256 and SHA-384. SHA functionality is also provided to mobile applications
+and can also be used as part of HMAC generation. For mobile applications generating a MAC, the HMAC
+operations in a byte-oriented mode and can use SHA-1 (with a 160-bit key) to generate a 160-bit MAC,
+SHA-256 (with a 256-bit key) to generate a 256-bit MAC, SHA-384 (with a 384-bit key) to generate a 384bit MAC and SHA-512 (with a 512-bit key) to generate a 512-bit MAC. FIPS 198-1 & 180-4 dictate the
+block size used, and they specify block sizes/output MAC lengths of 512/160, 512/160, 1024/384, and
+1024/512-bits for HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 respectively.
+
+
+**PP_MDF_V3.3:FCS_HTTPS_EXT.1:**
+The TOE supports the HTTPS protocol (compliant with RFC 2818) so that (mobile and system)
+applications executing on the TOE can act as HTTPS clients and securely connect to external servers
+using HTTPS. Administrators have no credentials and cannot use HTTPS or TLS to establish
+administrative sessions with the TOE as the TOE does not provide any such capabilities.
+
+
+**PP_MDF_V3.3:FCS_IV_EXT.1:**
+The TOE generates IVs by reading from /dev/urandom for use with all keys. In all cases, the TOE uses
+/dev/urandom and generates the IVs in compliance with the requirements of table 11 of PP_MDF_V3.3.
+
+
+**PP_MDF_V3.3:FCS_RBG_EXT.1:**
+
+
+76 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+The TOE provides a number of different RBGs including:
+
+
+1. An AES-256 CTR_DRBG in Google Tensor processors hardware
+2. An AES-256 CTR_DRBG provided by BoringSSL. This is the only accredited and supported DRBG
+
+present in the system and available to independently developed applications. As such, the TOE
+provides mobile applications access (through an Android Java API) to random data drawn from
+its AES-256 CTR_DRBG
+3. An SHA-256 HMAC_DRBG provided by the Titan security chip
+The TOE initializes its AP DRBG with enough data from its AP hardware noise source to ensure at least
+256-bits of entropy. The TOE then uses its AP DRBG to seed an entropy daemon that uses the BoringSSL
+AES-256 CTR_DRBG to provide random bits for user space. The entropy daemon starts early in the boot
+process to ensure availability to the rest of the system.
+
+
+The TOE seeds its BoringSSL AES-256 CTR_DRBG using 384-bits of data from the entropy daemon, thus
+ensuring at least 256-bits of entropy. The TOE uses its BoringSSL DRBG for all random generation
+including salts.
+
+
+The TOE seeds the Titan security chip SHA-256 HMAC_DRBG with entropy from its hardware noise and
+then uses the DRBG when generating keys and cryptographic random values.
+
+
+**PP_MDF_V3.3:FCS_SRV_EXT.1:**
+The TOE provides applications access to the cryptographic operations including encryption (AES),
+hashing (SHA), signing and verification (RSA & ECDSA), key hashing (HMAC), keyed message digests
+(HMAC-SHA-256), generation of asymmetric keys for key establishment (RSA and ECDH), and generation
+of asymmetric keys for signature generation and verification (RSA, ECDSA). The TOE provides access
+through the Android operating systemโs Java API, through the native BoringSSL API, and through the
+application processor module (user and kernel) APIs.
+
+
+**PP_MDF_V3.3:FCS_SRV_EXT.2:**
+The TOE provides applications with APIs to perform the functions referenced in FCS_COP.1/ENCRYPT
+and FCS_COP.1/SIGN.
+
+
+**PP_MDF_V3.3:FCS_STG_EXT.1:**
+The TOE provides the user, administrator and mobile applications the ability to import and use
+asymmetric public and private keys into the TOEโs software-based Secure Key Storage. Certificates are
+stored in files using UID-based permissions and an API virtualizes the access. Additionally, the user and
+administrator can request the TOE to destroy the keys stored in the Secure Key Storage. While normally
+mobile applications cannot use or destroy the keys of another application, applications that share a
+common application developer (and are thus signed by the same developer key) may do so. In other
+words, applications with a common developer (and which explicitly declare a shared UUID in their
+application manifest) may use and destroy each otherโs keys located within the Secure Key Storage.
+
+
+The TOE provides additional protections on keys beyond including key attestation, to allow enterprises
+and application developers the ability to ensure which keys have been generated securely within the
+phone.
+
+
+77 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+The TOE also provides an extension to Android Keystore, StrongBox, which allows mobile applications to
+specify that keys be stored in the Pixelโs hardware-based key storage (provided by the Titan M security
+chip [3] ).
+
+
+**PP_MDF_V3.3:FCS_STG_EXT.2:**
+The TOE employs a key hierarchy that protects all DEKs and KEKs by encryption with either the REK or by
+the REK and password derived KEK.
+
+
+The TOE encrypts Long-term Trusted channel Key Material (LTTCKM, i.e., Bluetooth and Wi-Fi keys)
+values using AES-256 GCM encryption and stores the encrypted values within their respective
+configuration files.
+
+
+All keys are 256-bits in size. The TOE generates keys using its BoringSSL AES-256 CTR_DRBG (for the Java
+and native layer), the Titan series security chips SHA-256 HMAC_DRBG (for StrongBox) or the Google
+Tensor series processors AES-256 CTR_DRBG (for Trusted Applications in TrustZone). By utilizing only
+256-bit KEKs, the TOE ensures that all keys are encrypted by an equal or larger sized key.
+
+
+In the case of Wi-Fi, the TOE utilizes the 802.11-2012 KCK and KEK keys to unwrap (decrypt) the
+WPA2/WPA3 Group Temporal Key received from the access point. The TOE protects persistent Wi-Fi
+keys (user certificates and private keys) by storing them in the Android Key Store. The Wi-Fi connection
+uses AES-CCMP (CCM) to encrypt the wireless traffic.
+
+
+**PP_MDF_V3.3:FCS_STG_EXT.3:**
+The TOE protects the integrity of all DEKs and KEKs (including LTTCKM keys) stored in Flash by using
+authenticated encryption/decryption methods (CCM, GCM).
+
+
+**MOD_MDM_AGENT_V1.0:FCS_STG_EXT.4:**
+The private key used by the TOE to verify policy integrity is stored in the Android Keystore.
+
+
+**PKG_TLS_V1.1:FCS_TLS_EXT.1:**
+**PKG_TLS_V1.1:FCS_TLSC_EXT.1:**
+**PKG_TLS_V1.1:FCS_TLSC_EXT.2:**
+The TOE provides mobile applications (through its Android API) the use of TLS version 1.2 as a client,
+including support for the selections chosen in section 5 for FCS_TLSC_EXT.1 (and the TOE requires no
+configuration other than using the appropriate library APIs as described in the Admin Guidance).
+
+
+When an application uses the combined APIs provided in the Admin Guide to attempt to establish a
+trusted channel connection based on TLS or HTTPS, the TOE supports only Subject Alternative Name
+(SAN) (DNS and IP address) as reference identifiers (the TOE does not accept reference identifiers in the
+Common Name[CN]). The TOE supports client (mutual) authentication (only a certificate is required to
+provide support for mutual authentication).
+
+
+No additional configuration is needed to allow the device to use the supported cipher suites, as only the
+claimed cipher suites are supported in the aforementioned library as each of the aforementioned
+ciphersuites are supported on the TOE by default or through the use of the TLS library.
+
+
+3 StrongBox is not available on the Pixel 6 Pro/6/6a
+
+78 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+While the TOE supports the use of wildcards in X.509 reference identifiers (SAN only), the TOE does not
+support certificate pinning. If the TOE cannot determine the revocation status of a peer certificate, the
+TOE rejects the certificate and rejects the connection.
+
+
+**PKG_TLS_V1.1:FCS_TLSC_EXT. 4:**
+The TOE includes the โrenegotiation_infoโ TLS extension in its TLS client hello message.
+
+
+**PKG_TLS_V1.1:FCS_TLSC_EXT.5:**
+The TOE in its evaluated configuration and, by design, supports elliptic curves for TLS (P-256 and P-384)
+and has a fixed set of supported curves (thus the admin cannot and need not configure any curves).
+
+
+**MOD_WLANC_V1.0:FCS_TLSC_EXT.1/WLAN:**
+**MOD_WLANC_V1.0:FCS_TLSC_EXT.2/WLAN:**
+The TSF supports TLS versions 1.1, and 1.2 and also supports the selected ciphersuites utilizing SHA-1,
+SHA-256, and SHA-384 (see the selections in section 5 for FCS_TLSC_EXT.1/WLAN) for use with EAP-TLS
+as part of WPA2/WPA3. The TOE in its evaluated configuration and, by design, supports only evaluated
+elliptic curves (P-256 & P-384 and no others) and has a fixed set of supported curves (thus the admin
+cannot and need not configure any curves).
+
+
+The TOE allows the user to load and utilize authentication certificates for EAP-TLS used with
+WPA3/WPA2. The Android UI
+
+```
+ Settings -> Security -> Advanced settings -> Encryption &
+ credentials -> Install a certificate -> Wi-Fi certificate
+
+```
+
+allows the user to import an RSA or ECDSA certificate for use with Wi-Fi.
+
+
+**MOD_WLANC_V1.0:FCS_WPA_EXT.1:**
+The TSF support WPA2 and WPA3 security types for Wi-Fi networks.
+
+### 6.3 User data protection
+
+
+**PP_MDF_V3.3:FDP_ACF_EXT.1:**
+The TOE provides a mechanism based on the use of assigned permissions to specify the level of access
+any application may have to any system service. A system service may have multiple permissions
+associated with it, depending on the functionality of the service (for example read and write access may
+be separate controls on one service while both may be combined into a single control on another
+service). When an application wants to access the system service in question, the calling application
+must be granted access to the permission by the user.
+
+
+Some permissions are granted automatically for applications that are installed by Google (these are only
+for Google applications and are not provided for any third party applications) while all the user of the
+device must authorize other permissions. Applications using API Level 23 (Android 6.0) or higher (the
+current API Level is 35) will prompt the user to grant the permission the first time the permission is
+requested by the application. Applications written to older API Levels will prompt the user for all
+permissions the first time the application runs. If the user has approved the permission persistently, it
+will be allowed every time the application runs, but if the user only approved the permission for one
+time use, the user will be prompted to approve access every time the permission is requested by the
+application.
+
+
+79 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+[Permissions in API Level 33 are assigned a protectionLevel](https://developer.android.com/reference/android/R.attr#protectionLevel) based on the implied potential risk to
+accessing data protected by the permission. The protectionLevel is divided into two types: base
+permissions and protection flags. Base permissions are associated with the level of risk while the flags
+are modifiers that may provide context or refinement of the base permission.
+
+
+The TOE provides the following base permissions to applications (for API Level 35):
+
+
+1. Normal - A lower-risk permission that gives an application access to isolated application-level
+
+features, with minimal risk to other applications, the system, or the user. The system
+automatically grants this type of permission to a requesting application at installation, without
+asking for the user's explicit approval (though the user always has the option to review these
+permissions before installing).
+2. Dangerous - A higher-risk permission that would give a requesting application access to private
+
+user data or control over the device that can negatively impact the user. Because this type of
+permission introduces potential risk, the system cannot automatically grant it to the requesting
+application. For example, any dangerous permissions requested by an application will be
+displayed to the user and require confirmation before proceeding or some other approach can
+be taken to avoid the user automatically allowing the use of such facilities.
+3. Signature - A permission that the system is to grant only if the requesting application is signed
+
+with the same certificate as the application that declared the permission. If the certificates
+match, the system automatically grants the permission without notifying the user or asking for
+the user's explicit approval.
+4. Internal - a permission that is managed internally by the system and only granted according to
+
+the protection flags.
+An example of a normal permission is the ability to vibrate the device: android.permission.VIBRATE. This
+permission allows an application to make the device vibrate, and an application that does not request
+(or declare) this permission would have its vibration requests ignored.
+
+
+An example of a dangerous privilege would be access to location services to determine the location of
+the mobile device: android.permission.ACCESS_FINE_LOCATION. The TOE controls access to Dangerous
+permissions during the running of the application. The TOE prompts the user to review the applicationโs
+requested permissions (by displaying a description of each permission group, into which individual
+permissions map, that an application requested access to). If the user approves, then the application is
+allowed to continue running. If the user disapproves, the device continues to run, but cannot use the
+services protected by the denied permissions. Thereafter, the mobile device grants that application
+during execution access to the set of permissions declared in its Manifest file.
+
+
+An example of a signature permission is the android.permission.BIND_VPN_SERVICE that an application
+must declare in order to utilize the VpnService APIs of the device. Because the permission is a Signature
+permission, the mobile device only grants this permission to an application (2nd installed app) that
+requests this permission and that has been signed with the same developer key used to sign the
+application (1st installed app) declaring the permission (in the case of the example, the Android
+Framework itself).
+
+
+An example of an internal permission is the
+android.permission.SET_DEFAULT_ACCOUNT_FOR_CONTACTS, which is only granted to system
+applications fulfilling the Contacts app role to allow the default account for new contacts to be set.
+
+
+80 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+Additionally, Android includes the following flags that layer atop the base categories (details can be
+[found here https://developer.android.com/reference/android/R.attr#protectionLevel):](https://developer.android.com/reference/android/R.attr#protectionLevel)
+
+
+1. appop - this permission is closely associated with an app op for controlling access.
+2. companion - this permission can be automatically granted to the system companion device
+
+manager service.
+3. configurator - this permission automatically granted to device configurator.
+4. development - this permission can also (optionally) be granted to development applications
+
+(e.g., to allow additional location reporting during beta testing).
+5. incidentReportApprover - this permission designates the app that will approve the sharing of
+
+incident reports.
+6. installer - this permission can be automatically granted to system apps that install packages.
+7. instant - this permission can be granted to instant apps.
+8. knownSigner - this permission can also be granted if the requesting application is signed by, or
+
+has in its signing lineage, any of the certificate digests declared in knownCerts (this allows for
+signature changes such as when an application has been changed to a new organization to
+maintain access during updates).
+9. module - this permission can also be granted if the requesting application is included in the
+
+mainline module.
+10. oem - this permission can be granted only if its protection level is signature, the requesting app
+
+resides on the OEM partition, and the OEM has allowlisted the app to receive this permission by
+the OEM.
+11. pre23 - this permission can be automatically granted to apps that target API levels below API
+
+level 23 (Android 6.0).
+12. preinstalled - this permission can be automatically granted to any application pre-installed on
+
+the system image (not just privileged apps) (the TOE does not prompt the user to approve the
+permission).
+13. privileged - this permission can also be granted to any applications installed as privileged apps
+
+on the system image. Please avoid using this option, as the signature protection level should be
+sufficient for most needs and works regardless of exactly where applications are installed. This
+permission flag is used for certain special situations where multiple vendors have applications
+built in to a system image which need to share specific features explicitly because they are being
+built together.
+14. recents - this permission will be granted to the recents app.
+15. role - this permission is managed by role.
+16. runtime - this permission can only be granted to apps that target runtime permissions API level
+
+23 (Android 6.0) and above.
+17. setup - this permission can be automatically granted to the setup wizard app.
+18. vendorPrivileged - this permission can be granted to privileged apps in vendor partition.
+19. verifier - this permission can be automatically granted to system apps that verify packages.
+
+
+81 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+[The Android 15 (Level 35) API (details found here https://developer.android.com/reference/packages)](https://developer.android.com/reference/packages)
+provides services to mobile applications.
+
+
+While Android provides a large number of individual permissions, they are grouped into categories or
+features that provide similar functionality for the simplicity of the user interaction. These groupings do
+not affect the permissions themselves; it is only a way to group them together for the user presentation.
+Table 35 shows a series of functional categories centered on common functionality.
+
+|Service Features|Description|
+|---|---|
+|Sensitive I/O Devices & Sensors|Location services, Audio & Video capture, Body sensors|
+|User Personal Information & Credentials|Contacts, Calendar, Call logs, SMS|
+|Metadata & Device ID Information|IMEI, Phone Number|
+|Data Storage Protection|App data, App cache|
+|System Settings & Application Management|Date time, Reboot/Shutdown, Sleep, Force-close
application, Administrator Enrollment|
+|Wi-Fi, Bluetooth, USB Access|Wi-Fi, Bluetooth, USB tethering, debugging and file transfer|
+|Mobile Device Management & Administration|MDM APIs|
+|Peripheral Hardware|NFC, Camera, Headphones|
+|Security & Encryption|Certificate/Key Management, Password, Revocation rules|
+
+
+
+_**Table 35 - Functional Categories**_
+
+
+**PP_MDF_V3.3:FDP_ACF_EXT.1.2:**
+Applications with a common developer have the ability to allow sharing of data between their
+applications. A common application developer can sign their generated APK with a common certificate
+or key and set the permissions of their application to allow data sharing. When the different
+applicationsโ signatures match and the proper permissions are enabled, information can then be shared
+as needed.
+
+
+The TOE supports Enterprise profiles to provide additional separation between application and
+application data belonging to the Enterprise profile. Applications installed into the Enterprise versus
+Personal profiles cannot access each otherโs secure data, applications, and can have separate device
+administrators/managers. This functionality is built into the device by default and does not require an
+application download. The Enterprise administrative app (an MDM agent application installed into the
+Enterprise Profile) may enable cross-profile contacts search, in which case, the device owner can search
+the address book of the enterprise profile. Please see the Admin Guide for additional details regarding
+how to set up and use Enterprise profiles. Ultimately, the enterprise profile is under control of the
+personal profile. The personal profile can decide to remove the enterprise profile, thus deleting all
+information and applications stored within the enterprise profile. However, despite the โcontrolโ of the
+personal profile, the personal profile cannot dictate the enterprise profile to share applications or data
+with the personal profile; the enterprise profile MDM must allow for sharing of contacts before any
+information can be shared.
+
+
+**PP_MDF_V3.3:FDP_ACF_EXT.2:**
+The TOE allows an administrator to allow sharing of the enterprise profile address book with the normal
+profile. Each application group (profile) has its own calendar as well as keychain (keychain is the
+collection of user [not application] keys, and only the user can grant the userโs applications access to use
+a given key in the userโs keychain), thus Androidโs personal and work profiles do not share calendar
+appointments nor keys.
+
+
+82 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+**PP_MDF_V3.3:FDP_DAR_EXT.1:**
+The TOE provides Data-At-Rest AES-256 XTS hardware encryption for all data stored on the TOE in the
+user data partition (which includes both user data and TSF data). The TOE also has TSF data relating to
+key storage for TSF keys not stored in the systemโs Android Key Store. The TOE separately encrypts
+those TSF keys and data. Additionally, the TOE includes a read-only file system in which the TOEโs
+system executables, libraries, and their configuration data reside. For its Data-At-Rest encryption of the
+data partition on the internal Flash (where the TOE stores all user data and all application data), the TOE
+uses an AES-256 bit DEK with XTS feedback mode to encrypt each file in the data partition using
+dedicated application processor hardware.
+
+
+**PP_MDF_V3.3:FDP_DAR_EXT.2:**
+The vendor provides the NIAPSEC library for Sensitive Data Protection (SDP) that application developers
+must use to opt-in for sensitive data protection. This library calls into the TOE to generate an RSA key
+that acts as a primary KEK for the SDP encryption process. When an application that has opted-in for
+SDP receives incoming data while the device is locked, an AES symmetric DEK is generated to encrypt
+that data. The public key from the primary RSA KEK is then used to encrypt the AES DEK. Once the device
+is unlocked, the RSA KEK private key is re-derived and can be used to decrypt the AES DEK for each piece
+of information that was stored while the device was locked. For performance reasons SDP-protected
+data is usually decrypted and re-encrypted according to FDP_DAR_EXT.1 at the next successful login and
+access of the application, though this is a choice of the application developer (who may have a reason to
+maintain the SDP-status of the data).
+
+
+The keys for SDP are stored in the keystore (FCS_STG_EXT.1) with the settings
+[setUnlockedDeviceRequired and setUserAuthenticationRequired](https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder#setUnlockedDeviceRequired(boolean)) to enable. These settings ensure that
+sensitive data cannot be unlocked except once the user is authenticated to the TOE.
+
+
+Application data marked as sensitive will have header information about how the data is encrypted that
+will specify whether the data can only be read through the NIAPSEC library (utilizing the appropriate
+primary SDP KEK). To the system as a whole, there is no difference between an SDP file and a non-SDP
+file to avoid calling out where sensitive data is located; this is specifically limited to the header data of
+the file which would mark how the DEK is encrypted. Application data is segregated from other
+applications as per FDP_ACF_EXT.1.2.
+
+
+**PP_MDF_V3.3:FDP_IFC_EXT.1:**
+The TOE will route all traffic other than traffic necessary to establish the VPN connection to the VPN
+gateway (when the gatewayโs configuration specifies so) when the Always-On-VPN is enabled. The TOE
+includes an interceptor kernel module that controls inbound and output packets. When a VPN is active,
+the interceptor will route all incoming packets to the VPN and conversely route all outbound packets to
+the VPN before they are output.
+
+
+Note that when the TOE tries to connect to a Wi-Fi network, it performs a standard captive portal check
+which sends traffic that bypasses the full tunnel VPN configuration in order to detect whether the Wi-Fi
+network restricts Internet access until one has authenticated or agreed to usage terms through a captive
+portal. If the administrator wishes to deactivate the captive portal check (in order to prevent the
+plaintext traffic), they may do this by following the instructions in the Admin Guide.
+
+
+The only exception to all traffic being routed to the VPN is in the instance of ICMP echo requests. The
+TOE uses ICMP echo responses on the local subnet to facilitate network troubleshooting and categorizes
+
+
+83 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+it as a part of ARP. As such, if an ICMP echo request is issued on the subnet the TOE is part of, it will
+respond with an ICMP echo response, but no other instances of traffic will be routed outside of the VPN.
+
+
+**PP_MDF_V3.3:FDP_STG_EXT.1:**
+The TOEโs Trusted Anchor Database consists of the built-in certs and any additional user or admin/MDM
+loaded certificates. The built-in certs are individually stored in the deviceโs read-only system image in
+the /system/etc/security/cacerts directory, and the user can individually disable certs through the
+Android user interface:
+
+```
+ Settings -> Security -> Advanced settings -> Encryption &
+ credentials -> Trusted Credentials
+
+```
+
+Because the built-in CA certificates reside on the read-only system partition, the TOE places a copy of
+any disabled built-in certificate into the /data/misc/user/X/cacerts-removed/ directory, where 'X'
+represents the userโs number (which starts at 0). The TOE stores added CA certificates in the
+corresponding /data/misc/user/X/cacerts-added/ directory and also stores a copy of the CA certificate in
+the userโs Secure Key Storage (residing in the /data/misc/keystore/user_X/ directory). The TOE uses
+Linux file permissions that prevent any mobile application or entity other than the TSF from modifying
+these files. Only applications registered as an administrator (such as an MDM Agent Application) have
+the ability to access these files, staying in accordance to the permissions established in FMT_SMF.1 and
+FMT_MOF_EXT.1.
+
+
+**PP_MDF_V3.3:FDP_UPC_EXT.1/APPS:**
+**PP_MDF_V3.3:FDP_UPC_EXT.1/BLUETOOTH:**
+The TOE provides APIs allowing non-TSF applications (mobile applications) the ability to establish a
+secure channel using TLS, HTTPS, and Bluetooth BR/EDR and LE. Additionally, the vendor provides the
+NIAPSEC library for application developers to use for Hostname Checking, Revocation Checking, and TLS
+Ciphersuite restriction. Application developers must utilize this library to ensure the device behaves in
+the evaluated configuration. Mobile applications can use the following Android APIs for TLS, HTTPS, and
+Bluetooth respectively:
+
+
+SSL:
+
+
+javax.net.ssl.SSLContext:
+
+
+[https://developer.android.com/reference/javax/net/ssl/SSLSocket](https://developer.android.com/reference/javax/net/ssl/SSLSocket)
+
+
+Developers then need to swap SocketFactory for SecureSocketFactory, part of a private library
+provided by Google.
+
+
+[Developers can request this library by emailing: niapsec@google.com](mailto:niapsec@google.com)
+
+
+HTTPS:
+
+
+javax.net.ssl.HttpsURLConnection:
+
+
+[https://developer.android.com/reference/javax/net/ssl/HttpsURLConnection](https://developer.android.com/reference/javax/net/ssl/HttpsURLConnection)
+
+
+Developers then need to swap HTTPSUrlConnections for SecureUrl part of a private library
+provided by Google.
+
+
+[Developers can request this library by emailing: niapsec@google.com](mailto:niapsec@google.com)
+
+
+Bluetooth:
+
+84 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+android.bluetooth:
+
+
+[http://developer.android.com/reference/android/bluetooth/package-summary.html](http://developer.android.com/reference/android/bluetooth/package-summary.html)
+
+### 6.4 Identification and authentication
+
+
+**PP_MDF_V3.3:FIA_AFL_EXT.1:**
+The TOE maintains in persistent storage, for each user, the number of failed password logins since the
+last successful login and upon reaching the maximum number of incorrect logins, the TOE performs a full
+wipe of all protected data (and in fact, wipes all user data). The maximum number of failed attempts is
+limited to only counting password attempts, as biometric attempts are not considered critical attempts
+that can trigger a wipe.
+
+
+The administrator can adjust the number of failed login attempts that are allowed for the password
+unlock screen through an MDM. The possible values range from the default of ten failed logins to a
+value between 0 (deactivate wiping) and 50. When an authentication attempt occurs, the TOE first
+increments the failed login counter, and then checks the validity of the password by providing it to
+Androidโs Gatekeeper (which runs in the Trusted Execution Environment).
+
+
+Any visual error to the user about a failed entry is displayed after the validation check. Androidโs
+Gatekeeper keeps this password counter in persistent secure storage and increments the counter before
+validating the password. Upon successful validation of the password, this counter is reset back to zero. If
+the login attempt is a failure and the counter is equal or greater than the specified value the device will
+be wiped. By storing the counter persistently, and by incrementing the counter prior to validating it, the
+TOE ensures a correct tally of failed attempts even if it loses power.
+
+
+Table 36 lists the supported biometric fingerprint sensors for each device.
+
+
+
+
+
+
+
+
+
+|Device:|Ultrasonic|Under
Display|Power
Button|
+|---|---|---|---|
+|Pixel 9 Pro XL/9
Pro/9/9a|X|||
+|Pixel 8 Pro/8/8a||X||
+|Pixel Tablet|||X|
+|Pixel 9 Pro Fold/Fold|||X|
+|Pixel 7 Pro/7/7a||X||
+|Pixel 6 Pro/6/6a||X||
+
+
+_**Table 36 - Supported Biometric Modalities**_
+
+
+Additionally, the phone allows the user to unlock the device using their fingerprint. The TOE (through a
+separate counter) allows users up to 5 attempts to unlock the device via fingerprint before the TOE
+completely disables the fingerprint sensor. Once the TOE has disabled the fingerprint unlock entirely, it
+remains disabled until the user enters their password to unlock the device. Note that restarting the
+phone at any point disables the fingerprint sensor automatically until the user enters a correct password
+and unlocks the phone, and therefore TOE restart disruptions are not applicable for biometric
+authentication mechanisms.
+
+
+**MOD_BT_V1.0:FIA_BLT_EXT.1:**
+The TOE requires explicit user authorization before it will pair with a remote Bluetooth device. When
+pairing with another device, the TOE requires that the user either confirm that a displayed numeric
+
+85 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+passcode matches between the two devices or that the user enter (or choose) a numeric passcode that
+the peer device generates (or must enter). The TOE requires this authorization (via manual input) for
+mobile application use of the Bluetooth trusted channel and in situations where temporary (nonbonded) connections are formed.
+
+
+**MOD_BT_V1.0:FIA_BLT_EXT.2:**
+The TOE does not allow any data transfers with remote devices that have not been paired or authorized
+by the user of the TOE. All Bluetooth connections require initial approval by the user in the user
+interface and cannot be done programmatically. Bluetooth pairing (RFCOMM connections) is completed
+by confirming/entering a displayed passcode in the user interface. TOE support for OBEX (OBject
+EXchange) through L2CAP (Logical Link Control and Adaptation Protocol) requires the user to explicitly
+authorize the transfer via a popup that will be displayed to the user.
+
+
+**MOD_BT_V1.0:FIA_BLT_EXT.3:**
+The TOE rejects duplicate Bluetooth connections by only allowing a single session per paired device. This
+ensures that when the TOE receives a duplicate session attempt while the TOE already has an active
+session with that device, then the TOE ignores the duplicate session.
+
+
+**MOD_BT_V1.0:FIA_BLT_EXT.4:**
+The TOEโs Bluetooth host and controller supports Bluetooth Secure Simple Pairing and the TOE utilizes
+this pairing method when the remote host also supports it.
+
+
+**MOD_BT_V1.0:FIA_BLT_EXT.6:**
+The TOE requires explicit user authorization before granting trusted (paired) remote devices access to
+services associated with the OPP and MAP Bluetooth profiles.
+
+
+**MOD_BT_V1.0:FIA_BLT_EXT.7:**
+The TOE requires explicit user authorization before granting untrusted (unpaired) remote devices access
+to services associated with OPP and MAP Bluetooth profiles.
+
+
+**MOD_MDM_AGENT_V1.0:FIA_ENR_EXT.2:**
+[The MDM Agent is configured to connect to https://m.google.com](https://m.google.com/) for all communications with the
+MDM Server. All communications between the MDM Server and the MDM Agent are handled through
+the public server at this address and this address cannot be changed.
+
+
+**MOD_BIO_V1.1:FIA_MBE_EXT.1:**
+The TOE provides a mechanism to enroll user biometrics for authentication. The enrollment process
+requires the user to have a password set and to be authenticated successfully prior to being able to start
+the enrollment process. The user is able to enroll multiple fingerprints individually for use on supported
+devices.
+
+
+**MOD_BIO_V1.1:FIA_MBE_EXT.2:**
+**MOD_BIO_V1.1:FIA_MBV_EXT.2:**
+The TSF determines the quality of a sample before using it to enroll or verify a user. The fingerprint
+systems utilize different capture sensors, but the data analysis of the quality is common. Fingerprint
+[sample quality is determined using three measures. While the Android 15 CDD](https://source.android.com/docs/compatibility/15/android-15-cdd#7310_biometric_sensors) does not specify exactly
+how the quality measure must be performed, [Class 3](https://source.android.com/docs/security/features/biometric/measure#biometric-classes) provides strict requirements in terms of
+performance, leading to the measures here.
+
+
+86 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+The first measure is the completeness of the sample. For example, if the finger is offset from the sensor
+and only half the sensor acquires an image of the fingerprint, this partial print would be considered
+insufficient quality, as there is not enough data to make a match. This can also be triggered by events
+like a too light or too hard touch on the sensor (either of which can cause parts of the sensor to not
+sense the minutia of the fingerprint).
+
+
+The second measure is the clarity of the sample. Clarity is determined primarily by how clear the
+fingerprint minutia are in the sample image. Areas with no minutia (that is not a partial image), such as
+when a finger is dirty, or if the sensor is blocked, will be considered as insufficient quality. Repeated
+attempts with similar results will trigger a user notification that the sensor or finger may be dirty so the
+user can consider remediation (such as wiping the sensor or washing the finger).
+
+
+The third measure is a sufficient number of minutia within the sample. If the sample is complete and
+clear, then it is checked for a sufficient number of minutia to be used. The system looks for a large
+number of data points from which to build the template for use. While there is not a specific number,
+the check looks not only at the number but the distribution across the sample. For example if 50 points
+are needed but 40 points are found in only half the image this would be rejected, the distribution of the
+minutia would still cause the sample to fail.
+
+
+Each of these measures is used independently to determine whether the sample has sufficient quality.
+
+
+These measures are used on any sample that is collected, regardless of the purpose of the sample
+(enrollment or verification).
+
+
+**MOD_BIO_V1.1:FIA_MBV_EXT.1/PBFPS:**
+**MOD_BIO_V1.1:FIA_MBV_EXT.1/UDFPS:**
+**MOD_BIO_V1.1:FIA_MBV_EXT.1/USFPS:**
+The TOEโs fingerprint sensor provides FAR and FRR rates as shown in Table 37. The FAR and FRR rates
+provide a rating as to the protection provided against โliveโ attacks where-in a live fingerprint is
+presented to the sensor with regards to ensuring a proper match to the enrolled fingerprint(s). Each
+phone provides a FRR of shown in the table below, along with a rounded up (for the worse) and mapped
+ratio. Prior to the rounded rate, the FRR meets the requirements for FIA_BMG_EXT in all cases.
+
+
+Users have up to 5 attempts to unlock the phone using fingerprint before the fingerprint unlock method
+is disabled for 30 seconds. After the 4th unsuccessful round of unlock attempts (a total of 20 fingerprint
+attempts), the fingerprint sensor is disabled entirely and the user is prompted for their password. The
+fingerprint unlock remains disabled until the user enters their password.
+
+
+
+
+
+
+
+
+
+|Device|Sensor Type|False Accept Rate
(FAR)|False Reject Rate
(FRR)|Imposter Attack
Presentation
Accept Rate
(IAPAR)|
+|---|---|---|---|---|
+|Pixel 9 Pro XL/9
Pro/9/9a|USFPS|1:50,000|2.5%|7%|
+|Pixel 8 Pro/8/8a|UDFPS|UDFPS|UDFPS|UDFPS|
+|Pixel Tablet|PBFPS|PBFPS|PBFPS|PBFPS|
+|Pixel 9 Pro Fold/Fold|PBFPS|PBFPS|PBFPS|PBFPS|
+|Pixel 7 Pro/7/7a|UDFPS|UDFPS|UDFPS|UDFPS|
+|Pixel 6 Pro/6/6a|UDFPS|UDFPS|UDFPS|UDFPS|
+
+
+_**Table 37 - Fingerprint False Accept/Reject Rates**_
+
+
+
+87 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+**MOD_BIO_V1.1:FIA_MBV_EXT.3:**
+To provide protection against artefacts (beyond just properly matching a live fingerprint correctly), the
+TOEโs fingerprint sensor provides an IAPAR rate not exceeding 7% based on a biometric transaction
+using a built-in presentation attack detection (PAD) mechanism. An artefact is a non-live item (i.e. not a
+live person attempting to use their own actual fingerprint directly) that is presented to the sensor as a
+valid attempt at authentication.
+
+
+The PAD mechanism, in addition to the normal quality checks of the biometric sample, checks for
+additional information in the sample that can be used to determine if the sample is from an imposter.
+The IAPAR is measured as the Spoof Acceptance Rate as shown in the Android biometric testing
+[requirements here at Measuring Biometric Unlock Security.](https://source.android.com/docs/security/features/biometric/measure#fingerprint-authentication)
+
+
+**MOD_WLANC_V1.0:FIA_PAE_EXT.1:**
+The TOE can join WPA2-802.1X (802.11i) and WPA3-Enterprise wireless networks requiring EAP-TLS
+authentication, acting as a client/supplicant (and in that role connect to the 802.11 access point and
+communicate with the 802.1X authentication server).
+
+
+**PP_MDF_V3.3:FIA_PMG_EXT.1:**
+The TOE authenticates the user through a password consisting of basic Latin characters (upper and
+lower case, numbers, and the special characters noted in the selection (see the selections in section 5
+for FIA_PMG_EXT.1)). The TOE defaults to requiring passwords to have a minimum of four characters
+but no more than sixteen, contain at least one letter; however, an MDM application can change these
+defaults. The Smart Lock feature is not allowed in the evaluated configuration as this feature
+circumvents the requirements for FIA_PMG_EXT.1 and many others.
+
+
+**PP_MDF_V3.3:FIA_TRT_EXT.1:**
+Androidโs GateKeeper throttling is used to prevent brute-force attacks. After a user enters an incorrect
+password or a failed biometric, GateKeeper APIs return a value in milliseconds (500ms default) in which
+the user must wait before another authentication attempt. Any attempts before the defined amount of
+time has passed will be ignored by GateKeeper. Gatekeeper also keeps a count of the number of failed
+authentication attempts since the last successful attempt. These two values together are used to
+prevent brute-force attacks of the TOE.
+
+
+**PP_MDF_V3.3:FIA_UAU.5:**
+The TOE, in its evaluated configuration, allows the user to authenticate using either a password or
+biometric (see Table 36). Upon boot, the first unlock screen presented requires the user to enter their
+password to unlock the device. The biometric sensors are disabled until the user enters their password
+for the first time.
+
+
+Upon device lock during normal use of the device, the user has the ability to unlock the phone either by
+entering their password or by using a biometric authentication. Throttling of these inputs can be read
+about in the FIA_TRT_EXT.1 section. The entered password is compared to a value derived as described
+in the key hierarchy and key table above (FCS_STG_EXT.2 and FCS_CKM_EXT.3, respectively).
+FIA_MBV_EXT.1 describes the biometric authentication process and its security measures.
+
+
+Some security related user settings (e.g. changing the password, modifying, deleting, or adding stored
+fingerprint templates, Smart Lock settings, etc.) and actions (e.g. factory reset) require the user to enter
+
+
+88 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+their password before modifying these settings or executing these actions. In these instances, biometric
+authentication is not accepted to permit the referenced functions.
+
+
+The TOEโs evaluated configuration disallows other authentication mechanisms, such as pattern, PIN, or
+Smart Lock mechanisms (on-body detection, trusted places, trusted devices, and trusted voice).
+
+
+**PP_MDF_V3.3:FIA_UAU.6/CREDENTIAL:**
+**PP_MDF_V3.3:FIA_UAU.6/LOCKED:**
+The TOE requires the user to enter their password or supply their biometric in order to unlock the TOE.
+Additionally the TOE requires the user to confirm their current password when accessing the
+
+```
+ Settings -> Security -> Screen lock
+
+```
+
+menu in the TOEโs user interface. The TOE can disable Smart Lock through management controls. Only
+after entering their current user password can the user then elect to change their password.
+
+
+**PP_MDF_V3.3:FIA_UAU.7:**
+The TOE allows the user to enter the user's password from the lock screen. The TOE will, by default,
+display the most recently entered character of the password briefly or until the user enters the next
+character in the password, at which point the TOE obscures the character by replacing the character
+with a dot symbol. Further, the TOE provides no feedback other than whether the fingerprint unlock
+attempt succeeded or failed.
+
+
+**PP_MDF_V3.3:FIA_UAU_EXT.1:**
+As described in FCS_STG_EXT.2, the TOEโs key hierarchy requires the user's password in order to derive
+the KEK_* keys in order to decrypt other KEKs and DEKs. Thus, until it has the user's password, the TOE
+cannot decrypt the DEK utilized for Data-At-Rest encryption, and thus cannot decrypt the userโs
+protected data.
+
+
+**PP_MDF_V3.3:FIA_UAU_EXT.2:**
+The TOE, when configured to require a user password, allows a user to perform the actions assigned in
+FIA_UAU_EXT.2.1 (see selections in section 5 for FIA_UAU_EXT.2) without first successfully
+authenticating. Choosing the input method allows the user to select between different keyboard devices
+(say, for example, if the user has installed additional keyboards). Note that the TOE automatically names
+and saves (to the internal Flash) any screen shots or photos taken from the lock screen, and the TOE
+provides the user no opportunity to name them or change where they are stored.
+
+
+When configured, the user can also launch Google Assistant to initiate some features of the phone.
+However, if the command requires access to the userโs data (e.g. contacts for calls or messages), the
+phone requires the user to manually unlock the phone before the action can be completed.
+
+
+Beyond those actions, a user cannot perform any other actions other than observing notifications
+displayed on the lock screen until after successfully authenticating. Additionally, the TOE provides the
+user the ability to hide the contents of notifications once a password (or any other locking
+authentication method) is enabled.
+
+
+**PP_MDF_V3.3:FIA_X509_EXT.1:**
+The TOE checks the validity of all imported CA certificates by checking for the presence of the
+basicConstraints extension and that the CA flag is set to TRUE as the TOE imports the certificate. In
+addition to the check during import, the checks will be done again at use of the CA certificate.
+
+
+89 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+The TOEโs certificate validation algorithm examines each certificate in the path (starting with the peerโs
+certificate) and first checks for validity of that certificate (e.g., has the certificate expired; or if not yet
+valid, whether the certificate contains the appropriate X.509 extensions [e.g., the CA flag in the basic
+constraints extension for a CA certificate, or that a server certificate contains the Server Authentication
+purpose in the extendedKeyUsage field]), then verifies each certificate in the chain (applying the same
+rules as above, but also ensuring that the Issuer of each certificate matches the Subject in the next rung
+โupโ in the chain and that the chain ends in a self-signed certificate present in either the TOEโs trusted
+anchor database or matches a specified Root CA), and finally the TOE performs revocation checking for
+all certificates in the chain.
+
+
+For certificates imported into the TOE (not CA certificates), the checks on the validity of the certificate
+are performed on use, not on import. An imported certificate that does not meet the requirements for
+basicConstraints will fail.
+
+
+**MOD_WLANC_V1.0:FIA_X509_EXT.1/WLAN:**
+In addition to the checks performed as part of PP_MDF_V3.3:FIA_X509_EXT.1, the TOE verifies the
+extendedKeyUsage Server Authentication purpose during WPA2/EAP-TLS negotiation.
+
+
+**PP_MDF_V3.3:FIA_X509_EXT.2:**
+**MOD_WLANC_V1.0:FIA_X509_EXT.2/WLAN:**
+**MOD_WLANC_V1.0:FIA_X509_EXT.6:**
+The TOE uses X.509v3 certificates during EAP-TLS, TLS, and HTTPS. The TOE comes with a built-in set of
+default Trusted Credentials (Android's set of trusted CA certificates), and while the user cannot remove
+any of the built-in default CA certificates, the user can disable any of those certificates through the user
+interface so that certificates issued by disabled CAโs cannot validate successfully. In addition, a user and
+an administrator/MDM can import a new trusted CA certificate into the Trust Anchor Database (the TOE
+stores the new CA certificate in the Security Key Store).
+
+
+The certificates that will be used to establish EAP-TLS, TLS or HTTPS connections are stored in the key
+store specified in FCS_STG_EXT.1.
+
+
+The TOE does not establish TLS connections itself (beyond EAP-TLS used for WPA2/WPA3 Wi-Fi
+connections), but provides a series of APIs that mobile applications can use to check the validity of a
+peer certificate. The mobile application, after correctly using the specified APIs, can be assured as to the
+validity of the peer certificate and be assured that the TOE will not establish the trusted connection if
+the peer certificate cannot be verified (including validity, certification path, and revocation [through
+OCSP]). If, during the process of certificate verification, the TOE cannot establish a connection with the
+server acting as the OCSP Responder, the TOE will not deem the serverโs certificate as valid and will not
+establish a TLS connection with the server.
+
+
+For mobile applications, the application developer will specify whether the TOE should use the Android
+system Trusted CAs, use application-specified trusted CAs, or a combination of the two. In this way, the
+TOE always knows which trusted CAs to use.
+
+
+The user or administrator explicitly specifies the trusted CA that the TOE will use for EAP-TLS
+authentication of the serverโs certificate when creating a new EAP-TLS connection. The certificates are
+all checked at use.
+
+
+90 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+The TOE, when acting as a WPA2/WPA3 supplicant uses X.509 certificates for EAP-TLS authentication.
+Because the TOE may not have network connectivity to a revocation server prior to being admitted to
+the WPA2/WPA3 network and because the TOE cannot determine the IP address or hostname of the
+authentication server (the Wi-Fi access point proxies the supplicantโs authentication request to the
+server), the TOE will accept the certificate of the server.
+
+
+**PP_MDF_V3.3:FIA_X509_EXT.3:**
+Applications needing compliant revocation checking must utilize the NIAPSEC library. The NIAPSEC
+library created by the vendor provides the following functions to allow for certificate path validation and
+revocation checking:
+
+ - public boolean isValid(List certs)
+
+ - public Boolean isValid(Certificate cert)
+The first function allows for validation and revocation checking against a list of certificates, while the
+second checks a singular certificate. Revocation checking is completed using OCSP. Please see the
+FIA_X509_EXT.2/WLAN section for a further explanation on how the TOE handles revocation checking.
+
+### 6.5 Security management
+
+
+**MOD_MDM_AGENT_V1.0:FMT_POL_EXT.2**
+The TOE only accepts policies which have been signed with the private key of the MDM Server. The
+public key (downloaded as part of the enrollment process) is used to verify the integrity of the policy
+file. If the signature of the file is confirmed, the policy is applied and the MDM Server is notified of the
+successful application. If the policy signature check fails, the policy file is discarded and the MDM Server
+is notified of the failure.
+
+
+**PP_MDF_V3.3:FMT_MOF_EXT.1:**
+**PP_MDF_V3.3:FMT_SMF.1:**
+The TOE provides the management functions described in Table 16 - Security Management Functions in
+section 5. The table includes annotations describing the roles that have access to each service and how
+to access the service. The TOE enforces administrative configured restrictions by rejecting user
+configuration (through the UI) when attempted. It is worth noting that the TOEโs ability to specify
+authorized application repositories takes the form of allowing enterprise applications (i.e., restricting
+applications to only those applications installed by an MDM Agent).
+
+
+**MOD_BT_V1.0:FMT_SMF_EXT.1/BT:**
+The TOE provides the management functions described in Table 17 - Bluetooth Security Management
+Functions in section 5. The TOE enforces administrative configured restrictions by rejecting user
+configuration (through the UI) when attempted.
+
+
+**MOD_WLANC_V1.0:FMT_SMF_EXT.1/WLAN:**
+The TOE provides the management functions described in Table 18 - WLAN Security Management
+Functions in section 5. As with Table 16 - Security Management Functions, the table includes
+annotations describing the roles that have access to each service and how to access the service. The TOE
+enforces administrative configured restrictions by rejecting user configuration (through the UI) when
+attempted.
+
+
+**PP_MDF_V3.3:FMT_SMF_EXT.2:**
+
+
+91 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+The TOE offers MDM agents the ability to wipe protected data, wipe sensitive data, remove Enterprise
+applications, and remove all device stored Enterprise resource data upon un-enrollment. The TOE offers
+MDM agents the ability to wipe protected data (effectively wiping the device) at any time. Similarly, the
+TOE also offers the ability to remove Enterprise applications and a full wipe of managed profile data of
+the TOEโs Enterprise data/applications at any time. These capabilities are available as APIs that can be
+set through the MDM and then passed to the MDM agent to apply (and start the action as specified).
+
+
+**PP_MDF_V3.3:FMT_SMF_EXT.3:**
+The TOE offers MDM agents and the user the
+
+```
+ Settings -> Security -> Advanced settings -> Device admin apps
+
+```
+
+menu to view each application that has been granted admin rights, and further to see what operations
+each admin app has been granted.
+
+
+**MOD_MDM_AGENT_V1.0:FMT_SMF_EXT.4:**
+During the enrollment process, the TOE will import the MDM Server public key to be used for verifying
+the policy signature. This is handled automatically as part of the process and not as a separate function.
+The certificates necessary for connecting to the MDM Server are already present on the device.
+
+
+The TOE supports the management functions of the PP_MDF_V3.3 as specified in Table 16 - Security
+Management Functions, Table 17 - Bluetooth Security Management Functions and Table 18 - WLAN
+Security Management Functions. The TOE itself supports the enrollment into a managed configuration
+with an MDM Server but does not provide other self-management capabilities.
+
+
+**MOD_MDM_AGENT_V1.0:FMT_UNR_EXT.1:**
+When the TOE is unenrolled from management via the MDM Server, the TOE will perform remediation
+actions to the managed applications and data on the device. The user cannot initiate unenrollment (the
+user can perform a factory reset, but cannot unenroll from management). The admin can block the
+ability of the user to perform the factory reset. The remediation action is a wipe of all data on the device
+(a factory reset).
+
+### 6.6 Protection of the TSF
+
+
+**PP_MDF_V3.3:FPT_AEX_EXT.1:**
+The Linux kernel of the TOEโs Android operating system provides address space layout randomization
+utilizing the get_random_int(void) kernel random function to provide eight unpredictable bits to the
+base address of any user-space memory mapping. The random function, though not cryptographic,
+ensures that one cannot predict the value of the bits.
+
+
+**PP_MDF_V3.3:FPT_AEX_EXT.2:**
+[The TOE utilizes the 6.1 Linux kernel (https://source.android.com/devices/architecture/kernel/modular-](https://source.android.com/devices/architecture/kernel/modular-kernels#core-kernel-requirements)
+[kernels#core-kernel-requirements), whose memory management unit (MMU) enforces read, write, and](https://source.android.com/devices/architecture/kernel/modular-kernels#core-kernel-requirements)
+execute permissions on all pages of virtual memory and ensures that write and execute permissions are
+not simultaneously granted on all memory. The Android operating system sets the ARM No eXecute (XN)
+bit on memory pages and the TOEโs ARMv8 Application Processorโs Memory Management Unit (MMU)
+circuitry enforces the XN bits. From Androidโs documentation
+(https://source.android.com/devices/tech/security/index.html), Android supports 'Hardware-based No
+eXecute (NX) to prevent code execution on the stack and heap. Section D.5 of the ARMv8 Architecture
+
+
+92 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+Reference Manual contains additional details about the MMU of ARM-based processors:
+[http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.f/index.html.](http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.f/index.html)
+
+
+**PP_MDF_V3.3:FPT_AEX_EXT.3:**
+The TOEโs Android operating system provides explicit mechanisms to prevent stack buffer overruns in
+addition to taking advantage of hardware-based No eXecute to prevent code execution on the stack and
+heap. Specifically, the vendor builds the TOE (Android and support libraries) using gcc-fstack-protector
+compile option to enable stack overflow protection and Android takes advantage of hardware-based
+eXecute-Never to make the stack and heap non-executable. The vendor applies these protections to all
+TSF executable binaries and libraries.
+
+
+**PP_MDF_V3.3:FPT_AEX_EXT.4:**
+The TOE protects itself from modification by untrusted subjects using a variety of methods. The first
+protection employed by the TOE is a Secure Boot process that uses cryptographic signatures to ensure
+the authenticity and integrity of the bootloader and kernels using data fused into the device processor.
+
+
+The TOE protects its REK by limiting access to only trusted applications within the TEE (Trusted Execution
+Environment). The TOE key manager includes a TEE module that utilizes the REK to protect all other keys
+in the key hierarchy. All TEE applications are cryptographically signed, and when invoked at runtime (at
+the behest of an untrusted application), the TEE will only load the trusted application after successfully
+verifying its cryptographic signature.
+
+
+The TOE protects biometric data by separating it from the Android operating system. The biometric
+sensor is tied to the TEE such that it cannot be accessed directly from Android but can only be done
+through the biometric software inside the TEE. All biometric data is maintained within the TEE such that
+Android is only able to know the result of a biometric process (such as enrollment or verification), and
+not any of the data used in that process itself.
+
+
+Additionally, the TOEโs Android operating system provides 'sandboxing' that ensures that each thirdparty mobile application executes with the file permissions of a unique Linux user ID, in a different
+virtual memory space. This ensures that applications cannot access each otherโs memory space or files
+and cannot access the memory space or files of other applications (notwithstanding access between
+applications with a common application developer).
+
+
+While the TOE supports USSD and MMI codes, they are only available once the user has authenticated
+to the TOE through the dialer. Attempting to access these codes through the emergency dialer will be
+rejected as a non-emergency number.
+
+
+The TOE, in its evaluated configuration has its bootloader in the locked state. This prevents a user from
+installing a new software image via another method than Googleโs proscribed OTA methods. The TOE
+allows an operator to download and install an OTA update through the system settings
+
+```
+ Settings -> System -> System update -> Check for update
+
+```
+
+while the phone is running, or by separately downloading an OTA image, and then โsideloadingโ the
+OTA update from Androidโs recovery mode. In both cases, the TOE will verify the digital signature of the
+new OTA before applying the new firmware.
+
+
+For the first install of the Common Criteria compliant build, the administrator must unlock the deviceโs
+bootloader via the fastboot interface, โsideloadโ the correct build, reboot the phone back to the
+fastboot interface, re-lock the bootloader, and finally start the phone normally. For both the locking and
+
+
+93 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+unlocking of the bootloader, the device is factory reset as part of the process. This prevents an attacker
+from modifying or switching the image running on the device to allow access to sensitive data. After this
+first install of the official build, further updates can be done via normal OTA updates.
+
+
+**PP_MDF_V3.3:FPT_AEX_EXT.5:**
+The TOE models provide Kernel Address Space Layout Randomization (KASLR) as a hardening feature to
+randomize the location of kernel data structures at each boot, including the core kernel as a random
+physical address, mapping the core kernel at a random virtual address in the vmalloc area, loading
+kernel modules at a random virtual address in the vmalloc area, and mapping system memory at a
+random virtual address in the linear area. The entropy used to dictate the randomization is based on the
+hardware present within the phone. For ARM devices, such as the TOE, 13-25 bits of entropy are
+generated on boot from the DRBG in the Application Processor, from which the starting memory
+address is generated.
+
+
+**PP_MDF_V3.3:FPT_BBD_EXT.1:**
+The TOEโs hardware and software architecture ensures separation of the application processor (AP)
+from the baseband or communications processor (CP) through internal controls of the TOEโs SoC, which
+contains both the AP and the CP. The AP restricts hardware access control through a protection unit that
+restricts software access from the baseband processor through a dedicated 'modem interface'. The
+protection unit combines the functionality of the Memory Protection Unit (MPU), the Register
+Protection Unit (RPU), and the Address Protection Unit (APU) into a single function that conditionally
+grants access by a master to a software defined area of memory, to registers, or to a pre-decoded
+address region, respectively. The modem interface provides a set of APIs (grouped into five categories)
+to enable a high-level OS to send messages to a service defined on the modem/baseband processor. The
+combination of hardware and software restrictions ensures that the TOEโs AP prevents software
+executing on the modem or baseband processor from accessing the resources of the application
+processor (outside of the defined methods, mediated by the application processor).
+
+
+**MOD_BIO_V1.1:FPT_BDP_EXT.1:**
+The complete biometric authentication process happens inside the TEE (including image capture, all
+processing and match determination). All software in the biometric system is inside the TEE boundary,
+while the sensors are accessible from within Android. The TEE handles calls for authentication made
+from Android with only the success or failure of the match provided back to Android (and when
+applicable, to the calling app). The image taken by the capture sensor is processed by the biometric
+service to check the enrolled templates for a match to the captured image.
+
+
+**PP_MDF_V3.3:FPT_JTA_EXT.1:**
+The TOE prevents access to its processorโs JTAG interface by requiring use of a signing key to
+authenticate prior to gaining JTAG access. Only a JTAG image with the accompanying device serial
+number (which is different for each mobile device) that has been signed by Googleโs private key can be
+used to access a deviceโs JTAG interface. The Google private key corresponds to the Google RSA 2048-bit
+public key (a SHA-256 hash of which is fused into the TOEโs application processor).
+
+
+**PP_MDF_V3.3 & MOD_BIO_V1.1:FPT_KST_EXT.1:**
+The TOE does not store any plaintext key or biometrics material in its internal Flash; the TOE encrypts all
+keys and biometric data before storing them. This ensures that irrespective of how the TOE powers
+down (e.g., a user commands the TOE to power down, the TOE reboots itself, or battery depletes or is
+removed), all keys and biometric data stored in the internal Flash are wrapped with a KEK. Please refer
+
+
+94 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+to section 6.2 of the TSS for further information (including the KEK used) regarding the encryption of
+keys stored in the internal Flash. As the TOE encrypts all keys stored in Flash, upon boot-up, the TOE
+must first decrypt any keys in order to utilize them.
+
+
+**PP_MDF_V3.3 & MOD_BIO_V1.1:FPT_KST_EXT.2:**
+The TOE itself (i.e., the mobile device) comprises a cryptographic module that utilizes cryptographic
+libraries including BoringSSL, application processor cryptography (which leverages AP hardware), and
+the following system-level executables that utilize KEKs: vold, wpa_supplicant, and the Android Key
+Store.
+
+
+1. vold and application processor hardware provides Data-At-Rest encryption of the user data
+
+partition in Flash using the Google Tensor Inline Storage Encryption (ISE)
+2. wpa_supplicant provides WPA2/WPA3 services
+3. the Android Key Store application provides key generation, storage, deletion services to mobile
+
+applications and to user through the UI
+The TOE ensures that plaintext key material is not exported by not allowing the REK to be exported and
+by ensuring that only authenticated entities can request utilization of the REK. Furthermore, the TOE
+only allows the system-level executables access to plaintext DEK values needed for their operation. The
+TSF software (the system-level executables) protects those plaintext DEK values in memory both by not
+providing any access to these values and by clearing them when no longer needed (in compliance with
+FCS_CKM_EXT.4). Note that the TOE does not use the biometric template to encrypt/protect key
+material (and instead only relies upon the userโs password).
+
+
+The TOE also ensures that biometric data used for enrolling and authenticating users can not be
+exported. During authentication or enrollment, the calling program (the TSF or an app) is able to request
+biometric actions, but the data resulting from that action is not provided back to the calling program.
+The calling program only receives a notice of success of failure about the process.
+
+
+**PP_MDF_V3.3:FPT_KST_EXT.3:**
+The TOE does not provide any way to export plaintext DEKs or KEKs (including all keys stored in the
+Android Key Store) as the TOE chains or directly encrypts all KEKs to the REK.
+
+
+Furthermore, the components of the device are designed to prevent transmission of key material
+outside the device. Each internal system component requiring access to a plaintext key (for example the
+Wi-Fi driver) must have the necessary precursor(s), whether that be a password from the user or file
+access to key in Flash (for example the encrypted AES key used for encryption of the Flash data
+partition). With those appropriate precursors, the internal system-level component may call directly to
+the system-level library to obtain the plaintext key value. The system library in turn requests decryption
+from a component executing inside the trusted execution environment and then directly returns the
+plaintext key value (assuming that it can successfully decrypt the requested key, as confirmed by the
+CCM/GCM verification) to the calling system component. That system component will then utilize that
+key (in the example, the kernel which holds the key in order to encrypt and decrypt reads and writes to
+the encrypted user data partition files in Flash). In this way, only the internal system components
+responsible for a given activity have access to the plaintext key needed for the activity, and that
+component receives the plaintext key value directly from the system library.
+
+
+For a userโs mobile applications, those applications do not have any access to any system-level
+components and only have access to keys that the application has imported into the Android Key Store.
+
+
+95 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+Upon requesting access to a key, the mobile application receives the plaintext key value back from the
+system library through the Android API. Mobile applications do not have access to the memory space of
+any other mobile application so it is not possible for a malicious application to intercept the plaintext
+key value to then log or transmit the value off the device.
+
+
+**PP_MDF_V3.3:FPT_NOT_EXT.1:**
+When the TOE encounters a critical failure (either a self-test failure or TOE software integrity verification
+failure), the TOE attempts to reboot. If the failure persists between boots, the user may attempt to boot
+to the recovery mode/kernel to wipe data and perform a factory reset in order to recover the device.
+
+
+**MOD_BIO_V1.1:FPT_PBT_EXT.1:**
+The TOE requires the user to enter their password to enroll, re-enroll or unenroll any biometric
+templates. When the user attempts biometric authentication to the TOE, the biometric sensor takes an
+image of the presented biometric for comparison to the enrolled templates. The biometric system
+compares the captured image to all the stored templates on the device to determine if there is a match.
+
+
+**PP_MDF_V3.3:FPT_STM.1:**
+The TOE requires time for the Package Manager (which installs and verifies APK signatures and
+certificates), image verifier, wpa_supplicant, and Android Key Store applications. These TOE components
+obtain time from the TOE using system API calls [e.g., time() or gettimeofday()]. An application (unless a
+system application is residing in /system/priv-app or signed by the vendor) cannot modify the system
+time as mobile applications need the Android 'SET_TIME' permission to do so. Likewise, only a process
+with root privileges can directly modify the system time using system-level APIs. Further, this stored
+time is used both for the time/date tags in audit logs and is used to track inactivity timeouts that force
+the TOE into a locked state.
+
+
+By default, the TOE uses the Cellular Carrier time (obtained through the Carrierโs network time server)
+as the trusted time source. The admin can decide to not use cellular time as the trusted source but
+instead use a NTP server to set the trusted time. The default NTP server is a Google-hosted server
+source, but this can be changed by the admin to point to another trusted server. It is also possible to let
+the user set the date and time through the TOEโs user interface and use the internal clock to maintain a
+local (as opposed to externally checked) trusted time.
+
+
+**PP_MDF_V3.3:FPT_TST_EXT.1:**
+The TOE automatically performs known answer power on self-tests (POST) on its cryptographic
+algorithms to ensure that they are functioning correctly. Each component providing cryptography
+performs known answer tests on their cryptographic algorithms to ensure they are working correctly.
+Should any of the tests fail, the TOE displays an error message stating โBoot Failureโ and halts the boot
+process, displays an error to the screen, and forces a reboot of the device.
+
+
+
+
+
+
+
+
+
+|Algorithm|Implemented in|Description|
+|---|---|---|
+|AES encryption/decryption|BoringSSL
Kernel
Storage
Application Processor
Titan chip|Comparison of known answer to calculated value|
+|ECDH key agreement|BoringSSL|Comparison of known answer to calculated value|
+
+
+96 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+|Algorithm|Implemented in|Description|
+|---|---|---|
+|DRBG random bit generation|BoringSSL
Application Processor
Titan chip|Comparison of known answer to calculated value|
+|ECDSA sign/verify|BoringSSL|Comparison of known answer to calculated value|
+|HMAC-SHA|BoringSSL
Kernel
Storage
Application Processor
Titan chip|Comparison of known answer to calculated value|
+|RSA sign/verify|BoringSSL|Comparison of known answer to calculated value|
+|SHA hashing|BoringSSL
Kernel
Storage
Application Processor
Titan chip|Comparison of known answer to calculated value|
+
+
+
+_**Table 38 - Power-up Cryptographic Algorithm Known Answer Tests**_
+
+
+**PP_MDF_V3.3:FPT_TST_EXT.2/PREKERNEL:**
+**PP_MDF_V3.3:FPT_TST_EXT.2/POSTKERNEL:**
+**MOD_WLANC_V1.0:FPT_TST_EXT.3/WLAN:**
+The TOE ensures a secure boot process in which the TOE verifies the digital signature of the bootloader
+software for the Application Processor (using a public key whose hash resides in the processorโs internal
+fuses) before transferring control. The bootloader, in turn, verifies the signature of the Linux kernel it
+loads. This series of checks occur for all boot modes (normal, recovery and fastboot). The recovery and
+fastboot modes utilize the same alternative boot mode but expose different software to the user once
+the boot is complete.
+
+
+For any boot mode, the TOE performs checking of the entire /system and /vendor partitions through use
+of Androidโs dm-verity mechanism (and while the TOE will still operate, it will log any blocks/executables
+that have been modified). Some limited failures (changes under a block size, depending on the location
+of the failure) can be automatically self-corrected as part of the check process.
+
+
+dm-verity is a hash table of the block device used for storage (in this case the /system and /vendor
+partitions) where every 4k block has a SHA256. These hashes are then concatenated and every 4k of
+that hash is again hashed. This is repeated until a 4k root hash is generated (this is normally 4 total
+layers of hashes), and this root hash is signed with the keys used to verify the signature of the Linux
+kernel. The Wi-Fi components are included in the /system partition and are verified as part of the dmverity check of that partition as part of the platform checks.
+
+
+**PP_MDF_V3.3:FPT_TUD_EXT.1:**
+The TOEโs user interface provides a method to query the current version of the TOE software/firmware
+(Android version, baseband version, kernel version, build number, and software version) and hardware
+(model and version). Additionally, the TOE provides users the ability to review the currently installed
+apps (including 3rd party 'built-in' applications) and their version.
+
+
+**PP_MDF_V3.3:FPT_TUD_EXT.2:**
+The TOE verifies all OTA (over-the-air) updates to the TOE software (which includes baseband processor
+updates) using a public key chaining ultimately to the Root Public Key, a hardware protected key whose
+
+
+97 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+SHA-256 hash resides inside the application processor. Should this verification fail, the software update
+will fail and the update will not be installed.
+
+
+The application processor verifies the bootloaderโs authenticity and integrity (thus tying the bootloader
+and subsequent stages to a hardware root of trust: the SHA-256 hash of the Root Public Key, which
+cannot be reprogrammed after the โwrite-enableโ fuse has been blown).
+
+
+**PP_MDF_V3.3:FPT_TUD_EXT.3:**
+The Android OS on the TOE requires that all applications bear a valid signature before Android will install
+the application.
+
+
+Additionally, Android allows updates through Google Play updates, including both APK and APEX files.
+Both file types use Android APK signature format and the TOE verifies the accompanying signature prior
+to installing the file (additionally, Android ensures that updates to existing files use the same signing
+certificate). APEX files are used to update low level modules within Android that are not traditional
+applications and as such are not easily able to be updated using a traditional APK. These files both follow
+the same format, structure and signature requirements.
+
+
+**PP_MDF_V3.3:FPT_TUD_EXT.6:**
+The TOE maintains a monotonic anti-rollback counter used to set a minimum version for the TOE
+software. Before a new update can be installed, the version of the new software is compared to the
+counter version. The update is allowed only if the version of the new software is equal or greater than
+the counter. APEX files, which update the TOE software also follow the anti-rollback counter of the
+device preventing downgrades.
+
+### 6.7 TOE access
+
+
+**PP_MDF_V3.3:FTA_SSL_EXT.1:**
+The TOE transitions to its locked state either immediately after a User initiates a lock by pressing the
+power button (if configured) or after a (also configurable) period of inactivity, and as part of that
+transition, the TOE will display a lock screen (the KeyGuard lock screen) to obscure the previous
+contents and play a โlock soundโ to indicate the phoneโs transition; however, the TOEโs lock screen still
+displays email notifications, calendar appointments, user configured widgets, text message notifications,
+the time, date, call notifications, battery life, signal strength, and carrier network. But without
+authenticating first, a user cannot perform any related actions based upon these notifications (they
+cannot respond to emails, calendar appointments, or text messages) other than the actions assigned in
+Timing of Authentication (PP_MDF_V3.3:FIA_UAU_EXT.2).
+
+
+The administrator can also force the device into the locked state through the use of an MDM.
+
+
+Note that during power up, the TOE presents the user with an unlock screen stating โunlock for all
+features and dataโ. While at this screen, the TOE has already decrypted Device Encrypted (DE) files
+within the userdata partition, but cannot yet decrypt the userโs Credential Encrypted (CE) files. The user
+can only access a subset of device functionality before authenticating (e.g. the user can making an
+emergency call, receive incoming calls, receiving alarms, and any other โdirect bootโ functionality). After
+the user enters their password, the TOE decrypts the userโs CE files within the user data partition and
+the user has unlocked the full functionality of the phone. After this initial authentication, upon
+(re)locking the phone, the TOE presents the user with the previously mentioned KeyGuard lock screen.
+While locked, the actions described in FIA_UAU_EXT.2.1 are available for the user to utilize.
+
+98 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+
+**PP_MDF_V3.3:FTA_TAB.1:**
+The TOE can be configured to display a user-specified message on the Lock screen, and additionally an
+administrator can also set a Lock screen message using an MDM.
+
+
+**MOD_WLANC_V1.0:FTA_WSE_EXT.1:**
+The TOE allows an administrator to specify (through the use of an MDM) a list of wireless networks
+(SSIDs) to which the user may direct the TOE to connect to, the security type, authentication protocol,
+and the client credentials to be used for authentication. When not enrolled with an MDM, the TOE
+allows the user to control to which wireless networks the TOE should connect, but does not provide an
+explicit list of such networks, rather the user may scan for available wireless network (or directly enter a
+specific wireless network), and then connect. Once a user has connected to a wireless network, the TOE
+will automatically reconnect to that network when in range and the user has enabled the TOEโs Wi-Fi
+radio.
+
+### 6.8 Trusted path/channels
+
+
+**MOD_BT_V1.0:FTP_BLT_EXT.1:**
+**MOD_BT_V1.0:FTP_BLT_EXT.3/BR:**
+**MOD_BT_V1.0:FTP_BLT_EXT.3/LE:**
+The TSF enforces the use of encryption by default, over Bluetooth BD/EDR and LE connections using at
+least 128-bit AES encryption keys and does not allow the key length to be renegotiated below the length
+set at the pairing (the request to change the size will be rejected, and the connection terminated if this
+is not accepted). ECDH is used to generate key pairs for the devices to exchange symmetric keys. The
+admin cannot configure key sizes.
+
+
+**MOD_BT_V1.0:FTP_BLT_EXT.2:**
+The TSF will terminate a connection with a remote device if the remote device requests to terminate
+encryption.
+
+
+**PP_MDF_V3.3:FTP_ITC_EXT.1:**
+The TOE provides secured (encrypted and mutually authenticated) communication channels between
+itself and other trusted IT products through the use of TLS and HTTPS. The TOE provides mobile
+applications and MDM agent applications access to HTTPS and TLS via published APIs, thus facilitating
+administrative communication and configured enterprise connections. These APIs are accessible to any
+application that needs an encrypted end-to-end trusted channel.
+
+
+The TOE also uses TLS connections to download OTA updates for the device.
+
+
+**MOD_WLANC_V1.0:FTP_ITC.1/WLAN:**
+The TOE provides secured (encrypted and mutually authenticated) communication channels between
+itself and other trusted IT products through the use of IEEE 802.11-2012, 802.1X, and EAP-TLS. The TOE
+permits itself and applications to initiate communicate via the trusted channel, and the TOE initiates
+communications via the WPA2/WPA3 (IEEE 802.11-2012, 802.1X with EAP-TLS) trusted channel for
+connection to a wireless access point.
+
+
+**MOD_MDM_AGENT_V1.0:FTP_ITC_EXT.1(2):**
+**MOD_MDM_AGENT_V1.0:FTP_TRP.1(2):**
+The TSF uses HTTPS connections for both enrollment with the MDM Server as well as for the
+communication channel for normal operations.
+
+99 of 100
+
+
+Google Pixel Devices on Android 15 โ Security Target Version: 1.0
+Date: April 4, 2025
+
+### 6.9 Live Cycle
+
+
+**PP_MDF_V3.3:ALC_TSU_EXT.1:**
+Google supports a bug filing system for the Android OS outlined here:
+[https://source.android.com/setup/contribute/report-bugs. This allows developers or users to search for,](https://source.android.com/setup/contribute/report-bugs)
+file, and vote on bugs that need to be fixed. This helps to ensure that all bugs that affect large numbers
+of people get pushed up in priority to be fixed. The method outlined above requires the user to submit
+their bug to Androidโs website. As such, the user of the device needs to establish a trusted channel web
+connection to securely file the bug by following the set-up steps to establish a secure HTTPS/TLS/EAPTLS connection from the TOE, then visiting the above web portal to submit the report.
+
+
+Google also commits to pushing out monthly security updates for the Android operating system
+(including the Java layer and kernel, not including applications). Google provides security updates for at
+least three years from the device launch. The latest information about this can be found at
+[https://support.google.com/nexus/answer/4457705 (for smartphones) and](https://support.google.com/nexus/answer/4457705)
+[https://support.google.com/googlepixeltablet/answer/13399216](https://support.google.com/googlepixeltablet/answer/13399216) (for tablets), summarized in Table 39.
+
+|Device|Android
updates to|Security
patched to|
+|---|---|---|
+|Pixel 9 Pro XL/9
Pro/9/9 Pro Fold/9a|Aug 2031|Aug 2031|
+|Pixel 8a|May 2031|May 2031|
+|Pixel 8 Pro/8|Oct 2030|Oct 2030|
+|Pixel Tablet|Jun 2026|Jun 2028|
+|Pixel Fold|Jun 2028|Jun 2028|
+|Pixel 7 Pro/7|Oct 2027|Oct 2027|
+|Pixel 7a|May 2028|May 2028|
+|Pixel 6 Pro/6|Oct 2026|Oct 2026|
+|Pixel 6a|Jul 2027|Jul 2027|
+
+
+
+_**Table 39 - Security Update Period**_
+
+
+These systematic updates are designed to address the highest issue problems as quickly as possible and
+allows Google to ensure their Pixel products remain as safe as possible and any issues are addressed
+promptly. Google posts Android Security Bulletins with each release showing the patches that are
+[included https://source.android.com/docs/security/bulletin.](https://source.android.com/docs/security/bulletin)
+
+
+Google creates updates and patches to resolve reported issues as quickly as possible. The delivery time
+for resolving an issue depends on the severity, and can be as rapid as a few days before the update can
+be deployed for high priority cases. Google maintains a security blog (https://android[developers.googleblog.com/) to disseminate information directly to the public.](https://android-developers.googleblog.com/)
+
+
+100 of 100
+
+
+
diff --git a/niap-cc/sdp-file-encrypt/doc/knowledge_base/st-samsung-android15.md b/niap-cc/sdp-file-encrypt/doc/knowledge_base/st-samsung-android15.md
new file mode 100644
index 0000000..8c46f0a
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/doc/knowledge_base/st-samsung-android15.md
@@ -0,0 +1,6532 @@
+Consider using the pymupdf_layout package for a greatly improved page layout analysis.
+# Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ Spring Security Target
+
+Version: 0.4
+07/01/2025
+
+
+_**Prepared for:**_
+
+## **Samsung Electronics Co., Ltd.**
+
+
+416 Maetan-3dong, Yeongtong-gu, Suwon-si, Gyeonggi-do, 443-742 Korea
+
+
+_**Prepared By:**_
+
+
+[www.gossamersec.com](http://www.gossamersec.com/)
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+## Table of Contents
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+**1** **Security Target Introduction ......................................................................................................... 4**
+1.1 Security Target Reference ............................................................................................................. 6
+1.2 TOE Reference ............................................................................................................................... 6
+1.3 TOE Overview ................................................................................................................................ 6
+1.4 TOE Description ............................................................................................................................. 6
+1.4.1 TOE Architecture ................................................................................................................. 12
+1.4.2 TOE Documentation ............................................................................................................ 14
+**2** **Conformance Claims................................................................................................................... 15**
+2.1 Conformance Rationale .............................................................................................................. 16
+**3** **Security Objectives ..................................................................................................................... 17**
+3.1 Security Objectives for the Operational Environment ................................................................ 17
+**4** **Extended Components Definition ............................................................................................... 18**
+**5** **Security Requirements ............................................................................................................... 21**
+5.1 TOE Security Functional Requirements ...................................................................................... 21
+5.1.1 Security Audit (FAU) ............................................................................................................ 24
+5.1.2 Cryptographic Support (FCS) ............................................................................................... 25
+5.1.3 User Data Protection (FDP) ................................................................................................. 35
+5.1.4 Identification and Authentication (FIA) .............................................................................. 38
+5.1.5 Security Management (FMT) .............................................................................................. 44
+5.1.6 Protection of the TSF (FPT) ................................................................................................. 52
+5.1.7 TOE Access (FTA) ................................................................................................................. 55
+5.1.8 Trusted Path/Channels (FTP) .............................................................................................. 56
+5.2 TOE Security Assurance Requirements ....................................................................................... 57
+5.2.1 Development (ADV) ............................................................................................................ 57
+5.2.2 Guidance Documents (AGD) ............................................................................................... 58
+5.2.3 Life-cycle Support (ALC) ...................................................................................................... 59
+5.2.4 Tests (ATE) ........................................................................................................................... 60
+5.2.5 Vulnerability Assessment (AVA) .......................................................................................... 60
+**6** **TOE Summary Specification ........................................................................................................ 61**
+6.1 Security Audit .............................................................................................................................. 61
+6.2 Cryptographic Support ................................................................................................................ 63
+6.3 User Data Protection ................................................................................................................... 77
+6.4 Identification and Authentication ............................................................................................... 82
+6.5 Security Management ................................................................................................................. 88
+6.6 Protection of the TSF .................................................................................................................. 89
+6.7 TOE Access .................................................................................................................................. 94
+6.8 Trusted Path/Channels ............................................................................................................... 95
+6.9 Work Profile Functionality .......................................................................................................... 95
+
+
+2 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+## List of Tables
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+Table 1 - Glossary .......................................................................................................................................... 5
+Table 2 - Evaluated Devices .......................................................................................................................... 7
+Table 3 โ Equivalent Devices......................................................................................................................... 9
+Table 4 - Carrier Models .............................................................................................................................. 12
+Table 5 - Technical Decisions ...................................................................................................................... 16
+Table 6 - Extended SFRs and SARs .............................................................................................................. 20
+Table 7 - TOE Security Functional Requirements ........................................................................................ 24
+Table 8 - Security Management Functions ................................................................................................. 50
+Table 9 - Bluetooth Security Management Functions ................................................................................ 50
+Table 10 - WLAN Security Management Functions .................................................................................... 51
+Table 11 - VPN Security Management Functions ....................................................................................... 51
+Table 12 - Audit Events ............................................................................................................................... 62
+Table 13 โ Bluetooth Audit Events ............................................................................................................. 62
+Table 14 โ WLAN Client Audit Events ......................................................................................................... 62
+Table 15 - Asymmetric Key Generation per Module .................................................................................. 63
+Table 16 - W-Fi Alliance Certificates ........................................................................................................... 65
+Table 17 - Salt Creation ............................................................................................................................... 67
+Table 18 - BoringSSL Cryptographic Algorithms ......................................................................................... 68
+Table 19 - Samsung Crypto Extension Cryptographic Algorithms .............................................................. 68
+Table 20 - Kernel Versions .......................................................................................................................... 68
+Table 21 - Samsung Kernel Cryptographic Algorithms ............................................................................... 69
+Table 22 - TEE Environments ...................................................................................................................... 69
+Table 23 - SCrypto TEE Cryptographic Algorithms ...................................................................................... 69
+Table 24 - Hardware Components .............................................................................................................. 70
+Table 25 - Storage Hardware Algorithms .................................................................................................... 70
+Table 26 - Wi-Fi Hardware Components ..................................................................................................... 71
+Table 27 - Wi-Fi Chip Algorithms ................................................................................................................ 71
+Table 28 - Mutable Key Storage Components ............................................................................................ 72
+Table 29 - Mutable Key Storage Cryptographic Algorithms........................................................................ 72
+Table 30 - SoC Cryptographic Algorithms ................................................................................................... 72
+Table 31 - Key Management Matrix ........................................................................................................... 76
+Table 32 - Access Control Categories .......................................................................................................... 79
+Table 33 - Device biometric sensor ............................................................................................................. 84
+Table 34 - Allowed Lock Screen Authentication Methods .......................................................................... 86
+Table 35 - Secure Boot Public Keys ............................................................................................................. 90
+Table 36 - Power-up Cryptographic Algorithm Self-Tests ........................................................................... 93
+
+
+3 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+## 1 Security Target Introduction
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+This section identifies the Security Target (ST) and Target of Evaluation (TOE) identification, ST
+conventions, ST conformance claims, and the ST organization. The TOE consists of the Samsung Galaxy
+Devices on Android 15 โ Spring provided by Samsung Electronics Co., Ltd. The TOE is being evaluated as
+a Mobile Device.
+
+
+The Security Target contains the following additional sections:
+
+ - Conformance Claims (Section 2)
+
+ - Security Objectives (Section 3)
+
+ - Extended Components Definition (Section 4)
+
+ - Security Requirements (Section 5)
+
+ - TOE Summary Specification (Section 6)
+
+
+_**Acronyms and Terminology**_
+
+
+AA Assurance Activity
+
+
+BAF Biometric Authentication Factor
+
+
+CC Common Criteria
+
+
+CCEVS Common Criteria Evaluation and Validation Scheme
+
+
+EAR Entropy Analysis Report
+
+
+FBE File-based Encryption
+
+
+GUI Graphical User Interface
+
+
+MDM Mobile Device Management
+
+
+NFC Near Field Communication
+
+
+PAD Presentation Attack Detection
+
+
+PAI Presentation Attack Instrument
+
+
+PCL Product Compliant List
+
+
+PP Protection Profile
+
+
+REK Root Encryption Key
+
+
+SAR Security Assurance Requirement
+
+
+SFR Security Functional Requirement
+
+
+SOC System on Chip
+
+
+SOF Strength of Function
+
+
+ST Security Target
+
+
+TEE Trusted Execution Environment (TrustZone)
+
+
+TOE Target of Evaluation
+
+
+4 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+TSF TOE Security Functionality
+
+
+U.S. United States
+
+
+VR Validation Report
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+|Glossary|Col2|
+|---|---|
+|Device Lock Screen
Android Lock Screen|The Device Lock Screen is the Android OS lock screen.|
+|File-Based Encryption
(FBE)|FBE allowed files to be encrypted with different keys and unlocked individually based
on different authentication/access controls. This is implemented as part of the ext4
or f2fs file system (using fscrypt).|
+|Firmware Over-the-air
(FOTA)|Firmware Over-the-air is a term for the process of updating the firmware (operating
system and services) on the device via a wireless connection as opposed to a wired
(i.e. USB) connection.|
+|Personal Profile|The personal profile is the common Android user on the device, such as when the
device is first setup. While the name implies this space is for the end user and not the
Enterprise, this can be configured as needed by the MDM. This is in contrast to a
work profile.|
+|Work Profile|The work profile is a second profile on a device created specifically by the MDM and
used to segment enterprise data from what may be personal data. The work profile
maintains separate authentication to access any apps or data stored within.|
+
+
+_**Conventions**_
+
+
+
+_**Table 1 - Glossary**_
+
+
+
+The following conventions have been applied in this document:
+
+ - Security Functional Requirements โ Part 2 of the CC defines the approved set of operations that
+may be applied to functional requirements: iteration, assignment, selection, and refinement.
+
+`o` Iteration: allows a component to be used more than once with varying operations. In the ST,
+
+iteration is indicated by a parenthetical number placed at the end of the component. For
+example FDP_ACC.1(1) and FDP_ACC.1(2) indicate that the ST includes two iterations of the
+FDP_ACC.1 requirement. Alternately, a usually descriptive textual extension may be added
+after a slash (/) character to identify a specific iteration. For example, iterations of a
+requirement such as FCS_COP.1 might be identified as FCS_COP.1/HASH and
+FCS_COP.1/CRYPT.
+
+`o` Assignment: allows the specification of an identified parameter. Assignments are indicated
+
+using bold and are surrounded by brackets (e.g., [ **assignment** ]). Note that an assignment
+within a selection would be identified in italics and with embedded bold brackets (e.g.,
+
+[ _**[selected-assignment]**_ ]).
+
+`o` Selection: allows the specification of one or more elements from a list. Selections are
+
+indicated using bold italics and are surrounded by brackets (e.g., [ _**selection**_ ]).
+
+`o` Refinement: allows the addition of details. Refinements are indicated using bold, for
+
+additions, and strike-through, for deletions (e.g., โโฆ all objects โฆโ or โโฆ some big things โฆโ).
+
+ - Other sections of the ST โ Other sections of the ST use bolding to highlight text of special
+interest, such as captions.
+
+
+5 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+### 1.1 Security Target Reference
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+**ST Title** - Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ Spring Security Target
+
+
+**ST Version** - Version 0.4
+
+
+**ST Date** - 07/01/2025
+
+
+**Proprietary Documentation** (sections with additional information are marked with KMD in the section
+title)
+
+
+**KMD Title** - Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 -Spring Key
+Management Description
+
+
+**KMD Version** - Version 0.4
+
+
+**KMD Date** - 07/01/2025
+
+### 1.2 TOE Reference
+
+
+**TOE Identification** โSamsung Galaxy Devices on Android 15 - Spring
+
+
+**TOE Developer** - Samsung Electronics Co., Ltd.
+
+
+**Evaluation Sponsor** - Samsung Electronics Co., Ltd.
+
+### 1.3 TOE Overview
+
+
+The Target of Evaluation (TOE) are the Samsung Galaxy Devices on Android 15 โSpring.
+
+### 1.4 TOE Description
+
+
+The TOE is a mobile device based on Android 15 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.
+
+
+The 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.
+
+ - Require a boot and device lock password (swipe, PIN, pattern, accessibility (direction), screen
+locks are not allowed). Acceptable biometrics are fingerprint for each device.
+
+ - The maximum password failure retry policy should be less than or equal to 30.
+
+ - A screen lock password required to decrypt data on boot.
+
+ - Security and audit logging must be enabled.
+
+ - External storage must be encrypted.
+
+ - When CC mode has been enabled, the TOE behaves as follows:
+
+`o` The TOE sets the system wide Android CC mode property to be enabled.
+
+`o` The TOE prevents loading of custom firmware/kernels and requires all updates occur
+
+through FOTA.
+
+`o` The TOE utilizes ACVP/CAVP approved cryptographic ciphers for TLS.
+
+
+6 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+The 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. The TOE also requires loaded applications must be
+implemented utilizing the NIAPSEC library.
+
+
+There are different models of the TOE, the Samsung Galaxy Devices on Android 15, and these models
+differ in their internal components (as described in the table below). All devices are A64 architecture.
+
+
+The model numbers of the mobile devices used during evaluation testing are as follows:
+
+
+_**Table 2 - Evaluated Devices**_
+
+
+7 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+In addition to the evaluated devices, **Error! Reference source not found.** 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+8 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+_**Table 3 โ Equivalent Devices**_
+
+
+For 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).
+
+
+9 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+10 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+11 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+
+
+
+
+
+
+
+
+_**Table 4 - Carrier Models**_
+
+
+1.4.1 TOE Architecture
+
+
+The TOE combines with a Mobile Device Management solution (note that this evaluation does not
+include an MDM agent nor server) that enables the Enterprise to watch, control and administer all
+deployed mobile devices, across multiple mobile service providers as well as facilitate secure
+communications through a VPN. This partnership provides a secure mobile environment that can be
+managed and controlled by the environment and reduces the risks inherent in any mobile deployment.
+
+
+Data on the TOE is protected through the implementation of Samsung File-Based Encryption (FBE) that
+utilizes ACVP/CAVP certified cryptographic algorithms to encrypt device storage. This functionality is
+combined with a number of on-device policies including local wipe, remote wipe, password complexity,
+automatic lock and privileged access to security configurations to prevent unauthorized access to the
+device and stored data.
+
+
+The Knox Platform for Enterprise provides a set of flexible deployment options for work environments.
+With Knox Platform for Enterprise, it is possible to segment the device into two separate areas, by
+convention called the personal profile and the work profile. In creating a work profile, the Enterprise
+establishes a completely separate workspace, with its own authentication, applications and services,
+and ensure they are kept separate from anything the user may do in the personal profile. Another
+option for deployment is Knox Separated Apps, a folder where the Enterprise can isolate a group of
+applications from the rest of the device, restricting access to shared information, while maintaining
+seamless access to the isolated applications for the user.
+
+
+The Samsung Knox Software Development Kit (SDK) builds on top of the existing Android security model
+by expanding the current set of security configuration options to more than 600 configurable policies
+and including additional security functionality such as application allow and block listing.
+
+
+_1.4.1.1_ _Physical Boundaries_
+
+
+The TOE is a multi-user capable mobile device based on Android 15 that incorporates the Samsung Knox
+SDK. The TOE does not include the user applications that run on top of the operating system, but does
+include controls that limit application behavior. The TOE includes an IPsec VPN client integrated into the
+firmware (as opposed to a downloadable application). Within an Enterprise environment, the Enterprise
+can manage the configuration of the mobile device, including the VPN client, through a compliant device
+management solution.
+
+
+The TOE communicates and interacts with 802.11-2012 Access Points and mobile data networks to
+establish network connectivity, and the through that connectivity interacts with MDM servers that allow
+administrative control of the TOE.
+
+
+12 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+_1.4.1.2_ _Logical Boundaries_
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+This section summarizes the security functions provided by the Samsung Galaxy Devices on Android 15:
+
+ - Security Audit
+
+ - Cryptographic support
+
+ - User data protection
+
+ - Identification and authentication
+
+ - Security management
+
+ - Protection of the TSF
+
+ - TOE access
+
+ - Trusted path/channels
+
+
+_1.4.1.2.1_ _Security Audit_
+
+
+The 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.
+
+
+_1.4.1.2.2_ _Cryptographic Support_
+
+
+The 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.
+
+
+_1.4.1.2.3_ _User Data Protection_
+
+
+The 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.
+
+
+_1.4.1.2.4_ _Identification 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. 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
+
+
+13 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+device (Note: This only works after the primary authentication method, password, has been entered
+after the device powers on).
+
+
+The TOE can also serve as an 802.1X supplicant and can use X.509v3 and validate certificates for EAPTLS, TLS and IPsec exchanges. The TOE can also act as a client or server in an authenticated Bluetooth
+pairing.
+
+
+_1.4.1.2.5_ _Security Management_
+
+
+The 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.
+
+
+_1.4.1.2.6_ _Protection of the TSF_
+
+
+The 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.
+
+
+The 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.
+
+
+_1.4.1.2.7_ _TOE 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.
+
+
+The TOE is also able to attempt to connect to wireless networks as configured.
+
+
+_1.4.1.2.8_ _Trusted Path/Channels_
+
+
+The 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.
+
+
+1.4.2 TOE Documentation
+
+
+ - Samsung Android 15 on Galaxy Devices Administrator Guide, version 9.0.4, July 1, 2025
+
+
+14 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+## 2 Conformance Claims
+
+
+This TOE is conformant to the following CC specifications:
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+
+- Common Criteria for Information Technology Security Evaluation Part 2: Security functional
+components, Version 3.1, Revision 5, April 2017.
+
+`o` Part 2 Extended
+
+- Common Criteria for Information Technology Security Evaluation Part 3: Security assurance
+components, Version 3.1 Revision 5, April 2017.
+
+`o` Part 3 Extended
+
+- PP-Configuration for Mobile Device Fundamentals, Biometric enrollment and verification โ for
+unlocking the device, Bluetooth, Virtual Private Network (VPN) Clients, and WLAN Clients,
+Version 1.0, 24 October 2022 (CFG_MDF-BIO-BT-VPNC-WLANC_V1.0)
+
+`o` The PP-Configuration includes the following components:
+
+ - Base-PP: Protection Profile for Mobile Device Fundamentals, Version 3.3,
+(PP_MDF_V3.3)
+
+ - PP-Module: PP-Module for Virtual Private Network (VPN) Clients, Version 2.4,
+(MOD_VPNC_V2.4)
+
+ - PP-Module: PP-Module for Bluetooth, Version 1.0, (MOD_BT_V1.0)
+
+ - PP-Module for WLAN Client, Version 1.0 (MOD_WLANC_V1.0)
+
+ - PP-Module: collaborative PP-Module for Biometric enrolment and verification for unlocking the device - [BIOPP-Module], Version 1.1, September 12, 2022
+(MOD_CPP_BIO_V1.1)
+
+- Package Claims:
+
+`o` Functional Package: Functional Package for Transport Layer Security (TLS), Version 1.1,
+
+(PKG_TLS_V1.1)
+
+- Technical Decisions as of October 27, 2023:
+
+
+15 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+_**Table 5 - Technical Decisions**_
+
+### 2.1 Conformance Rationale
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+The ST conforms to the requirements in PP_MDF_V3.3/MOD_BT_V1.0/MOD_WLANC_V1.0/
+PKG_TLS_V1.1/MOD_VPNC_V2.4/ MOD_CPP_BIO_V1.1. For simplicity, this shall be referenced as
+MDF/BT/BIO//WLAN/TLS/VPNC. As explained previously, the security problem definition, security
+objectives, and security requirements are defined in the PP.
+
+
+16 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+## 3 Security Objectives
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+The Security Problem Definition may be found in the MDF/BT/BIO//WLAN/TLS/VPNC and this section
+reproduces only the corresponding Security Objectives for operational environment for reader
+convenience. The MDF/BT/BIO//WLAN/TLS/VPNC offers additional information about the identified
+security objectives, but that has not been reproduced here and the MDF/BT/BIO//WLAN/TLS/VPNC
+should be consulted if there is interest in that material.
+
+
+In general, the MDF/BT/BIO//WLAN/TLS/VPNC has defined Security Objectives appropriate for Mobile
+Devices and as such are applicable to the Samsung Galaxy Devices on Android 15 TOE.
+
+### 3.1 Security Objectives for the Operational Environment
+
+
+ - **OE.CONFIG** (PP_MDF_V3.3) TOE administrators will configure the Mobile Device security
+functions correctly to create the intended security policy.
+
+ - **OE.NOTIFY** (PP_MDF_V3.3) The Mobile User will immediately notify the administrator if the
+Mobile Device is lost or stolen.
+
+ - **OE.PRECAUTION** (PP_MDF_V3.3) The Mobile User exercises precautions to reduce the risk of
+loss or theft of the Mobile Device.
+
+ - **OE.DATA_PROPER_USER** (PP_MDF_V3.3) Administrators take measures to ensure that mobile
+device users are adequately vetted against malicious intent and are made aware of the
+expectations for appropriate use of the device.
+
+ - **OE.NO_TOE_BYPASS** (MOD_WLANC_V1.0) Information cannot flow between external and
+internal networks located in different enclaves without passing through the TOE.
+
+ - **OE.TRUSTED_ADMIN** (MOD_WLANC_V1.0) TOE Administrators are trusted to follow and apply
+all administrator guidance in a trusted manner.
+
+ - **OE.PROTECTION** (MOD_CPP_BIO_V1.1) The TOE environment shall provide the SEE to protect
+the TOE, the TOE configuration and biometric data during runtime and storage **.**
+
+ - **OE.NO_TOE_BYPASS** (MOD_VPNC_V2.4) Information cannot flow onto the network to which
+the VPN client's host is connected without passing through the TOE.
+
+ - **OE.PHYSICAL** (MOD_VPNC_V2.4) Physical security, commensurate with the value of the TOE
+and the data it contains, is assumed to be provided by the environment.
+
+ - **OE.TRUSTED_CONFIG** (MOD_VPNC_V2.4) Personnel configuring the TOE and its operational
+environment will follow the applicable security configuration guidance.
+
+
+17 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+## 4 Extended Components Definition
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+All of the extended requirements in this ST have been drawn from the MDF/BT/BIO//WLAN/TLS/VPNC/
+BIOO. The MDF/BT/BIO//WLAN/TLS/VPNC/ BIO defines the following extended SFRs and SARs and since
+they are not redefined in this ST the MDF/BT/BIO//WLAN/TLS/VPNC/ BIO should be consulted for more
+information concerning those CC extensions.
+
+
+
+
+
+
+|Requirement Class Requirement Component|Col2|
+|---|---|
+|**FCS: Cryptographic**
**support**|FCS_CKM_EXT.1: Cryptographic Key Support|
+|**FCS: Cryptographic**
**support**|FCS_CKM_EXT.2: Cryptographic Key Random Generation|
+|**FCS: Cryptographic**
**support**|FCS_CKM_EXT.3: Cryptographic Key Generation|
+|**FCS: Cryptographic**
**support**|FCS_CKM_EXT.4: Key Destruction|
+|**FCS: Cryptographic**
**support**|FCS_CKM_EXT.5: TSF Wipe|
+|**FCS: Cryptographic**
**support**|FCS_CKM_EXT.6: Salt Generation|
+|**FCS: Cryptographic**
**support**|FCS_CKM_EXT.8: Bluetooth Key Generation|
+|**FCS: Cryptographic**
**support**|FCS_HTTPS_EXT.1: HTTPS Protocol|
+|**FCS: Cryptographic**
**support**|FCS_IPSEC_EXT.1: IPsec|
+|**FCS: Cryptographic**
**support**|FCS_IV_EXT.1: Initialization Vector Generation|
+|**FCS: Cryptographic**
**support**|FCS_RBG_EXT.1: Random Bit Generation|
+|**FCS: Cryptographic**
**support**|FCS_SRV_EXT.1: Cryptographic Algorithm Services|
+|**FCS: Cryptographic**
**support**|FCS_SRV_EXT.2: Cryptographic Algorithm Services|
+|**FCS: Cryptographic**
**support**|FCS_STG_EXT.1: Cryptographic Key Storage|
+|**FCS: Cryptographic**
**support**|FCS_STG_EXT.2: Encrypted Cryptographic Key Storage|
+|**FCS: Cryptographic**
**support**|FCS_STG_EXT.3: Integrity of Encrypted Key Storage|
+|**FCS: Cryptographic**
**support**|PKG_TLS_V1.1: FCS_TLS_EXT.1: TLS Protocol|
+|**FCS: Cryptographic**
**support**|PKG_TLS_V1.1: FCS_TLSC_EXT.1: TLS Client Protocol|
+|**FCS: Cryptographic**
**support**|FCS_TLSC_EXT.2: TLS Client Support for Mutual Authentication|
+|**FCS: Cryptographic**
**support**|FCS_TLSC_EXT.2/WLAN: TLS Client Support for Supported Groups
Extension (EAP-TLS for WLAN)|
+|**FCS: Cryptographic**
**support**|PKG_TLS_V1.1:FCS_TLSC_EXT.4 TLS Client Support for Renegotiation|
+|**FCS: Cryptographic**
**support**|FCS_TLSC_EXT.5: TLS Client Support for Supported Groups Extension|
+|**FCS: Cryptographic**
**support**|FCS_WPA_EXT.1: Supported WPA Versions|
+|**FDP: User data protection**|FDP_ACF_EXT.1: Access Control for System Services|
+|**FDP: User data protection**|FDP_ACF_EXT.2: Access Control for System Resources|
+|**FDP: User data protection**|FDP_ACF_EXT.3: Security Attribute Based Access Control|
+|**FDP: User data protection**|FDP_DAR_EXT.1: Protected Data Encryption|
+|**FDP: User data protection**|FDP_DAR_EXT.2: Sensitive Data Encryption|
+|**FDP: User data protection**|FDP_IFC_EXT.1: Subset Information Flow Control|
+|**FDP: User data protection**|FDP_IFC_EXT.1: Subset Information Flow Control|
+|**FDP: User data protection**|FDP_PBA_EXT.1: Storage of Critical Biometric Parameters|
+|**FDP: User data protection**|FDP_STG_EXT.1: User Data Storage|
+|**FDP: User data protection**|FDP_UPC_EXT.1: Inter-TSF User Data Transfer Protection|
+|**FDP: User data protection**|FDP_VPN_EXT.1: Split Tunnel Prevention|
+|**FIA: Identification and**
**authentication**|FIA_AFL_EXT.1: Authentication Failure Handling|
+|**FIA: Identification and**
**authentication**|FIA_BLT_EXT.1: Bluetooth User Authorization|
+|**FIA: Identification and**
**authentication**|FIA_BLT_EXT.2: Bluetooth Mutual Authentication|
+|**FIA: Identification and**
**authentication**|FIA_BLT_EXT.3: Rejection of Duplicate Bluetooth Connections|
+
+
+
+18 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+
+
+
+
+
+
+
+|Requirement Class Requirement Component|Col2|
+|---|---|
+||FIA_BLT_EXT.4: Secure Simple Pairing|
+||FIA_BLT_EXT.6: Trusted Bluetooth Device User Authorization|
+||FIA_BLT_EXT.7: Untrusted Bluetooth Device User Authorization|
+||FIA_BMG_EXT.1: Accuracy of Biometric Authentication|
+||FIA_PAE_EXT.1: Port Access Entity Authentication|
+||FIA_PMG_EXT.1: Password Management|
+||FIA_TRT_EXT.1: Authentication Throttling|
+||FIA_UAU_EXT.1: Authentication for Cryptographic Operation|
+||FIA_UAU_EXT.2: Timing of Authentication|
+||FIA_UAU_EXT.4: Secondary User Authentication|
+||FIA_X509_EXT.1: Validation of Certificates|
+||FIA_X509_EXT.1/WLAN: X.509 Certificate Validation|
+||FIA_X509_EXT.2: X.509 Certificate Authentication|
+||FIA_X509_EXT.3: Request Validation of Certificates|
+||FIA_X509_EXT.6: Certificate Storage and Management|
+||FIA_MBE_EXT.1 :Biometric enrolment|
+||FIA_MBE_EXT.2 :Fingerprint Quality of biometric templates for
biometric enrolment|
+||FIA_MBV_EXT.1:BMFPS Biometric verification|
+||FIA_MBV_EXT.1 :UDFPS Biometric verification|
+||FIA_MBV_EXT.2 :Fingerprint Quality of biometric samples for
biometric verification|
+|**FMT: Security management**|FMT_MOF_EXT.1: Management of Security Functions Behavior|
+|**FMT: Security management**|FMT_SMF.1: Specification of Management Functions|
+|**FMT: Security management**|FMT_SMF_EXT.2: Specification of Remediation Actions|
+|**FMT: Security management**|FMT_SMF_EXT.3 Current Administrator|
+|**FPT: Protection of the TSF**|FPT_AEX_EXT.1: Application Address Space Layout Randomization|
+|**FPT: Protection of the TSF**|FPT_AEX_EXT.2: Memory Page Permissions|
+|**FPT: Protection of the TSF**|FPT_AEX_EXT.3: Stack Overflow Protection|
+|**FPT: Protection of the TSF**|FPT_AEX_EXT.4: Domain Isolation|
+|**FPT: Protection of the TSF**|FPT_AEX_EXT.5: Kernel Address Space Layout Randomization|
+|**FPT: Protection of the TSF**|FPT_AEX_EXT.6: Write or Execute Memory Page Permissions|
+|**FPT: Protection of the TSF**|FPT_BBD_EXT.1: Application Processor Mediation|
+|**FPT: Protection of the TSF**|FPT_JTA_EXT.1: JTAG Disablement|
+|**FPT: Protection of the TSF**|FPT_KST_EXT.1: Key Storage|
+|**FPT: Protection of the TSF**|FPT_KST_EXT.2: No Key Transmission|
+|**FPT: Protection of the TSF**|FPT_KST_EXT.3: No Plaintext Key Export|
+|**FPT: Protection of the TSF**|FPT_NOT_EXT.1: Self-Test Notification|
+|**FPT: Protection of the TSF**|FPT_TST_EXT.1: TSF Cryptographic Functionality Testing|
+|**FPT: Protection of the TSF**|FPT_TST_EXT.2/PREKERNEL: TSF Integrity Checking (Pre-kernel)|
+|**FPT: Protection of the TSF**|FPT_TST_EXT.2/POSTKERNEL: TSF Integrity Checking (Post-Kernel)|
+|**FPT: Protection of the TSF**|FPT_TUD_EXT.1: Trusted Update: TSF Version Query|
+|**FPT: Protection of the TSF**|FPT_TUD_EXT.2: TSF Update Verification|
+|**FPT: Protection of the TSF**|FPT_BDP_EXT.1 Biometric data processing|
+|**FPT: Protection of the TSF**|FPT_PBT_EXT.1 Protection of biometric template|
+|**FTA: TOE access**|FTA_SSL_EXT.1: TSF- and User-initiated Locked State|
+
+
+
+19 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+|Requirement Class Requirement Component|Col2|
+|---|---|
+||FTA_WSE_EXT.1: Wireless Network Access|
+||FTP_ITC_EXT.1: Trusted Channel Communication|
+|**ALC: Life Cycle Support**|ALC_TSU_EXT.1: Timely Security Updates|
+
+
+
+_**Table 6 - Extended SFRs and SARs**_
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+20 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+## 5 Security Requirements
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+This section defines the Security Functional Requirements (SFRs) and Security Assurance Requirements
+(SARs) that serve to represent the security functional claims for the Target of Evaluation (TOE) and to
+scope the evaluation effort.
+
+
+The SFRs have all been drawn from the MDF/BT/BIO//WLAN/TLS/VPNC/BIO. The refinements and
+operations already performed in the MDF/BT/BIO//WLAN/TLS/VPNC are not identified (e.g.,
+highlighted) here, rather the requirements have been copied from the
+PP_MDF_V3.3/MOD_BT_V1.0/MOD_WLANC_V1.0/ PKG_TLS_V1.1/MOD_VPNC_V2.4/
+MOD_CPP_BIO_V1.1 and any residual operations have been completed herein. Of particular note, the
+MDF/BT/BIO//WLAN/TLS/VPNC made a number of refinements and completed some of the SFR
+operations defined in the Common Criteria (CC) and that PP should be consulted to identify those
+changes if necessary.
+
+
+The SARs are also drawn from the MDF/BT/BIO//WLAN/TLS/VPNC/BIO. The SARs are effectively refined
+since requirement-specific 'Assurance Activities' are defined in the MDF/BT/BIO//WLAN/TLS/VPNC/BIO
+that serve to ensure corresponding evaluations will yield more practical and consistent assurance than
+the assurance requirements alone. The MDF/BT/BIO//WLAN/TLS/VPNC/BIO should be consulted for the
+assurance activity definitions.
+
+### 5.1 TOE Security Functional Requirements
+
+
+The following table identifies the SFRs that are satisfied by the Samsung Galaxy Devices on Android 15
+TOE.
+
+
+
+
+
+|Requirement Class Requirement Component|Col2|
+|---|---|
+|**FAU: Security Audit**|FAU_GEN.1: Audit Data Generation|
+|**FAU: Security Audit**|MOD_BT_V1.0: FAU_GEN.1/BT Audit Data Generation (Bluetooth)|
+|**FAU: Security Audit**|MOD_WLANC_V1.0: FAU_GEN.1/WLAN: Audit Data Generation (Wireless LAN)|
+|**FAU: Security Audit**|FAU_SAR.1: Audit Review|
+|**FAU: Security Audit**|FAU_STG.1: Audit Storage Protection|
+|**FAU: Security Audit**|FAU_STG.4: Prevention of Audit Data Loss|
+|**FCS: Cryptographic**
**support**|FCS_CKM.1: Cryptographic Key Generation|
+|**FCS: Cryptographic**
**support**|MOD_WLANC_V1.0: FCS_CKM.1/WLAN: Cryptographic Key Generation
(Symmetric Keys for WPA2/WPA3 Connections)|
+|**FCS: Cryptographic**
**support**|MOD_VPNC_V2.4: FCS_CKM.1/VPN: Cryptographic Key Generation (IKE)|
+|**FCS: Cryptographic**
**support**|FCS_CKM.2/UNLOCKED: Cryptographic Key Establishment|
+|**FCS: Cryptographic**
**support**|FCS_CKM.2/LOCKED: Cryptographic Key Establishment|
+|**FCS: Cryptographic**
**support**|MOD_WLANC_V1.0: FCS_CKM.2/WLAN: Cryptographic Key Distribution (Group
Temporal Key for WLAN)|
+|**FCS: Cryptographic**
**support**|FCS_CKM_EXT.1: Cryptographic Key Support|
+|**FCS: Cryptographic**
**support**|FCS_CKM_EXT.2: Cryptographic Key Random Generation|
+|**FCS: Cryptographic**
**support**|FCS_CKM_EXT.3: Cryptographic Key Generation|
+|**FCS: Cryptographic**
**support**|FCS_CKM_EXT.4: Key Destruction|
+|**FCS: Cryptographic**
**support**|FCS_CKM_EXT.5: TSF Wipe|
+|**FCS: Cryptographic**
**support**|FCS_CKM_EXT.6: Salt Generation|
+|**FCS: Cryptographic**
**support**|MOD_BT_V1.0: FCS_CKM_EXT.8: Bluetooth Key Generation|
+|**FCS: Cryptographic**
**support**|FCS_COP.1/ENCRYPT: Cryptographic operation|
+
+
+21 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+
+
+
+
+|Requirement Class Requirement Component|Col2|
+|---|---|
+||FCS_COP.1/HASH: Cryptographic operation|
+||FCS_COP.1/SIGN: Cryptographic operation|
+||FCS_COP.1/KEYHMAC: Cryptographic operation|
+||FCS_COP.1/CONDITION: Cryptographic operation|
+||FCS_HTTPS_EXT.1: HTTPS Protocol|
+||MOD_VPN_CLI_V2.3: FCS_IPSEC_EXT.1: IPsec|
+||FCS_IV_EXT.1: Initialization Vector Generation|
+||FCS_RBG_EXT.1: Random Bit Generation|
+||FCS_SRV_EXT.1: Cryptographic Algorithm Services|
+||FCS_SRV_EXT.2: Cryptographic Algorithm Services|
+||FCS_STG_EXT.1: Cryptographic Key Storage|
+||FCS_STG_EXT.2: Encrypted Cryptographic Key Storage|
+||FCS_STG_EXT.3: Integrity of Encrypted Key Storage|
+||PKG_TLS_V1.1: FCS_TLS_EXT.1: TLS Protocol|
+||PKG_TLS_V1.1: FCS_TLSC_EXT.1: TLS Client Protocol|
+||MOD_WLANC_V1.0: FCS_TLSC_EXT.1/WLAN: TLS Client Protocol (EAP-TLS for
WLAN)|
+||PKG_TLS_V1.1: FCS_TLSC_EXT.2: TLS Client Support for Mutual Authentication|
+||MOD_WLANC_V1.0: FCS_TLSC_EXT.2/WLAN: TLS Client Support for Supported
Groups Extension (EAP-TLS for WLAN)|
+||PKG_TLS_V1.1:FCS_TLSC_EXT.4 TLS Client Support for Renegotiation|
+||PKG_TLS_V1.1: FCS_TLSC_EXT.5: TLS Client Support for Supported Groups
Extension|
+||MOD_WLANC_V1.0: FCS_WPA_EXT.1: Supported WPA Versions|
+|**FDP: User data protection**|FDP_ACF_EXT.1: Access Control for System Services|
+|**FDP: User data protection**|FDP_ACF_EXT.2: Access Control for System Resources|
+|**FDP: User data protection**|FDP_ACF_EXT.3: Security Attribute Based Access Control|
+|**FDP: User data protection**|FDP_DAR_EXT.1: Protected Data Encryption|
+|**FDP: User data protection**|FDP_DAR_EXT.2: Sensitive Data Encryption|
+|**FDP: User data protection**|FDP_IFC_EXT.1: Subset Information Flow Control|
+|**FDP: User data protection**|MOD_VPNC_V2.4: FDP_IFC_EXT.1: Subset Information Flow Control|
+|**FDP: User data protection**|FDP_PBA_EXT.1: Storage of Critical Biometric Parameters|
+|**FDP: User data protection**|MOD_VPNC_V2.4: FDP_RIP.2: Full Residual Information Protection|
+|**FDP: User data protection**|FDP_STG_EXT.1: User Data Storage|
+|**FDP: User data protection**|FDP_UPC_EXT.1/APPS: Inter-TSF User Data Transfer Protection (Applications)|
+|**FDP: User data protection**|FDP_UPC_EXT.1/BT: Inter-TSF User Data Transfer Protection (Bluetooth)|
+|**FDP: User data protection**|FDP_VPN_EXT.1: Split Tunnel Prevention|
+|**FIA: Identification and**
**authentication**|FIA_AFL_EXT.1: Authentication Failure Handling|
+|**FIA: Identification and**
**authentication**|MOD_BT_V1.0: FIA_BLT_EXT.1: Bluetooth User Authorization|
+|**FIA: Identification and**
**authentication**|MOD_BT_V1.0: FIA_BLT_EXT.2: Bluetooth Mutual Authentication|
+|**FIA: Identification and**
**authentication**|MOD_BT_V1.0: FIA_BLT_EXT.3: Rejection of Duplicate Bluetooth Connections|
+|**FIA: Identification and**
**authentication**|MOD_BT_V1.0: FIA_BLT_EXT.4: Secure Simple Pairing|
+|**FIA: Identification and**
**authentication**|MOD_BT_V1.0: FIA_BLT_EXT.6: Trusted Bluetooth Device User Authorization|
+|**FIA: Identification and**
**authentication**|MOD_BT_V1.0: FIA_BLT_EXT.7: Untrusted Bluetooth Device User Authorization|
+|**FIA: Identification and**
**authentication**|FIA_BMG_EXT.1(1): Accuracy of Biometric Authentication|
+|**FIA: Identification and**
**authentication**|FIA_BMG_EXT.1(2): Accuracy of Biometric Authentication|
+
+
+22 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+
+
+
+
+|Requirement Class Requirement Component|Col2|
+|---|---|
+||MOD_WLANC_V1.0: FIA_PAE_EXT.1: Port Access Entity Authentication|
+||FIA_PMG_EXT.1: Password Management|
+||FIA_TRT_EXT.1: Authentication Throttling|
+||FIA_UAU.5: Multiple Authentication Mechanisms|
+||FIA_UAU.6/CREDENTIAL: Re-authenticating (Credential Change|
+||FIA_UAU.6/LOCKED: Re-authenticating (TSF Lock)|
+||FIA_UAU.7: Protected Authentication Feedback|
+||FIA_UAU_EXT.1: Authentication for Cryptographic Operation|
+||FIA_UAU_EXT.2: Timing of Authentication|
+||FIA_UAU_EXT.4: Secondary User Authentication|
+||FIA_X509_EXT.1: Validation of Certificates|
+||MOD_WLANC_V1.0: FIA_X509_EXT.1/WLAN: X.509 Certificate Validation|
+||FIA_X509_EXT.2: X.509 Certificate Authentication|
+||MOD_WLANC_V1.0: FIA_X509_EXT.2/WLAN: X.509 Certificate Authentication
(EAP-TLS for WLAN)|
+||FIA_X509_EXT.3: Request Validation of Certificates|
+||MOD_WLANC_V1.0: FIA_X509_EXT.6/WLAN: Certificate Storage and
Management|
+||MOD_CPP_BIO_V1.1 /FIA_MBE_EXT.1 :Biometric enrolment|
+||MOD_CPP_BIO_V1.1 /FIA_MBE_EXT.2: Fingerprint Quality of biometric templates
for biometric enrolment|
+||MOD_CPP_BIO_V1.1/FIA_MBV_EXT.1/BMFPS : Biometric verification|
+||MOD_CPP_BIO_V1.1 /FIA_MBV_EXT.1/UDFPS: Biometric verification|
+||MOD_CPP_BIO_V1.1/FIA_MBV_EXT.2/ :Fingerprint Quality of biometric samples
for biometric verification|
+|**FMT: Security**
**management**|FMT_MOF_EXT.1: Management of Security Functions Behavior|
+|**FMT: Security**
**management**|FMT_SMF.1: Specification of Management Functions|
+|**FMT: Security**
**management**|MOD_BT_CLI_V1.0: FMT_SMF_EXT.1/BT: Specification of Management Functions
(Bluetooth)|
+|**FMT: Security**
**management**|MOD_WLANC_V1.0: FMT_SMF_EXT.1/WLAN: Specification of Management
Functions (WLAN Client)|
+|**FMT: Security**
**management**|MOD_VPNC_V2.4: FMT_SMF.1/VPN: Specification of Management Functions -
VPN|
+|**FMT: Security**
**management**|FMT_SMF_EXT.2: Specification of Remediation Actions|
+|**FMT: Security**
**management**|FMT_SMF_EXT.3: Current Administrator|
+|**FPT: Protection of the TSF**|FPT_AEX_EXT.1: Application Address Space Layout Randomization|
+|**FPT: Protection of the TSF**|FPT_AEX_EXT.2: Memory Page Permissions|
+|**FPT: Protection of the TSF**|FPT_AEX_EXT.3: Stack Overflow Protection|
+|**FPT: Protection of the TSF**|FPT_AEX_EXT.4: Domain Isolation|
+|**FPT: Protection of the TSF**|FPT_AEX_EXT.5: Kernel Address Space Layout Randomization|
+|**FPT: Protection of the TSF**|FPT_AEX_EXT.6: Write or Execute Memory Page Permissions|
+|**FPT: Protection of the TSF**|FPT_BBD_EXT.1: Application Processor Mediation|
+|**FPT: Protection of the TSF**|MOD_CPP_BIO_V1.1/FPT_BDP_EXT.1 : Biometric data processing|
+|**FPT: Protection of the TSF**|FPT_JTA_EXT.1: JTAG Disablement|
+|**FPT: Protection of the TSF**|FPT_KST_EXT.1 & MOD_CPP_BIO_V1.1/FPT_KST_EXT.1. Key Storage|
+|**FPT: Protection of the TSF**|FPT_KST_EXT.2 & MOD_CPP_BIO_V1.1/ FPT_KST_EXT.2: No Key Transmission|
+|**FPT: Protection of the TSF**|FPT_KST_EXT.3: No Plaintext Key Export|
+
+
+23 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+
+
+
+
+|Requirement Class Requirement Component|Col2|
+|---|---|
+||FPT_NOT_EXT.1: Self-Test Notification|
+||MOD_CPP_BIO_V1.1/FPT_PBT_EXT.1: Protection of biometric template|
+||FPT_STM.1: Reliable time stamps|
+||FPT_TST_EXT.1: TSF Cryptographic Functionality Testing|
+||MOD_WLANC_V1.0: FPT_TST_EXT.1/WLAN: TSF Cryptographic Functionality
Testing (WLAN Client)|
+||MOD_VPNC_V2.4: FPT_TST_EXT.1/VPN: TSF Self-Test (VPN Client)|
+||FPT_TST_EXT.2/PREKERNEL: TSF Integrity Checking (Pre-Kernel)|
+||FPT_TST_EXT.2/POSTKERNEL: TSF Integrity Checking (Post-Kernel)|
+||FPT_TUD_EXT.1: Trusted Update: TSF Version Query|
+||FPT_TUD_EXT.2: TSF Update Verification|
+||FPT_TUD_EXT.3: Application Signing|
+||FPT_TUD_EXT.6: Trusted Update Verification|
+|**FTA: TOE access**|FTA_SSL_EXT.1: TSF- and User-initiated Locked State|
+|**FTA: TOE access**|FTA_TAB.1: Default TOE Access Banners|
+|**FTA: TOE access**|MOD_WLANC_V1.0: FTA_WSE_EXT.1: Wireless Network Access|
+|**FTA: TOE access**|MOD_BT_V1.0: FTP_BLT_EXT.1: Bluetooth Encryption|
+|**FTA: TOE access**|MOD_BT_V1.0: FTP_BLT_EXT.2: Persistence of Bluetooth Encryption|
+|**FTA: TOE access**|MOD_BT_V1.0: FTP_BLT_EXT.3/BR: Bluetooth Encryption Parameters (BR/EDR)|
+|**FTA: TOE access**|MOD_BT_V1.0: FTP_BLT_EXT.3/LE: Bluetooth Encryption Parameters (LE)|
+|**FTA: TOE access**|FTP_ITC_EXT.1: Trusted Channel Communication|
+
+
+_**Table 7 - TOE Security Functional Requirements**_
+
+
+
+5.1.1 Security Audit (FAU)
+
+
+_5.1.1.1_ _FAU_GEN.1: Audit Data Generation, MOD_BT_V1.0: FAU_GEN.1/BT Audit Data_
+
+_Generation (Bluetooth) & MOD_WLANC_V1.0: FAU_GEN.1/WLAN: Audit Data Generation_
+_(Wireless LAN)_
+
+
+**FAU_GEN.1.1**
+
+The TSF shall be able to generate an audit record of the following auditable events:
+1. Start-up and shutdown of the audit functions
+2. All auditable events for the [not selected] level of audit
+3. All administrative actions
+4. Start-up and shutdown of the OS
+5. Insertion or removal of removable media
+6. Specifically defined auditable events in Table 12 (from Table 2 of the
+
+PP_MDF_V3.3);
+7. [ _**Audit records reaching [95] percentage of audit capacity**_ ]
+8. **[** _**Specifically defined auditable events as listed in Table 12 - Audit Events from**_
+
+_**Table 3 of the PP_MDF_V3.3**_ ]
+9. **[** _**Auditable events as listed in Table 13 โ Bluetooth Audit Events from Table 2 of the**_
+
+_**MOD_BT_V1.0**_ ]
+10. [ _**Auditable events as listed in Table 14 โ WLAN Client Audit Events from Table 2 of**_
+
+_**the MOD_WLANC_V1.0**_ **]**
+
+
+24 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+**FAU_GEN.1.2**
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+The TSF shall record within each audit record at least the following information:
+1. Date and time of the event
+2. Type of event
+3. Subject identity
+4. The outcome (success or failure) of the event
+5. Additional information in Table 2 (of the PP_MDF_V3.3)
+6. [ _**Additional information in Table 3 (of the PP_MDF_V3.3)**_ ]
+7. [ _For each audit event type, based on the auditable event definitions of the functional_
+
+_components included in the PP/ST, Additional information in the Auditable Events_
+_table of the MOD_BT_V1.0_ ] (TD0707 applied)
+
+
+_5.1.1.2_ _FAU_SAR.1: Audit Review_
+
+
+**FAU_SAR.1.1**
+
+The TSF shall provide the administrator with the capability to read all audited events
+and record contents from the audit records.
+**FAU_SAR.1.2**
+
+The TSF shall provide the audit records in a manner suitable for the user to interpret the
+information.
+
+
+_5.1.1.3_ _FAU_STG.1: Audit Storage Protection_
+
+
+**FAU_STG.1.1**
+
+The TSF shall protect the stored audit records in the audit trail from unauthorized
+deletion.
+**FAU_STG.1.2**
+
+The TSF shall be able to prevent unauthorized modifications to the stored audit records
+in the audit trail.
+
+
+_5.1.1.4_ _FAU_STG.4: Prevention of Audit Data Loss_
+
+
+**FAU_STG.4.1**
+
+The TSF shall overwrite the oldest stored audit records if the audit trail is full.
+
+
+5.1.2 Cryptographic Support (FCS)
+
+
+_5.1.2.1_ _FCS_CKM.1: Cryptographic Key Generation_
+
+
+**FCS_CKM.1.1**
+
+The TSF shall generate asymmetric cryptographic keys in accordance with a specified
+cryptographic key generation algorithm [
+
+ - _**RSA schemes using cryptographic key sizes of [2048-bit or greater] that meet FIPS**_
+_**PUB 186-5, โDigital Signature Standard (DSS)โ, Appendix B.3**_
+
+ - **ECC schemes using** [
+
+`o` _**โNIST curvesโ P-384, and [P-256, P-521] that meet the following: FIPS PUB 186-**_
+
+_**5, โDigital Signature Standard (DSS)โ, Appendix B.4,**_
+
+ - **FFC schemes using** [
+
+
+25 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+]. (TD0871)
+
+
+_5.1.2.2_ _MOD_WLANC_V1.0: FCS_CKM.1/WLAN: Cryptographic Key Generation (Symmetric Keys_
+
+_for WPA2/WPA3 Connections_
+
+
+**FCS_CKM.1.1/WLAN**
+
+The TSF shall generate symmetric cryptographic keys in accordance with a specified
+cryptographic key generation algorithm PRF-384 and [ _**PRF-704**_ ] (as defined in IEEE
+802.11-2012) and specified cryptographic key sizes 256 bits and [ _**no other key sizes**_ ]
+using a Random Bit Generator as specified in FCS_RBG_EXT.1
+
+
+_5.1.2.3_ _MOD_VPNC_V2.4: FCS_CKM.1/VPN: Cryptographic Key Generation (IKE)_
+
+
+**FCS_CKM.1.1/VPN**
+The TSF shall [ _**implement functionality**_ ] to generate asymmetric cryptographic keys
+used for IKE peer authentication in accordance with:
+
+ - _**FIPS PUB 186-5, โDigital Signature Standard (DSS)โ, Appendix B.3 for RSA schemes;**_
+
+ - _**FIPS PUB 186-5, โDigital Signature Standard (DSS)โ, Appendix B.4 for ECDSA**_
+_**schemes and implementing โNIST curvesโ, P-256, P-384 and [P-521]**_ ]
+and specified cryptographic key sizes equivalent to, or greater than, a symmetric key
+strength of 112 bits.
+
+
+_5.1.2.4_ _FCS_CKM.2/UNLOCKED: Cryptographic Key Establishment_
+
+
+**FCS_CKM.2.1/UNLOCKED**
+
+The TSF shall perform cryptographic key establishment in accordance with a specified
+cryptographic key establishment method:[
+
+ - _**Elliptic curve-based key establishment schemes that meets the following: NIST**_
+_**Special Publication 800-56A Revision 3, โRecommendation for Pair-Wise Key**_
+_**Establishment Schemes Using Discrete Logarithm Cryptographyโ,**_
+
+ - _**RSA-based key establishment schemes that meet the following [ NIST Special**_
+_**Publication 800-56B, โRecommendation for Pair-Wise Key Establishment Schemes**_
+_**Using Integer Factorization Cryptographyโ**_
+
+ - _**Finite field-based key establishment schemes that meets the following: NIST**_
+_**Special Publication 800-56A Revision 3, "Recommendation for Pair-Wise Key**_
+_**Establishment Schemes Using Discrete Logarithm Cryptography"**_
+].
+
+
+_5.1.2.5_ _FCS_CKM.2/LOCKED: Cryptographic Key Establishment_
+
+
+**FCS_CKM.2.1/LOCKED**
+
+The TSF shall perform cryptographic key establishment in accordance with a specified
+cryptographic key establishment method: [
+
+
+26 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+
+ - _**RSA-based key establishment schemes that meets the following: NIST Special**_
+_**Publication 800-56B, "Recommendation for Pair-Wise Key Establishment Schemes**_
+_**Using Integer Factorization Cryptography",**_
+
+ - _**Elliptic curve-based key establishment schemes that meets the following: [NIST**_
+_**Special Publication 800-56A Revision 3, โRecommendation for Pair-Wise Key**_
+_**Establishment Schemes Using Discrete Logarithm Cryptographyโ]]**_
+for the purposes of encrypting sensitive data received while the device is locked.
+
+
+_5.1.2.6_ _MOD_WLANC_V1.0: FCS_CKM.2/WLAN: Cryptographic Key Distribution (Group Temporal_
+
+_Key for WLAN)_
+
+
+**FCS_CKM.2.1/WLAN**
+
+Refinement: The TSF shall **decrypt** **Group Temporal Key** in accordance with a specified
+cryptographic key distribution method [ _AES Key Wrap in an EAPOL-Key frame_ ] that
+meets the following: [ _RFC 3394 for AES Key Wrap, 802.11-2012 for the packet format_
+_and timing considerations_ ] **and does not expose the cryptographic keys** .
+
+
+_5.1.2.7_ _FCS_CKM_EXT.1: Cryptographic Key Support_
+
+
+**FCS_CKM_EXT.1.1**
+
+The TSF shall support a [ _**immutable hardware**_ ] REK(s) with a [ _**symmetric**_ ] key of strength
+
+[ _**256 bits**_ ].
+**FCS_CKM_EXT.1.2**
+
+Each REK shall be hardware-isolated from the OS on the TSF in runtime.
+**FCS_CKM_EXT.1.3**
+
+Each REK shall be generated by a RBG in accordance with FCS_RBG_EXT.1.
+
+
+_5.1.2.8_ _FCS_CKM_EXT.2: Cryptographic Key Random Generation_
+
+
+**FCS_CKM_EXT.2.1**
+
+All DEKs shall be [
+
+ - _**randomly generated (for SD card encryption)**_
+
+ - _**from the combination of a randomly generated DEK with another DEK or salt in a**_
+
+] with entropy corresponding to the security strength of AES key sizes of [ _**256**_ ] bits.
+
+
+_5.1.2.9_ _FCS_CKM_EXT.3: Cryptographic Key Generation_
+
+
+**FCS_CKM_EXT.3.1**
+
+The TSF shall use [
+
+ - _**asymmetric KEKs of [128-bit] security strength,**_
+
+ - _**symmetric KEKs of [256-bit] security strength corresponding to at least the security**_
+_**strength of the keys encrypted by the KEK**_
+].
+**FCS_CKM_EXT.3.2**
+
+The TSF shall generate all KEKs using one of the following methods:
+
+
+27 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+
+ - Derive the KEK from a Password Authentication Factor using according to
+FCS_COP.1.1/CONDITION
+and [
+
+ - _**Generate the KEK using an RBG that meets this profile (as specified in**_
+_**FCS_RBG_EXT.1),**_
+
+ - _**Generate the KEK using a key generation scheme that meets this profile (as**_
+_**specified in FCS_CKM.1),**_
+
+ - _**Combine the KEK from other KEKs in a way that preserves the effective entropy of**_
+_**each factor by [concatenating the keys and using a KDF (as described in SP 800-**_
+_**108) (for FBE), encrypting one key with another]**_ ].
+
+
+_5.1.2.10_ _FCS_CKM_EXT.4: Key Destruction_
+
+
+**FCS_CKM_EXT.4.1**
+
+The TSF shall destroy cryptographic keys in accordance with the specified cryptographic
+key destruction methods:
+
+ - by clearing the KEK encrypting the target key
+
+ - in accordance with the following rules
+
+`o` For volatile memory, the destruction shall be executed by a single direct
+
+overwrite [ _**consisting of zeroes**_ ].
+
+`o` For non-volatile EEPROM, the destruction shall be executed by a single direct
+
+overwrite consisting of a pseudo random pattern using the TSF's RBG (as
+specified in FCS_RBG_EXT.1), followed by a read-verify.
+
+`o` For non-volatile flash memory, that is not wear-leveled, the destruction shall be
+
+executed [ _**by a single direct overwrite consisting of zeros followed by a read-**_
+_**verify**_ ].
+
+`o` For non-volatile flash memory, that is wear-leveled, the destruction shall be
+
+executed [ _**by a block erase**_ ].
+
+`o` For non-volatile memory other than EEPROM and flash, the destruction shall be
+
+executed by a single direct overwrite with a random pattern that is changed
+before each write.
+**FCS_CKM_EXT.4.2**
+
+The TSF shall destroy all plaintext keying material and critical security parameters when
+no longer needed.
+
+
+_5.1.2.11_ _FCS_CKM_EXT.5: TSF Wipe_
+
+
+**FCS_CKM_EXT.5.1**
+
+The TSF shall wipe all protected data by [
+
+ - _**Cryptographically erasing the encrypted DEKs and/or the KEKs in non-volatile**_
+_**memory by following the requirements in FCS_CKM_EXT.4.1**_
+
+ - _**Overwriting all Protected Data according to the following rules:**_
+
+`o` _**For EEPROM, the destruction shall be executed by a single direct overwrite**_
+
+_**consisting of a pseudo random pattern using the TSFโs RBG (as specified in**_
+_**FCS_RBG_EXT.1, followed by a read-verify.**_
+
+
+28 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+
+`o` _**For flash memory, that is not wear-leveled, the destruction shall be executed**_
+
+_**[by a block erase that erases the reference to memory that stores data as well**_
+_**as the data itself].**_
+
+`o` _**For flash memory, that is wear-leveled, the destruction shall be executed [by a**_
+
+_**block erase].**_
+
+`o` _**For non-volatile memory other than EEPROM and flash, the destruction shall**_
+
+_**be executed by a single direct overwrite with a random pattern that is**_
+_**changed before each write.**_
+].
+**FCS_CKM_EXT.5.2**
+
+The TSF shall perform a power cycle on conclusion of the wipe procedure.
+
+
+_5.1.2.12_ _FCS_CKM_EXT.6: Salt Generation_
+
+
+**FCS_CKM_EXT.6.1**
+
+The TSF shall generate all salts using a RBG that meets FCS_RBG_EXT.1.
+
+
+_5.1.2.13_ _MOD_BT_V1.0: FCS_CKM_EXT.8: Bluetooth Key Generation_
+
+
+**FCS_CKM_EXT.8.1**
+
+The TSF shall generate public/private ECDH key pairs every [ **time a connection between**
+**devices is established** ].
+
+
+_5.1.2.14_ _FCS_COP.1/ENCRYPT: Cryptographic operation_
+
+
+**FCS_COP.1.1/ENCRYPT**
+
+The TSF shall perform encryption/decryption in accordance with a specified
+cryptographic algorithm:
+
+ - AES-CBC (as defined in FIPS PUB 197, and NIST SP 800-38A) mode
+
+ - AES-CCMP (as defined in FIPS PUB 197, NIST SP 800-38C and IEEE 802.11-2012),
+and [
+
+ - _**AES-GCM (as defined in NIST SP 800-38D),**_
+
+ - _**AES Key Wrap (KW) (as defined in NIST SP 800-38F),**_
+
+ - _**AES-XTS (as defined in NIST SP 800-38E)**_ ]
+and cryptographic key sizes 128-bit key sizes and [ _**256-bit key sizes**_ ].
+
+
+_5.1.2.15_ _FCS_COP.1/HASH: Cryptographic operation_
+
+
+**FCS_COP.1.1/HASH**
+
+The TSF shall perform cryptographic hashing in accordance with a specified
+cryptographic algorithm SHA-1 and [ _**SHA-256, SHA-384, SHA-512**_ ] and message digest
+sizes 160 and [ _**256, 384, 512**_ ] that meet the following: FIPS Pub 180-4.
+
+
+_5.1.2.16_ _FCS_COP.1/SIGN: Cryptographic operation_
+
+
+**FCS_COP.1.1/SIGN**
+
+The TSF shall perform cryptographic signature services (generation and verification) in
+accordance with a specified cryptographic algorithm [
+
+
+29 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+
+ - _**RSA schemes using cryptographic key sizes of 2048-bit or greater that meet the**_
+_**following: FIPS PUB 186-5, โDigital Signature Standard (DSS)โ, Section 4,**_
+
+ - _**ECDSA schemes using โNIST curvesโ P-384 and [P-256, P-521] that meet the**_
+_**following: FIPS PUB 186-5, โDigital Signature Standard (DSS)โ, Section 5**_ ].
+
+
+_5.1.2.17_ _FCS_COP.1/KEYHMAC: Cryptographic operation_
+
+
+**FCS_COP.1.1/KEYHMAC**
+
+The TSF shall perform keyed-hash message authentication in accordance with a
+specified cryptographic algorithm HMAC-SHA-1 and [ _**HMAC-SHA-256, HMAC-SHA-384,**_
+_**HMAC-SHA-512**_ ] and cryptographic key sizes [ **160, 256, 384, 512-bits** ] and message
+digest sizes 160 and [ _**256, 384, 512**_ ] bits that meet the following: FIPS Pub 198-1, โThe
+Keyed-Hash Message Authentication Codeโ, and FIPS Pub 180-4, โSecure Hash
+Standardโ.
+
+
+_5.1.2.18_ _FCS_COP.1/CONDITION: Cryptographic operation_
+
+
+**FCS_COP.1.1/CONDITION**
+
+The TSF shall perform conditioning in accordance with a specified cryptographic
+algorithm HMAC-[ _**SHA-256**_ ] using a salt, and [ _**PDKDF2 with [8192] iterations, [key**_
+_**stretching with scrypt)]**_ ], and output cryptographic key sizes [ _**256**_ ] that meet the
+following: [ _**NIST SP 800-132 (PBKDF2), no standard (scrypt)**_ ].
+
+
+_5.1.2.19_ _FCS_HTTPS_EXT.1: HTTPS Protocol_
+
+
+**FCS_HTTPS_EXT.1.1**
+
+The TSF shall implement the HTTPS protocol that complies with RFC 2818.
+**FCS_HTTPS_EXT.1.2**
+
+The TSF shall implement HTTPS using TLS as defined in the Package for Transport Layer
+Security, version 1.1.
+**FCS_HTTPS_EXT.1.3**
+
+The TSF shall notify the application and [ _**no other action**_ ] if the peer certificate is
+deemed invalid.
+
+
+_5.1.2.20_ _MOD_VPNC_V2.4: FCS_IPSEC_EXT.1: IPsec_
+
+
+**FCS_IPSEC_EXT.1.1**
+
+The TSF shall implement the IPsec architecture as specified in RFC 4301.
+**FCS_IPSEC_EXT.1.2**
+
+The TSF shall implement [ _**tunnel mode**_ ].
+**FCS_IPSEC_EXT.1.3**
+
+The TSF shall have a nominal, final entry in the SPD that matches anything that is
+otherwise unmatched, and discards it.
+**FCS_IPSEC_EXT.1.4**
+
+The TSF shall implement the IPsec protocol ESP as defined by RFC 4303 using the
+cryptographic algorithms AES-GCM-128, AES-GCM-256 as specified in RFC 4106, [ _**AES-**_
+_**CBC-128, AES-CBC-256 (both specified by RFC 3602) together with a Secure Hash**_
+_**Algorithm (SHA)-based HMAC**_ ].
+**FCS_IPSEC_EXT.1.5**
+
+
+30 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+The TSF shall implement the protocol: [
+
+ - _**IKEv2 as defined in RFCs 7296 (with mandatory support for NAT traversal as**_
+_**specified in section 2.23), RFC 8247 and [RFC 4868 for hash functions]**_ ]. (TD0897
+applied)
+**FCS_IPSEC_EXT.1.6**
+
+The TSF shall ensure the encrypted payload in the [ _**IKEv2**_ ] protocol uses the
+cryptographic algorithms AES-CBC-128, AES-CBC-256 as specified in RFC 6379 and [ _**AES-**_
+_**GCM-128, AES-GCM-256 as specified in RFC 5282**_ ].
+**FCS_IPSEC_EXT.1.7**
+
+The TSF shall ensure that [
+
+ - _**IKEv2 SA lifetimes can be configured by [VPN Gateway] based on [length of time];**_
+If length of time is used, it must include at least one option that is 24 hours or less for
+Phase 1 SAs and 8 hours or less for Phase 2 SAs.
+**FCS_IPSEC_EXT.1.8**
+
+The TSF shall ensure that all IKE protocols implement DH groups 19 (256-bit Random
+ECP), 20 (384-bit Random ECP), and [ _**24 (2048-bit MODP with 256-bit POS), 14 (2048-bit**_
+_**MODP)**_ ].
+**FCS_IPSEC_EXT.1.9**
+
+The TSF shall generate the secret value x used in the IKE Diffie-Hellman key exchange
+(โxโ in g [x] mod p) using the random bit generator specified in FCS_RBG_EXT.1, and
+having a length of at least [ **(224, 256, or 384)** ] bits.
+**FCS_IPSEC_EXT.1.10**
+
+The TSF shall generate nonces used in IKE exchanges in a manner such that the
+probability that a specific nonce value will be repeated during the life a specific IPsec SA
+is less than 1 in 2^[ **(112, 128, or 192)** ].
+**FCS_IPSEC_EXT.1.11**
+
+The TSF shall ensure that all IKE protocols perform peer authentication using a [ _**RSA,**_
+_**ECDSA**_ ] that use X.509v3 certificates that conform to RFC 4945 and [ _**no other method**_ ].
+**FCS_IPSEC_EXT.1.12**
+
+The TSF shall not establish an SA if the [ _**IP address, Fully Qualified Domain Name**_
+_**(FQDN)**_ ] and [ _**no other reference identifier type**_ ] contained in a certificate does not
+match the expected value(s) for the entity attempting to establish a connection.
+**FCS_IPSEC_EXT.1.13**
+
+The TSF shall not establish an SA if the presented identifier does not match the
+configured reference identifier of the peer.
+**FCS_IPSEC_EXT.1.14**
+
+The [ _**VPN Gateway**_ ] shall be able to ensure by default that the strength of the
+symmetric algorithm (in terms of the number of bits in the key) negotiated to protect
+the [ _**IKEv2 IKE_SA**_ ] connection is greater than or equal to the strength of the symmetric
+algorithm (in terms of the number of bits in the key) negotiated to protect the _**IKEv2**_
+_**CHILD_SA**_ ] connection.
+
+
+_5.1.2.21_ _FCS_IV_EXT.1: Initialization Vector Generation_
+
+
+**FCS_IV_EXT.1.1**
+
+
+31 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+The TSF shall generate IVs in accordance with PP_MDF_V3.3 Table 11: References and IV
+Requirements for NIST-approved Cipher Modes.
+
+
+_5.1.2.22_ _FCS_RBG_EXT.1: Random Bit Generation_
+
+
+**FCS_RBG_EXT.1.1**
+
+The TSF shall perform all deterministic random bit generation services in accordance
+with NIST Special Publication 800-90A using _**[Hash_DRBG (any), HMAC_DRBG (any),**_
+_**CTR_DRBG (AES)]**_ .
+**FCS_RBG_EXT.1.2**
+
+The deterministic RBG shall be seeded by an entropy source that accumulates entropy
+from [ _**TSF-hardware-based noise source**_ ] with a minimum of [ _**256 bits**_ ] of entropy at
+least equal to the greatest security strength (according to NIST SP 800-57) of the keys
+and hashes that it will generate.
+**FCS_RBG_EXT.1.3**
+
+The TSF shall be capable of providing output of the RBG to applications running on the
+TSF that request random bits.
+
+
+_5.1.2.23_ _FCS_SRV_EXT.1: Cryptographic Algorithm Services_
+
+
+**FCS_SRV_EXT.1.1**
+
+The TSF shall provide a mechanism for applications to request the TSF to perform the
+following cryptographic operations:
+
+ - All mandatory and [ _**selected algorithms**_ ] in FCS_CKM.2/LOCKED
+
+ - The following algorithms in FCS_COP.1/ENCRYPT: AES-CBC, [ _**AES-GCM**_ ]
+
+ - All mandatory and selected algorithms in FCS_COP.1/SIGN
+
+ - All mandatory and selected algorithms in FCS_COP.1/HASH
+
+ - All mandatory and selected algorithms in FCS_COP.1/KEYHMAC
+
+ - [ _**No other cryptographic operations**_ ].
+
+
+_5.1.2.24_ _FCS_SRV_EXT.2: Cryptographic Algorithm Services_
+
+
+**FCS_SRV_EXT.2.1**
+
+The TSF shall provide a mechanism for applications to request the TSF to perform the
+following cryptographic operations:
+
+ - Algorithms in FCS_COP.1/ENCRYPT
+
+ - Algorithms in FCS_COP.1/SIGN
+by keys stored in the secure key storage.
+
+
+_5.1.2.25_ _FCS_STG_EXT.1: Cryptographic Key Storage_
+
+
+**FCS_STG_EXT.1.1**
+
+The TSF shall provide [ _**mutable hardware (only available on select devices),**_ _**software-**_
+_**based**_ ] secure key storage for asymmetric private keys and [ _**symmetric keys**_ ].
+**FCS_STG_EXT.1.2**
+
+The TSF shall be capable of importing keys/secrets into the secure key storage upon
+request of [ _**the user, the administrator**_ ] and [ _**applications running on the TSF**_ ].
+**FCS_STG_EXT.1.3**
+
+
+32 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+The TSF shall be capable of destroying keys/secrets in the secure key storage upon
+request of [ _**the user, the administrator**_ ].
+**FCS_STG_EXT.1.4**
+
+The TSF shall have the capability to allow only the application that imported the
+key/secret the use of the key/secret. Exceptions may only be explicitly authorized by [ _**a**_
+_**common application developer**_ ].
+**FCS_STG_EXT.1.5**
+
+The TSF shall allow only the application that imported the key/secret to request that the
+key/secret be destroyed. Exceptions may only be explicitly authorized by [ _**a common**_
+_**application developer**_ ].
+
+
+_5.1.2.26_ _FCS_STG_EXT.2: Encrypted Cryptographic Key Storage_
+
+
+**FCS_STG_EXT.2.1**
+
+The TSF shall encrypt all DEKs, KEKs [ _**Wi-Fi, Bluetooth, VPN, and SecurityLogAgent**_
+_**properties (related to SE Android)**_ ] and [ _**all software-based key storage**_ ] by KEKs that
+are [
+
+ - _**Protected by the REK with [**_
+
+`o` _**encryption by a REK,**_
+
+`o` _**encryption by a KEK that is derived from a REK],**_
+
+ - _**Protected by the REK and the password with [**_
+
+`o` _**encryption by a REK and the password-derived KEK or biometric-unlocked KEK,**_
+
+`o` _**encryption by a KEK that is derived from a REK and the password-derived or**_
+
+_**biometric-unlocked KEK]**_ ].
+**FCS_STG_EXT.2.2**
+
+DEKs, KEKs, [ _**Bluetooth and WPA3/WPA2 PSK long-term trusted channel key material**_
+_**and SecurityLogAgent properties (related to SE Android)**_ ] and [ _**all software-based key**_
+_**storage**_ ] shall be encrypted using one of the following methods: [
+
+`o` _**using a SP800-56B key establishment scheme,**_
+
+`o` _**using AES in the [GCM, CBC mode]**_
+].
+
+
+_5.1.2.27_ _FCS_STG_EXT.3: Integrity of Encrypted Key Storage_
+
+
+**FCS_STG_EXT.3.1**
+
+The TSF shall protect the integrity of any encrypted DEKs and KEKs and [ _**long-term**_
+_**trusted channel key material, all software-based key storage**_ ] by [
+
+ - _**[GCM] cipher mode for encryption according to FCS_STG_EXT.2**_
+
+ - _**a hash (FCS_COP.1/HASH) of the stored key that is encrypted by a key protected by**_
+_**FCS_STG_EXT.2**_
+
+ - _**a keyed hash (FCS_COP.1/KEYHMAC) using a key protected by a key protected by**_
+_**FCS_STG_EXT.2**_ ].
+**FCS_STG_EXT.3.2**
+
+The TSF shall verify the integrity of the [ _**MAC**_ ] of the stored key prior to use of the key.
+
+
+33 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+_5.1.2.28_ _PKG_TLS_V1.1: FCS_TLS_EXT.1: TLS Protocol_
+
+
+**FCS_TLS_EXT.1.1**
+
+The product shall implement [
+
+ - _**TLS as a client**_
+].
+
+
+_5.1.2.29_ _PKG_TLS_V1.1: FCS_TLSC_EXT.1: TLS Client Protocol_
+
+
+**FCS_TLSC_EXT.1.1**
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+The product shall implement TLS 1.2 (RFC 5246) and [ _**no earlier TLS versions**_ ] as a client
+that supports the cipher suites [
+
+ - _**TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288,**_
+
+ - _**TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289,**_
+
+ - _**TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289,**_
+
+ - _**TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289,**_
+
+ - _**TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289**_ ]
+and also supports functionality for [
+
+ - _**mutual authentication**_
+
+ - _**session renegotiation**_
+].
+**FCS_TLSC_EXT.1.2**
+
+The product shall verify that the presented identifier matches the reference identifier
+according to RFC 6125.
+**FCS_TLSC_EXT.1.3**
+
+The product shall not establish a trusted channel if the server certificate is invalid [
+
+ - _**with no exceptions**_
+].
+(TD0442 applied)
+
+
+_5.1.2.30_ _MOD_WLANC_V1.0: FCS_TLSC_EXT.1/WLAN: TLS Client Protocol (EAP-TLS for WLAN)_
+
+
+**FCS_TLSC_EXT.1.1/WLAN**
+
+The TSF shall implement TLS 1.2 (RFC 5246)] and [ _**TLS 1.1 (RFC 4346)**_ ] in support of the
+EAP-TLS protocol as specified in RFC 5216 supporting the following ciphersuites: [
+
+ - _**TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 5246,**_
+
+ - _**TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288,**_
+
+ - _**TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289,**_
+
+ - _**TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289,**_
+
+ - _**TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289,**_
+
+ - _**TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289**_
+].
+**FCS_TLSC_EXT.1.2/WLAN**
+
+The TSF shall generate random values used in the EAP-TLS exchange using the RBG
+specified in FCS_RBG_EXT.1.
+
+
+34 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+**FCS_TLSC_EXT.1.3/WLAN**
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+The TSF shall use X509 v3 certificates as specified in FIA_X509_EXT.1/WLAN.
+**FCS_TLSC_EXT.1.4/WLAN**
+
+The TSF shall verify that the server certificate presented includes the Server
+Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage
+field.
+**FCS_TLSC_EXT.1.5/WLAN**
+
+The TSF shall allow an authorized administrator to configure the list of CAs that are
+allowed to sign authentication server certificates that are accepted by the TOE.
+
+
+_5.1.2.31_ _PKG_TLS_V1.1: FCS_TLSC_EXT.2: TLS Client Support for Mutual Authentication_
+
+
+**FCS_TLSC_EXT.2.1**
+
+The product shall support mutual authentication using X.509v3 certificates.
+
+
+_5.1.2.32_ _MOD_WLANC_V1.0: FCS_TLSC_EXT.2/WLAN: TLS Client Support for Supported Groups_
+
+_Extension (EAP-TLS for WLAN)_
+
+
+**FCS_TLSC_EXT.2.1/WLAN**
+
+The TSF shall present the Supported Elliptic Curves Extension in the Client Hello with the
+following NIST curves: [ _**secp256r1, secp384r1**_ ].
+
+
+_5.1.2.33_ _PKG_TLS_V1.1:FCS_TLSC_EXT.4 TLS Client Support for Renegotiation_
+
+
+**FCS_TLSC_EXT.4.1**
+
+The product shall support secure renegotiation through use of the โrenegotiation_infoโ
+TLS extension in accordance with RFC 5746
+
+
+_5.1.2.34_ _PKG_TLS_V1.1: FCS_TLSC_EXT.5: TLS Client Support for Supported Groups Extension_
+
+
+**FCS_TLSC_EXT.5.1**
+
+The product shall present the Supported Groups Extension in the Client Hello with the
+supported groups: [
+
+ - _**secp256r1,**_
+
+ - _**secp384r1**_
+].
+
+
+_5.1.2.35_ _MOD_WLANC_V1.0: FCS_WPA_EXT.1/WLAN: Supported WPA Versions_
+
+
+**FCS_WPA_EXT.1.1/WLAN**
+
+The TSF shall support WPA3 and [ _**WPA2**_ ] security type.
+
+
+5.1.3 User Data Protection (FDP)
+
+
+_5.1.3.1_ _FDP_ACF_EXT.1: Access Control for System Services_
+
+
+**FDP_ACF_EXT.1.1**
+
+The TSF shall provide a mechanism to restrict the system services that are accessible to
+an application.
+**FDP_ACF_EXT.1.2**
+
+
+35 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+The TSF shall provide an access control policy that prevents [ _**application, groups of**_
+_**applications**_ ] from accessing [ _**all**_ ] data stored by other [ _**application, groups of**_
+_**applications**_ ]. Exceptions may only be explicitly authorized for such sharing by [ _**the**_
+_**administrator, a common application developer**_ ].
+
+
+_5.1.3.2_ _FDP_ACF_EXT.2: Access Control for System Resources_
+
+
+**FDP_ACF_EXT.2.1**
+
+The TSF shall provide a separate [ _**address book, calendar**_ ] for each application group
+and only allow applications within that process group to access the resource. Exceptions
+may only be explicitly authorized for such sharing by [ _**the user**_ ].
+
+
+_5.1.3.3_ _FDP_ACF_EXT.3: Security Attribute Based Access Control_
+
+
+**FDP_ACF_EXT.3.1**
+
+The TSF shall enforce an access control policy that prohibits an application from granting
+both write and execute permission to a file on the device except for [ _**files stored in the**_
+_**applicationโs private data folder**_ ].
+
+
+_5.1.3.4_ _FDP_DAR_EXT.1: Protected Data Encryption_
+
+
+**FDP_DAR_EXT.1.1**
+
+Encryption shall cover all protected data.
+**FDP_DAR_EXT.1.2**
+
+Encryption shall be performed using DEKs with AES in the [ _**CBC, XTS**_ ] mode with key size
+
+[ _**256**_ ] bits.
+
+
+_5.1.3.5_ _FDP_DAR_EXT.2: Sensitive Data Encryption_
+
+
+**FDP_DAR_EXT.2.1**
+
+The TSF shall provide a mechanism for applications to mark data and keys as sensitive.
+**FDP_DAR_EXT.2.2**
+
+The TSF shall use an asymmetric key scheme to encrypt and store sensitive data
+received while the product is locked.
+**FDP_DAR_EXT.2.3**
+
+The TSF shall encrypt any stored symmetric key and any stored private key of the
+asymmetric key(s) used for the protection of sensitive data according to
+FCS_STG_EXT.2.1 selection 2.
+**FDP_DAR_EXT.2.4**
+
+The TSF shall decrypt the sensitive data that was received while in the locked state upon
+transitioning to the unlocked state using the asymmetric key scheme and shall reencrypt that sensitive data using the symmetric key scheme.
+
+
+_5.1.3.6_ _FDP_IFC_EXT.1: Subset Information Flow Control_
+
+
+**FDP_IFC_EXT.1.1**
+
+The TSF shall [
+
+ - _**provide an interface which allows a VPN client to protect all IP traffic using IPsec,**_
+
+ - _**provide a VPN client which can protect all IP traffic using IPsec as defined in the**_
+_**PP-Module for VPN Client**_
+
+
+36 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+] with the exception of IP traffic required to establish the VPN connection and [ _**captive**_
+_**portal traffic needed for correct functioning of the TOE**_ ], when the VPN is enabled.
+
+
+_5.1.3.7_ _MOD_VPNC_V2.4: FDP_IFC_EXT.1: Subset Information Flow Control_
+
+
+**FDP_IFC_EXT.1.1**
+
+The TSF shall provide a VPN client which can protect all IP traffic using IPsec as defined
+in the PP-Module for VPN Client with the exception of IP traffic needed to manage the
+VPN connection, and [selection: [ _**captive portal traffic needed for correct functioning of**_
+_**the TOE**_ ] when the VPN is enabled.
+
+
+_5.1.3.8_ _MOD_VPNC_V2.4: FDP_RIP.2: Full Residual Information Protection_
+
+
+**FDP_RIP.2.1**
+
+The [ _**TOE**_ ] shall ensure that any previous information content of a resource is made
+unavailable upon the [ _**allocation of the resource to**_ ] all objects.
+
+
+_5.1.3.9_ _FDP_STG_EXT.1: User Data Storage_
+
+
+**FDP_STG_EXT.1.1**
+
+The TSF shall provide protected storage for the Trust Anchor Database.
+
+
+_5.1.3.10_ _FDP_UPC_EXT.1/APPS: Inter-TSF User Data Transfer Protection (Applications)_
+
+
+**FDP_UPC_EXT.1.1/APPS**
+
+The TSF shall provide a means for non-TSF applications executing on the TOE to use
+
+ - Mutually authenticated TLS as defined in the Functional Package for Transport Layer
+Security (TLS), version 1.1,
+
+ - HTTPS,
+and [
+
+ - _**IPsec as defined in the PP-Module for Virtual Private Network (VPN) Clients,**_
+_**version 2.4**_
+] to provide a protected communication channel between the non-TSF application and
+another IT product that is logically distinct from other communication channels,
+provides assured identification of its end points, protects channel data from disclosure,
+and detects modification of the channel data.
+**FDP_UPC_EXT.1.2/APPS**
+
+The TSF shall permit the non-TSF applications to initiate communication via the trusted
+channel.
+
+
+_5.1.3.11_ _FDP_UPC_EXT.1/BT: Inter-TSF User Data Transfer Protection (Bluetooth)_
+
+
+**FDP_UPC_EXT.1.1/BT**
+
+The TSF shall provide a means for non-TSF applications executing on the TOE to use
+
+ - Bluetooth BR/EDR in accordance with the PP-Module for Bluetooth,
+and [
+
+ - _**Bluetooth LE in accordance with the PP-Module for Bluetooth, version 1.0**_
+] to provide a protected communication channel between the non-TSF application and
+another IT product that is logically distinct from other communication channels,
+
+
+37 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+provides assured identification of its end points, protects channel data from disclosure,
+and detects modification of the channel data.
+**FDP_UPC_EXT.1.2/BT**
+
+The TSF shall permit the non-TSF applications to initiate communication via the trusted
+channel.
+
+
+_5.1.3.12_ _FDP_VPN_EXT.1: Split Tunnel Prevention_
+
+
+**FDP_VPN_EXT.1.1**
+
+The TSF shall ensure that all IP traffic (other than IP traffic required to establish the VPN
+connection) flow through the IPsec VPN client.
+
+
+5.1.4 Identification and Authentication (FIA)
+
+
+_5.1.4.1_ _FIA_AFL_EXT.1: Authentication Failure Handling_
+
+
+**FIA_AFL_EXT.1.1**
+
+The TSF shall consider password and [ _**no other**_ ] as critical authentication mechanisms.
+**FIA_AFL_EXT.1.2**
+
+The TSF shall detect when a configurable positive integer within [ **1-30** ] of [ _**non-unique**_ ]
+unsuccessful authentication attempts occur related to last successful authentication for
+each authentication mechanism.
+**FIA_AFL_EXT.1.3**
+
+The TSF shall maintain the number of unsuccessful authentication attempts that have
+occurred upon power off.
+**FIA_AFL_EXT.1.4**
+
+When the defined number of unsuccessful authentication attempts has exceeded the
+maximum allowed for a given authentication mechanism, all future authentication
+attempts will be limited to other available authentication mechanisms, unless the given
+mechanism is designated as a critical authentication mechanism.
+**FIA_AFL_EXT.1.5**
+
+When the defined number of unsuccessful authentication attempts for the last available
+authentication mechanism or single critical authentication mechanism has been
+surpassed, the TSF shall perform a wipe of all protected data.
+**FIA_AFL_EXT.1.6**
+
+The TSF shall increment the number of unsuccessful authentication attempts prior to
+notifying the user that the authentication was unsuccessful.
+
+
+_5.1.4.2_ _MOD_BT_V1.0: FIA_BLT_EXT.1: Bluetooth User Authorization_
+
+
+**FIA_BLT_EXT.1.1**
+
+The TSF shall require explicit user authorization before pairing with a remote Bluetooth
+device.
+
+
+_5.1.4.3_ _MOD_BT_V1.0: FIA_BLT_EXT.2: Bluetooth Mutual Authentication_
+
+
+**FIA_BLT_EXT.2.1**
+
+
+38 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+The TSF shall require Bluetooth mutual authentication between devices prior to any
+data transfer over the Bluetooth link.
+
+
+_5.1.4.4_ _MOD_BT_V1.0: FIA_BLT_EXT.3: Rejection of Duplicate Bluetooth Connections_
+
+
+**FIA_BLT_EXT.3.1**
+
+The TSF shall discard pairing and session initialization attempts from a Bluetooth device
+address (BD_ADDR) to which an active session already exists.
+
+
+_5.1.4.5_ _MOD_BT_V1.0: FIA_BLT_EXT.4: Secure Simple Pairing_
+
+
+**FIA_BLT_EXT.4.1**
+
+The TOE shall support Bluetooth Secure Simple Pairing, both in the host and the
+controller.
+**FIA_BLT_EXT.4.2**
+
+The TOE shall support Secure Simple Pairing during the pairing process.
+
+
+_5.1.4.6_ _MOD_BT_V1.0: FIA_BLT_EXT.6: Trusted Bluetooth Device User Authorization_
+
+
+**FIA_BLT_EXT.6.1**
+
+The TSF shall require explicit user authorization before granting trusted remote devices
+access to services associated with the following Bluetooth profiles: [ _**OPP, MA**_ ~~_**P**_~~ ~~]~~
+
+
+_5.1.4.7_ _MOD_BT_V1.0: FIA_BLT_EXT.7: Untrusted Bluetooth Device User Authorization_
+
+
+**FIA_BLT_EXT.7.1**
+
+The TSF shall require explicit user authorization before granting untrusted remote
+devices access to services associated with the following Bluetooth profiles: [ _**OPP**_ ].
+
+
+_5.1.4.8_ _MOD_CPP_BIO_V1.1: FIA_MBE_EXT.1: Biometric enrolment_
+
+
+**FIA_MBE_EXT.1.1**
+
+The TSF shall provide a mechanism to enrol an authenticated user to the biometric
+system.
+
+
+_5.1.4.9_ _MOD_CPP_BIO_V1.1: FIA_MBE_EXT.2 :Quality of biometric templates for biometric_
+
+_enrolment_
+
+
+**FIA_MBE_EXT.2.1**
+
+The TSF shall only use biometric samples of sufficient quality for enrolment. Sufficiency
+of sample data shall be determined by measuring sample with [developer defined
+quality assessment method].
+
+
+_5.1.4.10_ _MOD_CPP_BIO_V1.1: FIA_MBV_EXT.1:BMFPS Biometric verification_ _[1]_
+
+
+**FIA_MBV_EXT.1.1/BMFPS**
+
+The TSF shall provide a biometric verification mechanism using [fingerprint].
+**FIA_MBV_EXT.1.2/BMFPS**
+
+
+1 This applies to the S24 FE, A52, A53
+
+
+39 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+The TSF shall provide a biometric verification mechanism with the [FAR] not exceeding
+
+[1:100,000] for the upper bound of [95%] confidence interval and, [FRR] not exceeding
+
+[2%] for the upper bound of [95%] confidence interval.
+
+
+_5.1.4.11_ _MOD_CPP_BIO_V1.1: FIA_MBV_EXT.1: UDFPS Biometric verification_ _[2]_
+
+
+**FIA_MBV_EXT.1.1/UDFPS**
+
+The TSF shall provide a biometric verification mechanism using [fingerprint].
+**FIA_MBV_EXT.1.2/UDFPS**
+
+The TSF shall provide a biometric verification mechanism with the [FAR] not exceeding
+
+[1:100,000] for the upper bound of [95%] confidence interval and, [FRR] not exceeding
+
+[2%] for the upper bound of [95%] confidence interval.
+
+
+_5.1.4.12_ _MOD_CPP_BIO_V1.1: FIA_MBV_EXT.2 Quality of biometric samples for biometric_
+
+_verification_
+
+
+**FIA_MBV_EXT.2.1**
+
+The TSF shall only use biometric samples of sufficient quality for verification. Sufficiency
+of sample data shall be determined by measuring sample with [developer defined
+quality assessment method].
+
+
+_5.1.4.13_ _MOD_WLANC_V1.0: FIA_PAE_EXT.1: Port Access Entity Authentication_
+
+
+**FIA_PAE_EXT.1.1**
+
+The TSF shall conform to IEEE Standard 802.1X for a Port Access Entity (PAE) in the
+'Supplicant' role.
+
+
+_5.1.4.14_ _FIA_PMG_EXT.1: Password Management_
+
+
+**FIA_PMG_EXT.1.1**
+
+The TSF shall support the following for the Password Authentication Factor:
+1. Passwords shall be able to be composed of any combination of [ _**upper and lower**_
+
+_**case letters**_ ] _**, numbers, and special characters: [! @ # $ % ^ & * ( ) + = _ / - ' " : ;, ? `**_
+_**~ \ | < > { } [ ] ]**_ ];
+2. Password length up to [ **16** ] characters shall be supported.
+
+
+_5.1.4.15_ _FIA_TRT_EXT.1: Authentication Throttling_
+
+
+**FIA_TRT_EXT.1.1**
+
+The TSF shall limit automated user authentication attempts by [ _**enforcing a delay**_
+_**between incorrect authentication attempts**_ ] for all authentication mechanisms selected
+in FIA_UAU.5.1. The minimum delay shall be such that no more than 10 attempts can be
+attempted per 500 milliseconds.
+
+
+_5.1.4.16_ _FIA_UAU.5: Multiple Authentication Mechanisms_
+
+
+**FIA_UAU.5.1**
+
+
+2 This applies to Galaxy Z Fold6.
+
+
+40 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+The TSF shall provide password and [ _**fingerprint, hybrid**_ ] to support user authentication.
+**FIA_UAU.5.2**
+
+The TSF shall authenticate any user's claimed identity according to the [ **following rules:**
+
+ - **Passwords**
+
+`o` **Can be used at any time**
+
+ - **Biometric**
+
+`o` **Can only be used**
+
+ - **When there is an enrolled biometric,**
+
+ - **When the user enables the allow biometrics for unlock feature,**
+
+ - **The non-critical biometric failed limit has not been reached, and**
+
+ - **At device lock screen (not at the first lock screen after reboot/power-up)**
+
+ - **Hybrid**
+
+`o` **For work environments unlock and hybrid authentication factor configured by**
+
+**the user**
+].
+
+
+_5.1.4.17_ _FIA_UAU.6/CREDENTIAL: Re-authenticating (Credential Change)_
+
+
+**FIA_UAU.6.1/CREDENTIAL**
+
+The TSF shall re-authenticate the user via the Password Authentication Factor under the
+conditions attempted change to any supported authentication mechanisms.
+
+
+_5.1.4.18_ _FIA_UAU.6/LOCKED: Re-authenticating (TSF Lock)_
+
+
+**FIA_UAU.6.1/LOCKED**
+
+The TSF shall re-authenticate the user via an authentication factor defined in
+FIA_UAU.5.1 under the conditions TSF-initiated lock, user-initiated lock, [ _**no other**_
+_**conditions**_ ].
+
+
+_5.1.4.19_ _FIA_UAU.7: Protected Authentication Feedback_
+
+
+**FIA_UAU.7.1**
+
+The TSF shall provide only obscured feedback to the device's display to the user while
+the authentication is in progress.
+
+
+_5.1.4.20_ _FIA_UAU_EXT.1: Authentication for Cryptographic Operation_
+
+
+**FIA_UAU_EXT.1.1**
+
+The TSF shall require the user to present the Password Authentication Factor prior to
+decryption of protected data and encrypted DEKs, KEKs and [ _**long-term trusted channel**_
+_**key material, all software-based key storage**_ ] at startup.
+
+
+_5.1.4.21_ _FIA_UAU_EXT.2: Timing of Authentication_
+
+
+**FIA_UAU_EXT.2.1**
+
+The TSF shall allow [ _**[**_
+
+ - _**enter password or supply biometric authentication factor to unlock**_
+
+ - _**make emergency calls**_
+
+
+41 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+
+ - _**receive calls**_
+
+ - _**take pictures and screen shots (automatically named and stored internally by the**_
+
+_**TOE)**_
+
+ - _**see notifications**_
+
+ - _**configure sound/vibrate/mute**_
+
+ - _**set the volume (up and down) for various sound categories**_
+
+ - _**see the configured banner, access Notification Panel functions (including toggles**_
+
+_**Always on Display**_
+
+ - _**Flashlight**_
+
+ - _**Do not disturb toggle**_
+
+ - _**Auto rotate**_
+
+ - _**Sound (on, mute, vibrate)**_
+
+ - _**Access user configured Edge applications (Edge applications not available on Tab S6)**_
+_**]**_ ] on behalf of the user to be performed before the user is authenticated.
+**FIA_UAU_EXT.2.2**
+
+The TSF shall require each user to be successfully authenticated before allowing any
+other TSF-mediated actions on behalf of that user.
+
+
+_5.1.4.22_ _FIA_UAU_EXT.4: Secondary User Authentication_
+
+
+**FIA_UAU_EXT.4.1**
+
+The TSF shall provide a secondary authentication mechanism for accessing Enterprise
+applications and resources. The secondary authentication mechanism shall control
+access to the Enterprise application and shared resources and shall be incorporated into
+the encryption of protected and sensitive data belonging to Enterprise applications and
+shared resources.
+**FIA_UAU_EXT.4.2**
+
+The TSF shall require the user to present the secondary authentication factor prior to
+decryption of Enterprise application data and Enterprise shared resource data.
+
+
+_5.1.4.23_ _FIA_X509_EXT.1: Validation of Certificates_
+
+
+**FIA_X509_EXT.1.1**
+
+The TSF shall validate certificates in accordance with the following rules:
+
+ - RFC 5280 certificate validation and certificate path validation
+
+ - The certificate path must terminate with a certificate in the Trust Anchor Database
+
+ - The TSF shall validate a certificate path by ensuring the presence of the
+basicConstraints extension, that the CA flag is set to TRUE for all CA certificates, and
+that any path constraints are met.
+
+ - The TSF shall validate that any CA certificate includes caSigning purpose in the key
+usage field
+
+ - The TSF shall validate the revocation status of the certificate using [ _**OCSP as**_
+_**specified in RFC 6960 (for TLS, HTTPS, EAP-TLS, IPsec), CRL as specified in RFC 8603**_
+_**(for TLS, HTTPS)**_ ].
+
+ - The TSF shall validate the extendedKeyUsage field according to the following rules:
+
+
+42 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+
+`o` Certificates used for trusted updates and executable code integrity verification
+
+shall have the Code Signing purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3) in the
+extendedKeyUsage field
+
+`o` Server certificates presented for TLS shall have the Server Authentication
+
+purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field
+
+`o` Server certificates presented for EST shall have the CMC Registration Authority
+
+(RA) purpose (id-kp-cmcRA with OID 1.3.6.1.5.5.7.3.28) in the
+extendedKeyUsage field. [conditional]
+
+`o` Client certificates presented for TLS shall have the Client Authentication purpose
+
+(id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the EKU field.
+
+`o` OCSP certificates presented for OCSP responses shall have the OCSP Signing
+
+purpose (id-dp 9 with OID 1.3.6.1.5.5.7.3.9) in the EKU field. [conditional]
+**FIA_X509_EXT.1.2**
+
+The TSF shall only treat a certificate as a CA certificate if the basicConstraints extension
+is present and the CA flag is set to TRUE.
+
+
+_5.1.4.24_ _MOD_WLANC_V1.0: FIA_X509_EXT.1/WLAN: X.509 Certificate Validation_
+
+
+**FIA_X509_EXT.1.1/WLAN**
+
+The TSF shall validate certificates for EAP-TLS in accordance with the following rules:
+
+ - RFC 5280 certificate validation and certificate path validation
+
+ - The certificate path must terminate with a certificate in the Trust Anchor Database
+
+ - The TSF shall validate a certificate path by ensuring the presence of the
+basicConstraints extension and that the CA flag is set to TRUE for all CA certificates
+
+ - The TSF shall validate the extendedKeyUsage field according to the following rules:
+
+`o` Server certificates presented for TLS shall have the Server Authentication
+
+purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field
+
+`o` Client certificates presented for TLS shall have the Client Authentication purpose
+
+(id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field.
+**FIA_X509_EXT.1.2/WLAN**
+
+The TSF shall only treat a certificate as a CA certificate if the basicConstraints extension
+is present and the CA flag is set to TRUE.
+
+
+_5.1.4.25_ _FIA_X509_EXT.2: X.509 Certificate Authentication_
+
+
+**FIA_X509_EXT.2.1**
+
+The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication
+for mutually authenticated TLS as defined in the Package for Transport Layer Security,
+HTTPS, [ _**IPsec in accordance with the PP-Module for VPN Client**_ ], and [ _**no additional**_
+_**uses**_ ].
+**FIA_X509_EXT.2.2**
+
+When the TSF cannot establish a connection to determine the validity of a certificate,
+the TSF shall [ _**not accept the certificate**_ ].
+
+
+43 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+_5.1.4.26_ _MOD_WLANC_V1.0: FIA_X509_EXT.2/WLAN: X.509 Certificate Authentication (EAP-TLS_
+
+_for WLAN)_
+
+
+**FIA_X509_EXT.2.1/WLAN**
+
+The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication
+for EAP-TLS exchanges.
+
+
+_5.1.4.27_ _FIA_X509_EXT.3: Request Validation of Certificates_
+
+
+**FIA_X509_EXT.3.1**
+
+The TSF shall provide a certificate validation service to applications.
+**FIA_X509_EXT.3.2**
+
+The TSF shall respond to the requesting application with the success or failure of the
+validation.
+
+
+_5.1.4.28_ _MOD_WLANC_V1.0: FIA_X509_EXT.6: Certificate Storage and Management_
+
+
+**FIA_X509_EXT.6.1/WLAN**
+
+The TSF shall [ _**store and protect**_ ] to store and protect certificate(s) from unauthorized
+deletion and modification.
+**FIA_X509_EXT.6.2/WLAN**
+
+The TSF shall [ _**provide the capability for authorized administrators to load X.509v3**_
+_**certificates into the TOE**_ ] for use by the TSF.
+
+
+5.1.5 Security Management (FMT)
+
+
+_5.1.5.1_ _FMT_MOF_EXT.1: Management of Security Functions Behavior_
+
+
+**FMT_MOF_EXT.1.1**
+
+The TSF shall restrict the ability to perform the functions in column 3 of Table 8 Security Management Functions to the user.
+**FMT_MOF_EXT.1.2**
+
+The TSF shall restrict the ability to perform the functions in column 5 of Table 8 Security Management Functions to the administrator when the device is enrolled and
+according to the administrator-configured policy.
+
+
+_5.1.5.2_ _FMT_SMF.1: Specification of Management Functions_
+
+
+**FMT_SMF.1.1**
+
+The TSF shall be capable of performing the functions in column 2 of Table 8 - Security
+Management Functions.
+
+
+44 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+|Management Function
Mandatory = M
Implemented = I|Implemented|User Only|Admin|Admin Only|
+|---|---|---|---|---|
+|1. configure password policy:
a. minimum password length
b. minimum password complexity
c.
maximum password lifetime
The administrator can configure the required password characteristics (minimum length,
complexity, and lifetime) using the MDM APIs.
There are distinct settings for the passwords used to unlock the personal and work
profiles.
Length: an integer value of characters (0 = no minimum)
Complexity: Unspecified, Something, Numeric, Alphabetic, Alphanumeric, Complex.
Lifetime: an integer value of days (0 = no maximum)|M||M|M|
+|2. configure session locking policy:
a. screen-lock enabled/disabled
b. screen lock timeout
c.
number of authentication failures
The administrator can configure the session locking policy using the MDM APIs. There are
distinct settings for personal and work profile inactivity.
The user can also adjust each of the session locking policies for the personal and work
profile; however, if set by the administrator, the user can only set a more restrictive policy
(e.g., setting the device to allow fewer authentication failures than configured by the
administrator).
Screen lock timeout: an integer number of minutes before the TOE locks (0 = no lock
timeout)
Authentication failures: an integer number (0 = no limit)|M||M|M|
+|3. enable/disable the VPN protection:
a. across device
[
**_b. on a per-app basis,_**
**_c. _**
**_on a per-group of applications processes basis_**
]
The user can configure and then enable the TOEโs VPN to protect traffic across the entire
device.
The administrator (through an MDM Agent that utilizes the MDM APIs) can restrict the
TOEโs ability to connect to a VPN.
The administrator can configure per-app and per-work profile VPN connections with the
work profile MDM APIs.|M||I|I|
+|4. enable/disable [**NFC**3**, Bluetooth, Wi-Fi, and cellular radios**]
The administrator can disable the radios using the TOEโs MDM APIs. Once disabled, a user
cannot enable the radio. The administrator cannot fully disable/restrict cellular voice
capabilities. The TOEโs radios operate at frequencies of 2.4 GHz (NFC/Bluetooth), 2.4/5
GHz (Wi-Fi), and 850 MHz (4G/LTE).|M||I|I|
+
+
+
+45 of 96
+
+
+
+3 Samsung Galaxy Tab S7 devices do not have NFC radios.
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+|Management Function
Mandatory = M
Implemented = I|Implemented|User Only|Admin|Admin Only|
+|---|---|---|---|---|
+|5. enable/disable [**camera, microphone**]:
a. across device
[
**_d. no other method_**
]
An administrator may configure the TOE (through an MDM agent utilizing the MDM APIs)
to turn off the camera and or microphones. If the administrator has disabled either the
camera or the microphones, then the user cannot use those capture devices.
The administrator can also disable the use of the camera or microphone inside a work
profile without affecting access to those devices when outside the work profile.|M||I|I|
+|6. transition to the locked state
Both users and administrators (using the MDM APIs) can transition the TOE into a locked
state.|M||M|-|
+|7. TSF wipe of protected data
Both users and administrators (using the MDM APIs) can force the TOE to perform a full
wipe (factory reset) of data.|M||M||
+|8. configure application installation policy by:
[
**_a. restricting the sources of applications_**
**_b. specifying a set of allowed applications based on [application name, developer_**
**_signature] (an application whitelist)_**
**_c. _**
**_denying installation of applications_**
]
The administrator using the TOEโs MDM APIs can configure the TOE so that applications
cannot be installed and can also block the use of the Google Play Store. There are distinct
settings for disabling the installation of applications for the personal and work profile.|M||M|M|
+|9. import keys/secrets into the secure key storage
Both users and administrators (using the MDM APIs) can import secret keys into the
secure key storage.|M||I||
+|10. destroy imported keys/secrets and [**_no other keys/secrets_**] in the secure key storage
Both users and administrators (using the MDM APIs) can destroy secret keys in the secure
key storage.|M||I||
+|11. import X.509v3 certificates into the Trust Anchor Database
Both users and administrators (using the MDM APIs) can import X.509v3 certificates into
the Trust Anchor Database.|M||M||
+|12. remove imported X.509v3 certificates and [**_default X.509v3 certificates_**] in the Trust
Anchor Database
Both users and administrators (using the MDM APIs) can remove imported X.509v3
certificates from the Trust Anchor Database as well as disable any of the TOEโs default
Root CA certificates (in the latter case, the CA certificate still resides in the TOEโs read-only
system partition; however, the TOE will treat that Root CA certificate and any certificate
chaining to it as untrusted).|M||I||
+
+
+
+46 of 96
+
+
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+
+
+
+
+|Management Function
Mandatory = M
Implemented = I|Implemented|User Only|Admin|Admin Only|
+|---|---|---|---|---|
+|13. enroll the TOE in management
TOE users can enroll the TOE in management according to the instructions specific to a
given MDM. Presumably any enrollment would involve at least some user functions (e.g.,
install an MDM agent application) on the TOE prior to enrollment.|M|I|||
+|14. remove applications
Both users and administrators (using the MDM APIs) can uninstall user and administrator
installed applications in the personal profile and applications inside a work profile.|M||M||
+|15. update system software
Users can check for updates and cause the device to update if an update is available. An
administrator can use MDM APIs to query the version of the TOE and query the installed
applications and an MDM agent on the TOE could issue pop-ups, initiate updates, block
communication, etc. until any necessary updates are completed. Note that the system
software covers the entire mobile device (including all work profile software).|M||M||
+|16. install applications
Both users and administrators (using the MDM APIs) can install applications in the
personal profile and applications inside a work profile. Only administrators (using the
MDM APIs) can specify to install applications in a Knox Separated Apps folder.|M||M||
+|17. remove Enterprise applications
Both users and administrators (using the MDM APIs) can uninstall user and administrator
installed applications in the personal profile and applications inside a work profile.
Applications installed within the work profile are marked as Enterprise (work) applications|M||M||
+|18. enable/disable display notification in the locked state of:
[
**_f. _**
**_all notifications_**
]
TOE users can configure the TOE to allow or disallow notifications while in a locked state.|M||||
+|19. enable data-at rest protection
The TOE always encrypts user data storage.|M||||
+|20. enable removable mediaโs data-at-rest protection
The administrator (using the MDM APIs) can configure a removable media encryption
policy (on supported devices4). Once enabled, the device will prompt a user to encrypt a
newly inserted external SD cards (and the device will then encrypt any files present after
which the device can use the SD Card). If the user chooses not to encrypt the newly
inserted external SD card, then the device cannot access the SD Card. If the administrator
has set the policy to force encrypt removable media, then the settings option to decrypt
the SD Card is greyed out and the user cannot decrypt the SD Card.|M||I|I|
+
+
+4 Samsung Galaxy Z Fold6 and S24 FE devices do not support removable media.
+
+
+
+47 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+|Management Function
Mandatory = M
Implemented = I|Implemented|Col3|User Only|Admin|Col6|Admin Only|Col8|
+|---|---|---|---|---|---|---|---|
+|21. enable/disable location services:
a. across device
[
**_d. no other method_**
]
The administrator (using the MDM APIs) can disable location services.
Unless disabled by the administrator, TOE users can enable and disable location services.|M|M||I|I|I|I|
+|22. enable/disable the use of [**_Fingerprint Authentication Factor, Hybrid Authentication_**
**_Factor_**]
The TOE supports disabling Biometric authentication for the both the TOEโs normal device
lock screen and for the TOEโs work profile lock screen. The TOEโs normal device lock
screen supports biometrics, which the administrator can disable. The TOEโs work profile
supports hybrid authentication (combination of password and biometrics), which the
administrator can also disable.|M|M||I|I|I|I|
+|23. configure whether to allow/disallow establishment of a trusted channel if the
peer/server certificate is deemed invalid.|I|I||||||
+|24. enable/disable all data signaling over [assignment: list of externally accessible
hardware ports]||||||||
+|25. enable/disable [assignment: list of protocols where the device acts as a server]||||||||
+|26. enable/disable developer modes
The administrator (using the MDM APIs) can disable Developer Mode.
Unless disabled by the administrator, TOE users can enable and disable Developer Mode.|I|I||I|I|I|I|
+|27. enable/disable bypass of local user authentication||I|||I||I|
+|28. wipe Enterprise data
The TOE work profile provides the ability to remove only Enterprise data versus user data.|I|I||||||
+|29. approve [**selection:** _import, removal_] by applications of X.509v3 certificates in the
Trust Anchor Database||||||||
+|30. configure whether to allow/disallow establishment of a trusted channel if the TSF
cannot establish a connection to determine the validity of a certificate||||||||
+|31. enable/disable the cellular protocols used to connect to cellular network base stations||||||||
+|32. read audit logs kept by the TSF
The administrator (using the MDM APIs) can view the TOEโs audit records.|I|I||I|I|||
+|33. configure [**selection**: _certificate, public-key_] used to validate digital signature on
applications||||||||
+|34. approve exceptions for shared use of keys/secrets by multiple applications||||||||
+|35. approve exceptions for destruction of keys/secrets by applications that did not import
the key/secret||||||||
+|36. configure the unlock banner
The administrator (using the MDM APIs) can define a banner of a maximum of 256
characters to be displayed while the TOE is locked. There is no method for the user to
change the banner.|I|I||I|I|I|I|
+|37. configure the auditable items||||||||
+|38. retrieve TSF-software integrity verification values||||||||
+
+
+48 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+
+
+
+
+
+
+
+|Management Function
Mandatory = M
Implemented = I|Implemented|Col3|User Only|Admin|Col6|Admin Only|Col8|
+|---|---|---|---|---|---|---|---|
+|39. enable/disable
[
**_a. USB mass storage mode_**
]
The administrator (using the MDM APIs) can disable USB mass storage mode.|I|I||I|I|I|I|
+|40. enable/disable backup of [**selection:**_all applications, selected applications, selected_
_groups of applications, configuration data_] to [**selection:** _locally connected system,_
_remote system_]||||||||
+|41. enable/disable
[
**_a. Hotspot functionality authenticated by [pre-shared key],_**
**_b. USB tethering authenticated by [passcode]_**
]
The administrator (using the MDM APIs) can disable the wireless hotspot and USB
tethering.
If enabled by the administrator (and supported by the device5), TOE users can configure:
โข
A Wi-Fi hotspot with a pre-shared key
โข
A Bluetooth hotspot with another device that has been successfully completed a
Bluetooth pairing (establishing a pre-shared key)
โข
A USB tethering connection when the user has first authenticated to the device
(the tethering connection will be maintained when the device locks, but initial
setup requires the user to actively approve the connection via authentication to
the device)|I|I||I|I|I|I|
+|42. approve exceptions for sharing data between [**_groups of applications_**]
The TOE work profile and Knox Separated Apps folder provide separation between groups
of application processes along with the ability to control the ability to share data between
these groups|I|I||||I|I|
+|43. place applications into application process groups based on [**creating a** **Knox**
**Separated Apps folder**]|I|I||I|I|I|I|
+|44. unenroll the TOE from management||I|||I||I|
+|45. Enable/disable the Always On VPN protection
a. across device
[
**_b. on a per-app basis,_**
**_c. _**
**_on a per-group of applications processes basis_**]
The user can be required to use an Always On VPN|I|I||I|I|I|I|
+|46. revoke Biometric template||||||||
+
+
+
+5 Not all devices support all (or any) options for tethering. Many carriers require additional subscriptions/payments
+to enable tethering features on the device. The Tab S7 devices and the Tab S6 do not support tethering.
+
+
+49 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+
+
+
+
+
+
+
+
+|Management Function
Mandatory = M
Implemented = I|Implemented|User Only|Admin|Admin Only|
+|---|---|---|---|---|
+|47. additional management functions
[
โข
**enable/disable USB host storage**
โข
**disable CC Mode**
โข
**enable/disable manual Date/Time changes**
โข
**enable/disable applications (including pre-installed)**
]
The user can always disable CC Mode by entirely wiping the device (factory reset), as this
will return the phone to its factory state (in which CC Mode has not been enabled)|
I
I
I
I||
I
I
I
I|
I
I
I
I|
+
+
+_**Table 8 - Security Management Functions**_
+
+
+_5.1.5.3_ _MOD_BT_CLI_V1.0: FMT_SMF_EXT.1/BT: Specification of Management Functions_
+
+_(Bluetooth)_
+
+
+**FMT_SMF_EXT.1.1/BT**
+
+The TSF shall be capable of performing the following Bluetooth management functions:
+
+
+
+|Management Function
Mandatory = M
Implemented = I|Implemented|User Only|Admin|Admin Only|
+|---|---|---|---|---|
+|BT1.
Configure the Bluetooth trusted channel.
โข
Disable/enable the Discoverable (for BR/EDR) and Advertising (for LE)
modes;|M||I|I|
+|BT2.
Change the Bluetooth device name (separately for BR/EDR and LE);|||||
+|BT3.
Provide separate controls for turning the BR/EDR and LE radios on and off;|||||
+|BT4.
Allow/disallow the following additional wireless technologies to be used with
Bluetooth: [**_NFC_**];
Wi-Fi Direct services to transfer files can be enabled/disabled by the admin. NFC can
be disabled and so unable to be used for Bluetooth pairing.|I||I|I|
+|BT5.
Configure allowable methods of Out of Band pairing (for BR/EDR and LE);|||||
+|BT6.
Disable/enable the Discoverable (for BR/EDR) and Advertising (for LE) modes
separately;|||||
+|BT7.
Disable/enable the Connectable mode (for BR/EDR and LE);|||||
+|BT8.
Disable/enable the Bluetooth [**assignment:**list of Bluetooth service and/or
profiles available on the OS (for BR/EDR and LE)];|||||
+|BT9.
Specify minimum level of security for each pairing (for BR/EDR and LE);|||||
+
+
+_**Table 9 - Bluetooth Security Management Functions**_
+
+
+
+
+
+_5.1.5.4_ _MOD_WLANC_V1.0: FMT_SMF_EXT.1/WLAN: Specification of Management Functions_
+
+_(WLAN Client)_
+
+
+**FMT_SMF_EXT.1.1/WLAN**
+
+The TSF shall be capable of performing the following management functions:
+
+
+50 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+
+
+|Management Function
Mandatory = M
Implemented = I|Implemented|Col3|User Only|Admin|Admin Only|Col7|
+|---|---|---|---|---|---|---|
+|WL1.
configure security policy for each wireless network:
a. [**_specify the CA(s) from which the TSF will accept WLAN authentication_**
**_server certificate(s)_**]
b. security type
c.
authentication protocol
d. client credentials to be used for authentication;|M|M||M|I|I|
+|WL2.
specify wireless networks (SSIDs) to which the TSF may connect;|M|M||M||I|
+|WL3.
enable/disable disable wireless network bridging capability (for example,
bridging a connection between the WLAN and cellular radios to function as a
hotspot) authenticated by [**pre-shared key**]|M|M||M|||
+|WL4.
enable/disable certificate revocation list checking;|||||||
+|WL5.
disable ad hoc wireless client-to-client connection capability;|||||||
+|WL6.
disable roaming capability|||||||
+|WL7.
enable/disable IEEE 802.1X pre-authentication|||||||
+|WL8.
loading X.509 certificates into the TOE||I|||||
+|WL9.
revoke X.509 certificates loaded into the TOE||I|||||
+|WL10. enable/disable and configure PMK caching
a. set the amount of time (in minutes) for which PMK entries are cached
b. set the maximum number of PMK entries that can be cached|||||||
+
+
+_**Table 10 - WLAN Security Management Functions**_
+
+
+_5.1.5.5_ _MOD_VPNC_V2.4: FMT_SMF.1/VPN: Specification of Management Functions - VPN_
+
+
+**FMT_SMF.1.1/VPN**
+
+The TSF shall be capable of performing the following management functions **:**
+
+|Management Function
Mandatory = M
Implemented = I|Implemented|Col3|User Only|Admin|Admin Only|
+|---|---|---|---|---|---|
+|VPN1.
Specify VPN gateways to use for connections||I||||
+|VPN2.
Specify IPsec VPN Clients to use for connections||||||
+|VPN3.
Specify IPsec-capable network devices to use for connections||||||
+|VPN4.
Specify client credentials to be used for connections||I||||
+|VPN5.
Configure the reference identifier of the peer||I||||
+|VPN6.
[any additional VPN management functions]||||||
+
+
+
+_**Table 11 - VPN Security Management Functions**_
+
+
+_5.1.5.6_ _FMT_SMF_EXT.2: Specification of Remediation Actions_
+
+
+**FMT_SMF_EXT.2.1**
+
+The TSF shall offer [
+
+ - _**wipe of protected data**_
+
+ - _**wipe of sensitive data**_
+
+
+51 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+ - _**remove Enterprise applications**_
+
+ - _**remove all device-stored Enterprise resource data**_
+
+ - _**remove Enterprise secondary authentication data**_
+] upon unenrollment and [ _**no other triggers**_ ].
+
+
+_5.1.5.7_ _FMT_SMF_EXT.3: Current Administrator_
+
+
+**FMT_SMF_EXT.3.1**
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+The TSF shall provide a mechanism that allows users to view a list of currently
+authorized administrators and the management functions that each administrator is
+authorized to perform.
+
+
+5.1.6 Protection of the TSF (FPT)
+
+
+_5.1.6.1_ _FPT_AEX_EXT.1: Application Address Space Layout Randomization_
+
+
+**FPT_AEX_EXT.1.1**
+
+The TSF shall provide address space layout randomization ASLR to applications.
+**FPT_AEX_EXT.1.2**
+
+The base address of any user-space memory mapping will consist of at least 8
+unpredictable bits.
+
+
+_5.1.6.2_ _FPT_AEX_EXT.2: Memory Page Permissions_
+
+
+**FPT_AEX_EXT.2.1**
+
+The TSF shall be able to enforce read, write, and execute permissions on every page of
+physical memory.
+
+
+_5.1.6.3_ _FPT_AEX_EXT.3: Stack Overflow Protection_
+
+
+**FPT_AEX_EXT.3.1**
+
+TSF processes that execute in a non-privileged execution domain on the application
+processor shall implement stack-based buffer overflow protection.
+
+
+_5.1.6.4_ _FPT_AEX_EXT.4: Domain Isolation_
+
+
+**FPT_AEX_EXT.4.1**
+
+The TSF shall protect itself from modification by untrusted subjects.
+**FPT_AEX_EXT.4.2**
+
+The TSF shall enforce isolation of address space between applications.
+
+
+_5.1.6.5_ _FPT_AEX_EXT.5: Kernel Address Space Layout Randomization_
+
+
+**FPT_AEX_EXT.5.1**
+
+The TSF shall provide address space layout randomization (ASLR) to the kernel.
+**FPT_AEX_EXT.5.2**
+
+The base address of any kernel-space memory mapping will consist of [ **6** ] unpredictable
+bits.
+
+
+_5.1.6.6_ _FPT_AEX_EXT.6: Write or Execute Memory Page Permissions_
+
+
+**FPT_AEX_EXT.6.1**
+
+
+52 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+The TSF shall prevent write and execute permissions from being simultaneously granted
+to any page of physical memory [ _**excluding memory used for JIT (just-in-time)**_
+_**compilation and memory allocated with mmap**_ ].
+
+
+_5.1.6.7_ _FPT_BBD_EXT.1: Application Processor Mediation_
+
+
+**FPT_BBD_EXT.1.1**
+
+The TSF shall prevent code executing on any baseband processor (BP) from accessing
+application processor (AP) resources except when mediated by the AP.
+
+
+_5.1.6.8_ _MOD_CPP_BIO_V1.1:FPT_BDP_EXT.1: Biometric data processing_
+
+
+**FPT_BDP_EXT.1.1**
+Processing of plaintext biometric data shall be inside the TEE in runtime.
+**FPT_BDP_EXT.1.2**
+
+Transmission of plaintext biometric data between the capture sensor and the TEE shall
+be isolated from the main computer operating system on the TSF in runtime.
+
+
+_5.1.6.9_ _FPT_JTA_EXT.1: JTAG Disablement_
+
+
+**FPT_JTA_EXT.1.1**
+
+The TSF shall [ _**control access by a signing key**_ ] to JTAG.
+
+
+_5.1.6.10_ _FPT_KST_EXT.1 & MOD_CPP_BIO_V1.1/FPT_KST_EXT.1: Key Storage_
+
+
+**FPT_KST_EXT.1.1**
+
+The TSF shall not store any plaintext key material or **biometric data** in readable nonvolatile memory.
+
+
+_5.1.6.11_ _FPT_KST_EXT.2 & MOD_CPP_BIO_V1.1/FPT_KST_EXT.2: No Key Transmission_
+
+
+**FPT_KST_EXT.2.1**
+
+The TSF shall not transmit any plaintext key material or **biometric data** outside the
+security boundary of the TOE.
+
+
+_5.1.6.12_ _FPT_KST_EXT.3: No Plaintext Key Export_
+
+
+**FPT_KST_EXT.3.1**
+
+The TSF shall ensure it is not possible for the TOE user(s) to export plaintext keys.
+
+
+_5.1.6.13_ _FPT_NOT_EXT.1: Self-Test Notification_
+
+
+**FPT_NOT_EXT.1.1**
+
+The TSF shall transition to non-operational mode and [ _**force User authentication failure**_ ]
+when the following types of failures occur:
+
+ - failures of the self-test(s)
+
+ - TSF software integrity verification failures
+
+ - [ _**no other failures**_ ].
+
+
+_5.1.6.14_ _MOD_CPP_BIO_V1.1/FPT_PBT_EXT.1: Protection of biometric template_
+
+
+**FPT_PBT_EXT.1.1**
+
+
+53 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+The TSF shall protect the biometric template [using a password as an additional factor].
+
+
+_5.1.6.15_ _FPT_STM.1: Reliable time stamps_
+
+
+**FPT_STM.1.1**
+
+The TSF shall be able to provide reliable time stamps for its own use.
+
+
+_5.1.6.16_ _FPT_TST_EXT.1: TSF Cryptographic Functionality Testing_
+
+
+**FPT_TST_EXT.1.1**
+
+The TSF shall run a suite of self-tests during initial start-up (on power on) to
+demonstrate the correct operation of all cryptographic functionality.
+
+
+_5.1.6.17_ _MOD_WLANC_V1.0: FPT_TST_EXT.3/WLAN: TSF Cryptographic Functionality Testing_
+
+_(WLAN Client)_
+
+
+**FPT_TST_EXT.3.1/WLAN**
+
+The [ _**TOE platform**_ ] shall run a suite of self-tests during initial start-up (on power on) to
+demonstrate the correct operation of the TSF.
+**FPT_TST_EXT.3.2/WLAN**
+
+The [ _**TOE platform**_ ] shall provide the capability to verify the integrity of stored TSF
+executable code when it is loaded for execution through the use of the TSF-provided
+cryptographic services.
+
+
+_5.1.6.18_ _MOD_VPNC_V2.4: FPT_TST_EXT.1/VPN: TSF Self-Test (VPN Client)_
+
+
+**FPT_TST_EXT.1.1/VPN**
+
+The [ _**TOE Platform**_ ] shall run a suite of self -tests during initial start-up (on power on) to
+demonstrate the correct operation of the TSF.
+**FPT_TST_EXT.1.2/VPN**
+
+The [ _**TOE, TOE Platform**_ ] shall provide the capability to verify the integrity of stored TSF
+executable code when it is loaded for execution through the use of the [ **cryptographic**
+**signature and hash for integrity** ].
+
+
+_5.1.6.19_ _FPT_TST_EXT.2/PREKERNEL: TSF Integrity Checking (Pre-Kernel)_
+
+
+**FPT_TST_EXT.2.1/PREKERNEL**
+
+The TSF shall verify the integrity of the bootchain up through the Application Processor
+OS kernel stored in mutable media prior to its execution through the use of [ _**an**_
+_**immutable hardware hash of an asymmetric key**_ ].
+
+
+_5.1.6.20_ _FPT_TST_EXT.2/POSTKERNEL: TSF Integrity Checking (Post-Kernel)_
+
+
+**FPT_TST_EXT.2.1/POSTKERNEL**
+
+The TSF shall verify the integrity of [ _**[the /system partition**_ _]_ ], stored in mutable media
+prior to its execution through the use of [ _**hardware-protected hash**_ ].
+
+
+_5.1.6.21_ _FPT_TUD_EXT.1: Trusted Update: TSF Version Query_
+
+
+**FPT_TUD_EXT.1.1**
+
+The TSF shall provide authorized users the ability to query the current version of the
+TOE firmware/software.
+
+
+54 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+**FPT_TUD_EXT.1.2**
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+The TSF shall provide authorized users the ability to query the current version of the
+hardware model of the device.
+**FPT_TUD_EXT.1.3**
+
+The TSF shall provide authorized users the ability to query the current version of
+installed mobile applications.
+
+
+_5.1.6.22_ _FPT_TUD_EXT.2: TSF Update Verification_
+
+
+**FPT_TUD_EXT.2.1**
+
+The TSF shall verify software updates to the Application Processor system software and
+
+[ _**[communications processor software, bootloader software, carrier specific**_
+_**configuration]**_ ] using a digital signature verified by the manufacturer trusted key prior
+to installing those updates.
+**FPT_TUD_EXT.2.2**
+
+The TSF shall [ _**update only by verified software**_ ] the TSF boot integrity [ _**key, hash**_ ].
+**FPT_TUD_EXT.2.3**
+
+The TSF shall verify that the digital signature verification key used for TSF updates
+
+[ _**matches an immutable hardware public key**_ ].
+
+
+_5.1.6.23_ _FPT_TUD_EXT.3: Application Signing_
+
+
+**FPT_TUD_EXT.3.1**
+
+The TSF shall verify mobile application software using a digital signature mechanism
+prior to installation.
+
+
+_5.1.6.24_ _FPT_TUD_EXT.6: Trusted Update Verification_
+
+
+**FPT_TUD_EXT.6.1**
+
+The TSF shall verify that software updates to the TSF are a current or later version than
+the current version of the TSF.
+
+
+5.1.7 TOE Access (FTA)
+
+
+_5.1.7.1_ _FTA_SSL_EXT.1: TSF- and User-initiated Locked State_
+
+
+**FTA_SSL_EXT.1.1**
+
+The TSF shall transition to a locked state after a time interval of inactivity.
+**FTA_SSL_EXT.1.2**
+
+The TSF shall transition to a locked state after initiation by either the user or the
+administrator.
+**FTA_SSL_EXT.1.3**
+
+The TSF shall, upon transitioning to the locked state, perform the following operations:
+a. clearing or overwriting display devices, obscuring the previous contents;
+b. [ **no other actions** ].
+
+
+_5.1.7.2_ _FTA_TAB.1: Default TOE Access Banners_
+
+
+**FTA_TAB.1.1**
+
+
+55 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+Before establishing a user session, the TSF shall display an advisory warning message
+regarding unauthorized use of the TOE.
+
+
+_5.1.7.3_ _MOD_WLANC_V1.0: FTA_WSE_EXT.1: Wireless Network Access_
+
+
+**FTA_WSE_EXT.1.1**
+
+The TSF shall be able to attempt connections only to wireless networks specified as
+acceptable networks as configured by the administrator in FMT_SMF_EXT.1.1/WLAN.
+
+
+5.1.8 Trusted Path/Channels (FTP)
+
+
+_5.1.8.1_ _MOD_BT_V1.0: FTP_BLT_EXT.1: Bluetooth Encryption_
+
+
+**FTP_BLT_EXT.1.1**
+
+The TSF shall enforce the use of encryption when transmitting data over the Bluetooth
+trusted channel for BR/EDR and [ _**LE**_ ].
+**FTP_BLT_EXT.1.2**
+
+The TSF shall use key pairs per FCS_CKM_EXT.8 for Bluetooth encryption.
+
+
+_5.1.8.2_ _MOD_BT_V1.0: FTP_BLT_EXT.2: Persistence of Bluetooth Encryption_
+
+
+**FTP_BLT_EXT.2.1**
+
+The TSF shall [ **restart encryption** ] if the remote device stops encryption while connected
+to the TOE.
+
+
+_5.1.8.3_ _MOD_BT_V1.0: FTP_BLT_EXT.3/BR: Bluetooth Encryption Parameters (BR/EDR)_
+
+
+**FTP_BLT_EXT.3.1/BR**
+
+The TSF shall set the minimum encryption key size to [ **128 bits** ] for [ _BR/EDR_ ] and not
+negotiate encryption key sizes smaller than the minimum size.
+
+
+_5.1.8.4_ _MOD_BT_V1.0: FTP_BLT_EXT.3/LE: Bluetooth Encryption Parameters (LE)_
+
+
+**FTP_BLT_EXT.3.1/LE**
+
+The TSF shall set the minimum encryption key size to [ **128 bits** ] for [ _LE_ ] and not
+negotiate encryption key sizes smaller than the minimum size.
+
+
+_5.1.8.5_ _FTP_ITC_EXT.1: Trusted Channel Communication_
+
+
+**FTP_ITC_EXT.1.1**
+
+The TSF shall use
+
+ - 802.11-2012 in accordance with the PP-Module for WLAN Clients, version 1.0,
+
+ - 802.1X in accordance with the PP-Module for WLAN Clients, version 1.0,
+
+ - EAP-TLS in accordance with the PP-Module for WLAN Clients, version 1.0,
+
+ - mutually authenticated TLS as defined in the Package for Transport Layer Security,
+version 1.1
+and [
+
+ - _**IPsec in accordance with the PP-Module for VPN Client, version 2.4,**_
+
+ - _**HTTPS**_
+] protocols to provide a communication channel between itself and another trusted IT
+product that is logically distinct from other communication channels, provides assured
+
+
+56 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+identification of its end points, protects channel data from disclosure, and detects
+modification of the channel data.
+**FTP_ITC_EXT.1.2**
+
+The TSF shall permit the TSF to initiate communication via the trusted channel.
+**FTP_ITC_EXT.1.3**
+
+The TSF shall initiate communication via the trusted channel for wireless access point
+connections, administrative communication, configured enterprise connections, and [ _**no**_
+_**other connections**_ ].
+
+
+_5.1.8.6_ _MOD_WLANC_V1.0: FTP_ITC.1/WLAN: Trusted Channel Communication (Wireless LAN)_
+
+
+**FTP_ITC.1.1/WLAN**
+
+The TSF shall use 802.11-2012, 802.1X, and EAP-TLS to provide a trusted communication
+channel between itself and a wireless access point that is logically distinct from other
+communication channels and provides assured identification of its end points and
+protection of the channel data from modification or disclosure.
+**FTP_ITC.1.2/WLAN**
+
+The TSF shall permit the TSF to initiate communication via the trusted channel.
+**FTP_ITC.1.3/WLAN**
+
+The TSF shall initiate communication via the trusted channel for wireless access point
+connections.
+
+### 5.2 TOE Security Assurance Requirements
+
+
+The SARs are as specified in Part 3 of the Common Criteria. Note that the SARs have effectively been
+refined with the assurance activities explicitly defined in association with both the SFRs and SARs.
+
+
+5.2.1 Development (ADV)
+
+
+_5.2.1.1_ _ADV_FSP.1: Basic Functional Specification_
+
+
+**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.
+**ADV_FSP.1.1c**
+
+The functional specification shall describe the purpose and method of use for each SFRenforcing and SFR-supporting TSFI.
+**ADV_FSP.1.2c**
+
+The functional specification shall identify all parameters associated with each SFRenforcing and SFR-supporting TSFI.
+**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.
+**ADV_FSP.1.1e**
+
+
+57 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+The evaluator shall confirm that the information provided meets all requirements for
+content and presentation of evidence.
+**ADV_FSP.1.2e**
+
+The evaluator shall determine that the functional specification is an accurate and
+complete instantiation of the SFRs.
+
+
+5.2.2 Guidance Documents (AGD)
+
+
+_5.2.2.1_ _AGD_OPE.1: Operational User Guidance_
+
+
+**AGD_OPE.1.1d**
+
+The developer shall provide operational user guidance.
+**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, in particular 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 measures
+to be followed in order to fulfill 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.
+**AGD_OPE.1.1e**
+
+The evaluator shall confirm that the information provided meets all requirements for
+content and presentation of evidence.
+
+
+_5.2.2.2_ _AGD_PRE.1: Preparative Procedures_
+
+
+**AGD_PRE.1.1d**
+
+The developer shall provide the TOE, including its preparative procedures.
+**AGD_PRE.1.1c**
+
+
+58 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+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.
+**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.3 Life-cycle Support (ALC)
+
+
+_5.2.3.1_ _ALC_CMC.1: Labelling of the TOE_
+
+
+**ALC_CMC.1.1d**
+
+The developer shall provide the TOE and a reference for the TOE.
+**ALC_CMC.1.1c**
+
+The TOE shall be labelled with its unique reference.
+**ALC_CMC.1.1e**
+
+The evaluator shall confirm that the information provided meets all requirements for
+content and presentation of evidence.
+
+
+_5.2.3.2_ _ALC_CMS.1: TOE CM Coverage_
+
+
+**ALC_CMS.1.1d**
+
+The developer shall provide a configuration list for the TOE.
+**ALC_CMS.1.1c**
+
+The configuration list shall include the following: the TOE itself; and the evaluation
+evidence required by the SARs.
+**ALC_CMS.1.2c**
+
+The configuration list shall uniquely identify the configuration items.
+**ALC_CMS.1.1e**
+
+The evaluator shall confirm that the information provided meets all requirements for
+content and presentation of evidence.
+
+
+_5.2.3.3_ _ALC_TSU_EXT.1: Timely Security Updates_
+
+
+**ALC_TSU_EXT.1.1d**
+
+The developer shall provide a description in the TSS of how timely security updates are
+made to the TOE.
+**ALC_TSU_EXT.1.1c**
+
+The description shall include the process for creating and deploying security updates for
+the TOE software.
+**ALC_TSU_EXT.1.2c**
+
+
+59 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+The description shall express the time window as the length of time, in days, between
+public disclosure of a vulnerability and the public availability of security updates to the
+TOE.
+**ALC_TSU_EXT.1.3c**
+
+The description shall include the mechanisms publicly available for reporting security
+issues pertaining to the TOE.
+**ALC_TSU_EXT.1.4c**
+
+The description shall include where users can seek information about the availability of
+new updates including details (e.g. CVE identifiers) of the specific public vulnerabilities
+corrected by each update.
+**ALC_TSU_EXT.1.1e**
+
+The evaluator shall confirm that the information provided meets all requirements for
+content and presentation of evidence.
+
+
+5.2.4 Tests (ATE)
+
+
+_5.2.4.1_ _ATE_IND.1: Independent Testing - sample_
+
+
+**ATE_IND.1.1d**
+
+The developer shall provide the TOE for testing.
+**ATE_IND.1.1c**
+
+The TOE shall be suitable for testing.
+**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.5 Vulnerability Assessment (AVA)
+
+
+_5.2.5.1_ _AVA_VAN.1: Vulnerability Survey_
+
+
+**AVA_VAN.1.1d**
+
+The developer shall provide the TOE for testing.
+**AVA_VAN.1.1c**
+
+The TOE shall be suitable for testing.
+**AVA_VAN.1.1e**
+
+The evaluator shall confirm that the information provided meets all requirements for
+content and presentation 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 possessing Basic attack potential.
+
+
+60 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+## 6 TOE Summary Specification
+
+
+This chapter describes the security functions:
+
+ - Security audit
+
+ - Cryptographic support
+
+ - User data protection
+
+ - Identification and authentication
+
+ - Security management
+
+ - Protection of the TSF
+
+ - TOE access
+
+ - Trusted path/channels
+
+### 6.1 Security Audit
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+**FAU_GEN.1**
+TOE provides several distinct mechanisms for Security Audit logging โ one introduced via KNOX APIs,
+and one introduced from mainline AOSP โ Security Log
+(https://developer.android.com/reference/android/app/admin/SecurityLog). Some events might only
+be audited by one of these systems, so the client is encouraged to monitor both. Section 5.1 of the
+Administrator Guide describes the fields in the audit records.
+
+
+The following table enumerates the events that the TOE audits including the mechanisms logging it.
+Requirements marked with โ(O)โ are from the Additional Auditable Events table of the PP_MDF_V3.3.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+61 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+_**Table 12 - Audit Events**_
+
+
+**MOD_BT_V1.0: FAU_GEN.1/BT**
+The following table enumerates the events that the TOE audits from Table 2: Auditable Events of the
+MOD_BT_V1.0. Requirements marked with โ(O)โ are optional in the table.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+_**Table 13 โ Bluetooth Audit Events**_
+
+
+
+**MOD_WLANC_V1.0: FAU_GEN.1/WLAN**
+The following table enumerates the events that the TOE audits from Table 2: Auditable Events of the
+MOD_WLANC_V1.0.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+_**Table 14 โ WLAN Client Audit Events**_
+
+
+
+62 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+**FAU_SAR.1**
+The TOE provides the ability for the administrator to export and read the audit log.
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+**FAU_STG.1**
+The TOE stores audit records in a file within the file system accessible only to Linux processes with
+system permissions (effectively the TSF itself and MDM agents using the defined APIs). These
+restrictions prevent the unauthorized modification or deletion of the audit records stored in the audit
+files.
+
+
+**FAU_STG.4**
+The TOE pre-allocates a file system area (between 10MB and 50MB in size, depending upon available
+storage on the device) by creating a /data/system/[admin_uid]_bubble/bubbleFile and directory
+(/data/system/[admin_uid]) in which to archive compressed audit logs. If the TOE lacks sufficient space
+(at least 10MB), then the TOE returns a failure code in response to the administratorโs attempt to
+enable the AuditLog. Once enabled, the TOE writes audit events into nodes until they read a given size,
+and then compresses and archives the records. The TOE utilizes a circular buffer approach to handle
+when the accumulated, compressed audit events exceed the allocated file system size. When the limit is
+reached, the TOE removes the oldest audit logs, freeing space for new records.
+
+### 6.2 Cryptographic Support
+
+
+**FCS_CKM.1**
+The TOE supports asymmetric key generation for all types in accordance with FIPS 186-5. The TOE
+generates RSA keys in its BoringSSL and SCrypto library and generates DH/ECDH/ECDSA (including P-256,
+P384 and P-521) keys in BoringSSL and ECDSA (including P-256, P384 and P-521) keys in in SCrypto. The
+TOE supports generating keys with a security strength of 112-bits and larger, thus supports 2048-bit RSA
+and DH keys, and 256-bit ECDH/ECDSA keys. The TOEโs RSA and ECDSA implementations have the CAVP
+certificates described in the FCS_COP.1 section below.
+
+
+_**Table 15 - Asymmetric Key Generation per Module**_
+
+
+**MOD_WLANC_V1.0: FCS_CKM.1/WLAN**
+The TOE adheres to IEEE 802.11-2012 and IEEE 802.11ac-2014 for key generation. The TOEโs
+wpa_supplicant provides the PRF384 and PRF704 for WPA3/WPA2 derivation of 128-bit or 256-bit AES
+Temporal Key (using the HMAC implementation provided by BoringSSL) and employs its BoringSSL AES256 DRBG when generating random values used in the EAP-TLS and 802.11 4-way handshake. The TOE
+supports the AES-128 CCMP encryption mode. The TOE has successfully completed certification
+(including WPA3/WPA2 Enterprise) and received Wi-Fi CERTIFIED Interoperability Certificates from the
+Wi-Fi Alliance. The Wi-Fi Alliance maintains a website providing further information about the testing
+[program: http://www.wi-fi.org/certification.](http://www.wi-fi.org/certification)
+
+
+63 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+
+
+
+
+
+
+
+
+
+
+64 of 96
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+
+
+
+
+
+
+|Device Name Model Number Wi-Fi Alliance Certificate Numbers|Col2|
+|---|---|
+|SM-T638x
SM-T630x|SM-T638x
SM-T630x|
+|Galaxy S21 Ultra
SM-G998x
102482, 103060, 102486, 109409, 109162, 109410, 109164, 103062,
103084, 103087|Galaxy S21 Ultra
SM-G998x
102482, 103060, 102486, 109409, 109162, 109410, 109164, 103062,
103084, 103087|
+|Galaxy S21+
SM-G996x
102477, 103030, 102479, 103026, 103028, 103073, 103077, 103079|Galaxy S21+
SM-G996x
102477, 103030, 102479, 103026, 103028, 103073, 103077, 103079|
+|Galaxy S21
SM-G990x
119290,119706,119879|Galaxy S21
SM-G990x
119290,119706,119879|
+|Galaxy S21 5G FE
SM-G990x
119290, 119706, 119879|Galaxy S21 5G FE
SM-G990x
119290, 119706, 119879|
+|Galaxy A52
SM-G78xx
110242, 110243, 110475, 110613,
110614||
+|Galaxy Z Fold6 5G
SM-F956x
125692, 126097, 126098, 126099, 126164, 126165
|Galaxy Z Fold6 5G
SM-F956x
125692, 126097, 126098, 126099, 126164, 126165
|
+|Galaxy Z Flip6 5G
SM-F741x
125544, 126061, 126063, 126223, 126224
|Galaxy Z Flip6 5G
SM-F741x
125544, 126061, 126063, 126223, 126224
|
+|Galaxy Z Fold6 A
SM-F958
131717|Galaxy Z Fold6 A
SM-F958
131717|
+|Galaxy A53 5G
SM-A536
SM-S536
117220, 117304, 117536, 117578, 117579, 117580, 117581, 117880,
117881, 117882, 117902, 1211138|Galaxy A53 5G
SM-A536
SM-S536
117220, 117304, 117536, 117578, 117579, 117580, 117581, 117880,
117881, 117882, 117902, 1211138|
+|Galaxy S24 FE
SM-S721x
131705, 132146, 132147, 132247, 132248|Galaxy S24 FE
SM-S721x
131705, 132146, 132147, 132247, 132248|
+|Galaxy A36 5G
SM-A366
133887, 134088, 134087, 135641, 133836, 134035, 134036|Galaxy A36 5G
SM-A366
133887, 134088, 134087, 135641, 133836, 134035, 134036|
+|Galaxy A56 5G
SM-A566
133691, 134031, 134032, 134033|Galaxy A56 5G
SM-A566
133691, 134031, 134032, 134033|
+
+
+_**Table 16 - W-Fi Alliance Certificates**_
+
+
+**MOD_VPNC_V2.4: FCS_CKM.1/VPN**
+The VPN uses the TOE cryptographic libraries to generate asymmetric keys (RSA or ECDSA) for
+authentication during the IKE key exchange. Note that ECDSA is only supported by IKEv2 connections.
+
+
+**FCS_CKM.2/UNLOCKED**
+The TOE supports RSA (800-56B, as an initiator only), DHE (FFC 800-56A), and ECDHE (ECC 800-56A)
+methods in TLS key establishment/exchange. The TOE has CVL KAS and ECDSA CAVP algorithm
+certificates for Elliptic Curve key establishment and key generation respectively as described in the
+FCS_COP.1 section below. Samsung vendor-affirms that the TOEโs RSA key establishment follows 80056B. The TOE implementation meets RFC 3526 Section 3. The user and administrator need take no
+special configuration of the TOE as the TOE automatically generates the keys needed for negotiated TLS
+ciphersuites. Because the TOE only acts as a TLS client, the TOE only performs 800-56B encryption
+(specifically the encryption of the Pre-Master Secret using the Serverโs RSA public key) when
+participating in TLS_RSA_* based TLS handshakes. Thus, the TOE does not perform 800-56B decryption.
+However, the TOEโs TLS client correctly handles other cryptographic errors (for example, invalid
+checksums, incorrect certificate types, corrupted certificates) by sending a TLS fatal alert. As the TOE's
+RSA key exchange mechanism is used in the TLS handshake process and during product development,
+the TOE's implementation undergoes testing to ensure TLS compatibility.
+
+
+**FCS_CKM.2/LOCKED**
+For the S25, S24, S23, Tab Active 5 and their equivalent devices, the TOE provides a Sensitive Data
+Protection (SDP) library for applications that uses a hybrid crypto scheme based on 4096-bit RSA based
+key establishment. Applications can utilize this library to implement SDP that encrypts incoming data
+received while the phone is locked in a manner compliant with this requirement. For other devices, the
+
+
+65 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+TOE uses ECDH with a P-256 curve key establishment for protection of application sensitive data
+received while the device is locked.
+
+
+**MOD_WLANC_V1.0: FCS_CKM.2/WLAN**
+The TOE adheres to RFC 3394, SP 800-38F, and 802.11-2012 standards and unwraps the GTK (sent
+encrypted with the WPA3/2 KEK using AES Key Wrap in an EAPOL-Key frame). The TOE, upon receiving
+an EAPOL frame, will subject the frame to a number of checks (frame length, EAPOL version, frame
+payload size, EAPOL-Key type, key data length, EAPOL-Key CCMP descriptor version, and replay counter)
+to ensure a proper EAPOL message and then decrypt the GTK using the KEK, thus ensuring that it does
+not expose the Group Temporal Key (GTK).
+
+
+**FCS_CKM_EXT.1**
+The TOE supports a Root Encryption Key (REK) within the main (application) processor. Requests for
+encryption or decryption chaining to the REK are only accessible through the Trusted Execution
+Environment, or TEE (TrustZone). The REK lies in a series of 256-bit fuses, programmed during
+manufacturing. The TEE does not allow direct access to the REK but provides services to derive a HEK
+(Hardware Encryption Key, which is derived from the REK through a KDF function) for encryption and
+decryption.
+
+
+The REK value is generated during manufacturing either by the TOE (if it detects that the REK fuses have
+not been set) using its hardware DRBG or is generated during fabrication using an external RBG that
+meets the requirements of this PP in that the process utilizes a SHA-256 Hash_DRBG seeded by a
+hardware entropy source identical in architecture to that within the TOE. The application processor
+loads the fuse value into an internal hardware crypto register and the Trusted Execution Environment
+(TEE) provides trusted applications the ability to derive KEKs from the REK (using an SP 800-108 KDF to
+combine the REK with a salt). Additionally, the when the REK is loaded, the fuses for the REK become
+locked, preventing any further changing or loading of the REK value. The TEE does not allow trusted
+applications to use the REK for encryption or decryption, only the ability to derive a KEK from the REK.
+The TOE includes a TEE application that calls into the TEE in order to derive a KEK from the 256-bit
+REK/fuse value and then only permits use of the derived KEK for encryption and decryption as part of
+the TOE key hierarchy. This fabrication process includes strict controls (including physical and logical
+access control to the manufacturing room where programming takes place as well as video surveillance
+and access only to specific, authorized, trusted individuals) to ensure that the fabricator cannot access
+any REK values between generation and programming.
+
+
+**FCS_CKM_EXT.2** _**(KMD)**_
+The TOE supports Data Encryption Key (DEK) generation using its approved RBGs for use in SD card
+encryption. The TOE RBGs are capable of generating AES 256-bit DEKs in response to applications and
+services on the device. These can be accessed through both Android native APIs and C APIs depending
+on the library being called. For FBE, the TOE supports using a SP800-108 KDF to concatenate keys
+together to generate unique DEKs. The keys used in the SP800-108 KDF are generated by the approved
+RBGs. The TOE can also generate 128-bit asymmetric keys used for sensitive data protection.
+
+
+**FCS_CKM_EXT.3** _**(KMD)**_
+The TOE generates KEKs (which are always AES 256-bit keys generated by one of the TOEโs DRBGs)
+through a combination of methods. First, the TOE generates a KEK (the Keystore masterkey) for each
+user of the TOE. The TOE also generates encryption KEKs for FBE, the SD Card encryption, and work
+profile encryption (normal and sensitive).
+
+
+The TOE generates a number of different KEKs. In addition to the TSF KEKs, applications may request key
+generation (through either the Android APIs or SCrypto APIs within the TEE), and the TOE utilizes its
+
+
+66 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+BoringSSL/SCrypto CTR_DRBG and Kernel Crypto HMAC_DRBG to satisfy those requests. The requesting
+application ultimately chooses whether to use that key as a DEK or a KEK, but it is worth mentioning
+here, as an application can utilize such a key as a KEK, should it choose.
+
+
+**FCS_CKM_EXT.4** _**(KMD)**_
+The TOE destroys all the cryptographic keys (plaintext keys, authentication and biometric data, and
+other security parameters) when they are no longer in use by the system. The exceptions to this are
+public keys (that protect the boot chain and software updates) and the REK, which are never cleared.
+Keys stored in RAM during use are destroyed by a zero overwrite. Keys stored in Flash (i.e. eMMC) are
+destroyed by cryptographic erasure through a block erase call to the flash controller for the location
+where the FBE and SD Card keys are stored. Once these are erased, all keys (and data) stored within the
+encrypted data partition of the TOE are considered cryptographically erased.
+
+
+**FCS_CKM_EXT.5**
+The TOE provides a TOE Wipe function that first erases the encrypted DEKs used to encrypt the data
+partition using a block erase and read verify command to ensure that the UFS blocks containing the
+encrypted DEKs (FBE and SD card) are now reported as empty. After the encrypted keys have been
+erased, the TOE will delete the entire user partition with a block erase command and then reformat the
+partition. Upon completion of reformatting the Flash partition holding user data, the TOE will perform a
+power-cycle.
+
+
+**FCS_CKM_EXT.6**
+The TOE creates salt and nonces (which are just salt values used in WPA3/WPA2) using its AES-256
+CTR_DRBG.
+
+
+_**Table 17 - Salt Creation**_
+
+
+**MOD_BT_V1.0:FCS_CKM_EXT.8**
+The TOE will generate new ECDH key pairs for every pairing attempt.
+
+
+**FCS_COP.1/ENCRYPT**
+**FCS_COP.1/HASH**
+**FCS_COP.1/SIGN**
+**FCS_COP.1/KEYHMAC**
+**FCS_COP.1/CONDITION**
+
+
+The TOE performs cryptographic algorithms in accordance with the following NIST standards and has
+received the following CAVP algorithm certificates.
+
+
+The BoringSSL v1.9 library (with both Processor Algorithm Accelerators (PAA) and without PAA) provides
+the following algorithms.
+
+
+67 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+_**Table 18 - BoringSSL Cryptographic Algorithms**_
+
+
+
+The Samsung Crypto Extension v1.0 library provides the following algorithms.
+
+
+_**Table 19 - Samsung Crypto Extension Cryptographic Algorithms**_
+
+
+The evaluated devices utilize the following kernels for the Samsung Kernel Cryptographic Module
+(Kernel Crypto).
+
+
+_**Table 20 - Kernel Versions**_
+
+
+The Samsung Kernel Cryptographic (โKernel Cryptoโ) Module provides the following algorithms. Note that
+with and without PAA is equivalent to with and without crypto extensions.
+
+
+68 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+_**Table 21 - Samsung Kernel Cryptographic Algorithms**_
+
+
+The evaluated devices utilize the Samsung SCrypto Cryptographic Module for cryptographic operations
+within the TEE on each device. The following table lists the TEE operating systems for each device.
+
+
+_**Table 22 - TEE Environments**_
+
+
+The Samsung SCrypto TEE library provides the following algorithms. Note that the TOE only performs
+RSA signing/decryption (using the private key) in the TEE, and performs public key
+verification/encryption in the normal world using BoringSSL.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+69 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+_**Table 23 - SCrypto TEE Cryptographic Algorithms**_
+
+
+The Chipset hardware for storage encryption has various modules that provide cryptographic functions.
+The modules and versions are listed here. Only discrete modules are listed here.
+
+
+_**Table 24 - Hardware Components**_
+
+
+The storage encryption modules provide the following algorithms.
+
+
+_**Table 25 - Storage Hardware Algorithms**_
+
+
+The devices contain unique Wi-Fi chipsets based on the model of the device. The chipsets are listed
+here.
+
+
+
+
+
+
+
+70 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+_**Table 26 - Wi-Fi Hardware Components**_
+
+
+
+The Wi-Fi chipset hardware provides the following algorithms.
+
+
+_**Table 27 - Wi-Fi Chip Algorithms**_
+
+
+Several devices provide a secure processor for mutable hardware key storage. The devices and chipsets
+are listed here.
+
+
+71 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+_**Table 28 - Mutable Key Storage Components**_
+
+
+The chipsets for the mutable hardware key storage provide the following algorithms.
+
+
+_**Table 29 - Mutable Key Storage Cryptographic Algorithms**_
+
+
+The SoC hardware provides the following algorithms.
+
+
+_**Table 30 - SoC Cryptographic Algorithms**_
+
+
+72 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+The TOEโs application processors include hardware entropy implementations that supply random data
+within the TEE and to the Linux kernel RNG (primary input pool).
+
+
+Note that kernel-space system applications utilize the cryptographic algorithm implementations in the
+Samsung Kernel Cryptographic Module (Kernel Crypto) or in the Chipset hardware, while user-space
+system applications and mobile applications utilize the BoringSSL library (through the Android API). In
+the case of each cryptographic library, the library itself includes any algorithms required (for example,
+BoringSSL provides hash functions for use by HMAC and digital signature algorithms).
+
+
+Trusted Applications executing with the Trusted Execution Environment (TEE) utilize the SCrypto library.
+For example, the trusted application implementing the Android Keymaster that supports the Android
+Keystore utilizes the SCrypto library for all of its cryptographic functionality.
+
+
+For its HMAC implementations, the TOE accepts all key sizes of 160, 256, 384, & 512; supports all SHA
+sizes save 224 (e.g., SHA-1, 256, 384, & 512), utilizes the specified block size (512 for SHA-1 and 256, and
+1024 for SHA-384 & 512); and outputs MAC lengths of 160, 256, 384, and 512.
+
+
+The TOE conditions the userโs password using a combination of functions to increase the memory
+required for derivation to thwart attacks. This combination of functions is embedded in the scrypt
+algorithm. Scrypt uses three steps to condition the password:
+
+
+1. One PBKDF2 operation (NIST SP 800-132)
+
+
+2. Several rounds of ROMix operations
+
+
+3. One final PBKDF2 operation (NIST SP 800-132)
+
+
+This value is used as input for decrypting other keys that are tied to successful user authentication.
+
+
+To unlock the userโs keystore, the value generated in the previous step us conditioned further using
+PBKDF2 (NIST SP 800-132). The key derivation function uses the value derived from the initial password
+conditioning and a randomly generated 128-bit salt in 8192 HMAC-SHA-256 iterations to generate a 256bit KEK.
+
+
+In both cases of conditioning, the time needed to derive keying material does not impact or lessen the
+difficulty faced by an attackerโs exhaustive guessing as the combination of the password derived KEK
+with REK value entirely prevents offline attacks and the TOEโs maximum incorrect password login
+attempts (between 1 and 30 incorrect attempts with 4 character, minimum, passwords) prevents
+exhaustive online attacks.
+
+
+The TOEโs algorithm certificates represent the BoringSSL library, Kernel Cryptographic module, SCrypto
+library, Crypto Extensions library and Chipset hardware implementations. These implementations have
+been tested upon Android 15 running atop both Exynos and Qualcomm ARMv8 chipsets. The TOEโs
+Exynos processor devices include the Samsung Flash Memory Protector, while the TOEโs Qualcomm
+processor devices include hardware XTS-AES (Inline Crypto Engine, ICE) implementations for internal
+storage encryption and decryption.
+
+
+**FCS_HTTPS_EXT.1**
+The TOE includes the ability to support the HTTPS protocol (compliant with RFC 2818) so that (mobile
+and system client) applications executing on the TOE can securely connect to external servers using
+HTTPS. Administrators have no credentials and cannot use HTTPS or TLS to establish administrative
+sessions with the TOE as the TOE does not provide any such capabilities.
+
+
+**MOD_VPNC_V2.4: FCS_IPSEC_EXT.1**
+
+
+73 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+The TOEโs VPN Client implements the IPsec protocol as specified in RFC 4301; however, the VPN Client
+presents as few configuration options as possible to the User in order to minimize the possibility of
+misconfiguration and relies upon the Gateway to enforce organizational policies, for things like the
+specific cipher suites and selection of traffic to protect. For this reason, the VPN Client does not support
+editing of its SPD entries. The VPN Client will insert a PROTECT rule to IPsec encrypt and send all TOE
+traffic to the VPN GW (as the VPN Client ignores the IKEv2 Traffic Selector negotiated between the client
+and gateway and always sends all traffic).
+
+
+The VPN Client routes all packets through the kernelโs IPsec interface (ipsec0) when the VPN is active.
+The kernel compares packets routed through this interface to the SPDs configured for the VPN to
+determine whether to PROTECT, BYPASS, or DISCARD each packet. The vendor designed the TOEโs VPN
+Client, when operating in CC Mode, to allow no SPD configuration and always force all traffic through
+the VPN. The VPN Client ignores any IKEv2 traffic selector negotiations with the VPN GW and will always
+create an SPD PROTECT rule that matches all traffic. Thus, the kernel will match all packets,
+subsequently encrypt those packets, and finally forward them to the VPN Gateway. The VPN Client
+supports tunnel mode for its IPsec connections. The VPN Client provides IKEv2 key establishment as part
+of its IPsec implementation. The IKEv2 implementation is conformant with RFCs 5996 and 4307 and
+supports NAT traversal.
+
+
+The TOE provides RFC 4106 conformant AES-GCM-128 and AES-GCM-256, and RFC 3602 conformant
+AES-CBC-128 and AES-CBC-256 as encryption algorithms. The TOE Platform also provides SHA-1, SHA256, SHA-384, and SHA-512 in addition to HMAC-SHA1, HMAC-SHA-256, HMAC-SHA-384, and HMACSHA-512 as integrity/authentication algorithms (producing message digests of 160, 256, 384, and 512bits in length) as well as Diffie-Hellman Groups 14, 19, 20 and 24. The VPN utilizes the algorithms from
+the BoringSSL and Kernel Cryptographic modules as part of the IKEv2 and IPsec protocols. The encrypted
+payload for IKEv2 uses AES-CBC-128, AES-CBC-256 as specified in RFC 6379 and AES-GCM-128 and AESGCM-256 as specified in RFC 5282. The TOE relies upon the VPN Gateway to ensure that by default the
+strength of the symmetric algorithm (in terms of the number of bits in the key) negotiated to protect the
+IKEv2 /IKE_SA connection is greater than or equal to the strength of the symmetric algorithm (in terms
+of the number of bits in the key) negotiated to protect the IKEv2 CHILD_SA connection.
+
+
+An administrator can configure the VPN Gateway to limit SA lifetimes based on length of time to values
+that include 24 hours for IKE SAs and 8 hours for IPsec SAs. The TOE includes hardcoded limits of 10
+hours for an IKE SA and 3 hours for an IPsec SA. The TOE and VPN Gateway will rekey their IKE and IPsec
+SAs after the shorter of either 10 hours or 3 hours respectively (the TOEโs fixed lifetimes) or the
+administrator specified lifetime configured on the VPN Gateway.
+
+
+The VPN Client generates the secret value x used in the IKEv2 Diffie-Hellman key exchange ('x' in g [x] mod
+p) using the FIPS validated RBG specified in FCS_RBG_EXT.1 and having possible lengths of 224, 256, or
+384 bits. When a random number is needed for a nonce, the probability that a specific nonce value will
+be repeated during the life of a specific IPsec SA is less than 1 in 2 [112], 2 [128], or 2 [192] .
+
+
+The VPN Client implements peer authentication using RSA certificates or ECDSA certificates that
+conform to RFC 4945 and FIPS 186-5. If certificates are used, the VPN Client ensures that the IP address
+or Fully Qualified Distinguished Name (FQDN) contained in a certificate matches the expected IP Address
+or FQDN for the entity attempting to establish a connection and ensures that the certificate has not
+been revoked (using the Online Certificate Status Protocol [OCSP] in accordance with RFC 2560).
+
+
+The TOE supports a number of different Diffie-Hellman (DH) groups for use in SA negotiation including
+DH Groups 14 (2048-bit MODP), 19 (256-bit Random ECP), 20 (384-bit Random ECP), and 24 (2048-bit
+
+
+74 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+MODP with 256-bit POS). The TOE selects the DH group by selecting the largest group configured by an
+administrator that is offered by the VPN gateway.
+
+
+During the Peer Authentication stage of IPsec, the TOE Platform will verify the authenticity of the VPN
+gatewayโs X.509v3 certificate by validating the certificate, validating the certificate path, validating the
+certificateโs revocation status using OCSP, validating that the certificate path terminates in a trusted CA
+certificate, and validating that the CA certificate has the basicConstraints extension present and the CA
+flag set to true. The TOE will also ensure that the Subject Alternative Name IP address or DNS name in
+the VPN gatewayโs certificate matches the IP address or DNS name configured in the VPN profile. If the
+configured IP address or DNS name does not match a Subject Alternative Name in the VPN gatewayโs
+certificate, the TOE will refuse to establish an IPsec connection with the VPN gateway.
+
+
+The VPN Client relies upon the VPN Gateway to ensure that the cryptographic algorithms and key sizes
+negotiated during the IKEv2 negotiation ensure that the security strength of the Phase 1/IKE_SA are
+greater than or equal to that of the Phase 2/CHILD_SA.
+
+
+**FCS_IV_EXT.1** _**(KMD)**_
+The TOE generates IVs for data storage encryption and for key storage encryption. The TOE uses XTS-AES
+and AES-CBC mode for data encryption and AES-GCM for key storage.
+
+
+**FCS_RBG_EXT.1** _**(KMD)**_
+The TOE provides a number of different RBGs including:
+
+ - An AES-256 CTR_DRBG provided by BoringSSL. The TOE provides mobile applications access
+(through an Android API) to random data drawn from its AES-256 CTR_DRBG
+
+ - An AES-256 CTR_DRBG provided by SCrypto in the TEE
+
+ - A SHA-256 HMAC_DRBG provided by Kernel Crypto in the Android kernel (/dev/random or
+get_random_bytes())
+
+ - A hardware SHA-256 Hash_DRBG provided by the Qualcomm Application Processor hardware
+The TOE ensures that it initializes each RBG with sufficient entropy ultimately accumulated from a TOEhardware-based noise source. The TOE uses its hardware-based noise source to fill primary input pool
+continuously with random data that has full entropy, and in turn, the TOE draws from this input pool to
+seed both its AES-256 CTR_DRBG and its SHA-256 HMAC_DRBG. The TOE seeds each of its software
+DRBGs using 384-bits of data from the primary input pool, thus ensuring at least 256-bits of entropy.
+These RBGs are all capable of providing other amounts of entropy (such as 128-bits) to any requesting
+application. The TOE itself always uses 256-bits of entropy, but other applications or services are not
+subject to this limitation, and can request 128-bits or 256-bits of entropy subject its own requirements.
+The SHA-256 Hash_DRBG in the Qualcomm AP is used to generate the REK on first boot.
+
+
+**FCS_SRV_EXT.1**
+**FCS_SRV_EXT.2** _**(KMD)**_
+The TOE provides applications access to the cryptographic operations including encryption (AES),
+hashing (SHA), signing and verification (RSA & ECDSA), key hashing (HMAC), password-based keyderivation functions (PKBDFv2 HMAC-SHA-512), generating asymmetric keys for key establishment (RSA
+and ECDH), and generating asymmetric keys for signature generation and verification (RSA, ECDSA). The
+hashing functions are implemented in byte-oriented mode. The TOE also provides access through
+Android API methods and through the kernel. The vendor also developed testing applications to enable
+execution of the NIST algorithm test suite in order to verify the correctness of the algorithm
+implementations.
+
+
+75 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+**FCS_STG_EXT.1**
+The TOE provides users, administrators and applications running on the TOE the ability to generate,
+import, and securely store symmetric and asymmetric keys through the TOEโs Android Keystore. The
+TOE allows a user or administrator (via the MDM) to import a certificate (in PKCS#12 [PFX] format) and
+provides applications running on the TOE an API to import a certificate or secret key. In either case, the
+TOE will place the key into the userโs keystore (and the TOE will remove the PKCS#12 password-based
+protection if the imported key is a certificate) and doubly encrypt the imported key with DEKs, which in
+turn are encrypted by a KEK derived from the user's DKEK and a KEK derived from the REK. All user and
+application keys placed into the userโs keystore are secured in this fashion.
+
+
+The user of the TOE can elect to delete keys from the keystore, as well as to wipe the entire device
+securely. The administrator can only delete keys from the keystore that have been deployed to the TOE
+by the administrator.
+
+
+The TOE affords applications control (control over use and destruction) of keys that they create or
+import, and only the common application developer can explicitly authorize access, use, or destruction
+of one applicationโs key by any other application.
+
+
+_**Table 31 - Key Management Matrix**_
+
+
+On the devices with support for mutable hardware storage (see **Error! Reference source not found.** ) the T
+OE provides both software-based (the Android Keystore) and mutable hardware-based (the StrongBox
+Keystore) key storage. The key storage is implemented in a separate hardware chipset that is part of the
+SoC, providing additional protection beyond that normally provided by the Android Keystore which is
+implemented in the TEE. The hardware module implements its own cryptographic services internally to
+the module.
+
+
+By default, all key storage is handled with the Android Keystore, but an application developer can use
+the StrongBox keystore by setting a preference to use the hardware keystore instead. When the
+preference is set to the hardware keystore, the keys will be stored in the mutable hardware and all
+operations on the keys will be handled inside the hardware.
+
+
+**FCS_STG_EXT.2** _**(KMD)**_
+The TOE provides protection for all stored keys (i.e. those written to storage media for persistent
+storage) chained to both the userโs password and the REK. All keys are encrypted with AES-GCM or AESCBC (in the case of SD card File Encryption Keys). All KEKs are 256-bit, ensuring that the TOE encrypts
+every key with another key of equal or greater strength/size.
+
+
+In the case of Wi-Fi, the TOE utilizes the 802.11-2012 KCK and KEK keys to unwrap (decrypt) the
+WPA3/WPA2 Group Temporal Key received from the access point. Additionally, the TOE protects
+persistent Wi-Fi keys (user certificates) by storing them in the Android Keystore.
+
+
+The TOE also stores the SecurityLogAgent (properties related to the SE Android configuration) in the
+same manner as the long-term trusted channel key materials.
+
+
+**FCS_STG_EXT.3**
+
+
+76 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+The key hierarchy shows AES-256-GCM is used to encrypt all KEKs other than SD Card keys (which uses
+HMAC for integrity) and the GCM encryption mode itself ensures integrity as authenticated decryption
+operations fail if the encrypted KEK becomes corrupted.
+
+
+**PKG_TLS_V1.1: FCS_TLS_EXT.1**
+**PKG_TLS_V1.1: FCS_TLSC_EXT.1**
+**PKG_TLS_V1.1: FCS_TLSC_EXT.2**
+**PKG_TLS_V1.1: FCS_TLSC_EXT.4**
+**PKG_TLS_V1.1: FCS_TLSC_EXT.5**
+
+
+The TOE provides mobile applications (through its Android API) the use of TLS version 1.2 only as a
+client, including support for the selected ciphersuites in the selections in section 5.1.2.29. The TOE
+supports Subject Alternative Name (SAN) (DNS and IP address) as reference identifiers. The TOE
+supports client (mutual) authentication. The TOE inherently (without requiring any configuration)
+supports the supported ciphersuites and evaluated elliptic curves (P-256 and P-384); neither the user
+nor the administrator need configure anything in order for the TOE to support these ciphersuites or
+curves. The TOE supports the use of wildcards in X.509 reference identifiers (SAN), and the TOE supports
+certificate pinning through Androidโs Network security configuration. This configuration allows a mobile
+application to specify one or more certificate public key hashes (SHA-1 or SHA-256) along with the
+domain and optionally an expiry. With such a configuration, the application will only establish a TLS
+connection if one of the public keys in the certificate path matches a โpinnedโ key hash. After the
+optional expiry, Android disregards the pinned certificates and performs no pinning (to prevent
+connectivity issues in apps that have not been updated). The TOE includes the โrenegotiation_infoโ TLS
+extension in its TLS client hello message.
+
+
+**MOD_WLANC_V1.0: FCS_TLSC_EXT.1/WLAN**
+**MOD_WLANC_V1.0: FCS_TLSC_EXT.2/WLAN**
+**MOD_WLANC_V1.0: FCS_WPA_EXT.1/WLAN**
+The TSF supports TLS versions 1.2, and 1.1 with client (mutual) authentication and supports the
+ciphersuites in the selections in section 5.1.2.30 for use with EAP-TLS as part of WPA3/2. The TOE, by
+design, supports the evaluated elliptic curves (P-256 and P-384) and requires/allows no configuration of
+the supported curves.
+
+### 6.3 User Data Protection
+
+
+**FDP_ACF_EXT.1**
+**FDP_ACF_EXT.2**
+**FDP_ACF_EXT.3** _**(KMD)**_
+The TOE provides protection for high-level services like location, email, calendar in addition to providing
+individual permissions to which mobile applications can request access. The TOE provides the following
+base permissions to applications (for API Level 34):
+
+
+1. Normal - A lower-risk permission that gives an application access to isolated application-level
+features, with minimal risk to other applications, the system, or the user. The system automatically
+grants this type of permission to a requesting application at installation, without asking for the
+user's explicit approval (though the user always has the option to review these permissions before
+installing).
+2. Dangerous - A higher-risk permission that would give a requesting application access to private
+user data or control over the device that can negatively impact the user. Because this type of
+
+
+77 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+permission introduces potential risk, the system cannot automatically grant it to the requesting
+application. For example, any dangerous permissions requested by an application will be displayed
+to the user and require confirmation before proceeding or some other approach can be taken to
+avoid the user automatically allowing the use of such facilities.
+3. Signature - A permission that the system is to grant only if the requesting application is signed
+with the same certificate as the application that declared the permission. If the certificates match,
+the system automatically grants the permission without notifying the user or asking for the user's
+explicit approval.
+4. Internal - a permission that is managed internally by the system and only granted according to
+the protection flags.
+
+
+An example of a normal permission is the ability to vibrate the device: android.permission.VIBRATE. This
+permission allows an application to make the device vibrate, and an application that does not request
+(or declare) this permission would have its vibration requests ignored.
+
+
+An example of a dangerous privilege would be access to location services to determine the location of
+the mobile device: android.permission.ACCESS_FINE_LOCATION. The TOE controls access to Dangerous
+permissions during the running of the application. The TOE prompts the user to review the applicationโs
+requested permissions (by displaying a description of each permission group, into which individual
+permissions map, that an application requested access to). If the user approves, then the application is
+allowed to continue running. If the user disapproves, the devices continues to run, but cannot use the
+services protected by the denied permissions. Thereafter, the mobile device grants that application
+during execution access to the set of permissions declared in its Manifest file [6] .
+
+
+An example of a signature permission is the android.permission.BIND_VPN_SERVICE that an application
+must declare in order to utilize the VpnService APIs of the device. Because the permission is a Signature
+permission, the mobile device only grants this permission to an application (2nd installed app) that
+requests this permission and that has been signed with the same developer key used to sign the
+application (1st installed app) declaring the permission (in the case of the example, the Android
+Framework itself).
+
+
+An example of an internal permission is the
+android.permission.SET_DEFAULT_ACCOUNT_FOR_CONTACTS, which is only granted to system
+applications fulfilling the Contacts app role to allow the default account for new contacts to be set.
+
+
+Additionally, Android includes the following flags that layer atop the base categories:
+
+
+1. privileged - this permission can also be granted to any applications installed as privileged apps
+
+on the system image. Please avoid using this option, as the signature protection level should be
+sufficient for most needs and works regardless of exactly where applications are installed. This
+permission flag is used for certain special situations where multiple vendors have applications
+built in to a system image which need to share specific features explicitly because they are being
+built together.
+
+
+2. system - Old synonym for 'privileged'.
+
+
+6 Every Android app has a Manifest file that is at the root of the project. The manifest describes essential
+information including the permissions that the app needs in order to access protected parts of the system or other
+apps. It also declares any permissions that other apps must have if they want to access content from this app.
+
+
+78 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+3. development - this permission can also (optionally) be granted to development applications
+
+(e.g., to allow additional location reporting during beta testing).
+
+4. appop - this permission is closely associated with an app op for controlling access.
+
+
+5. pre23 - this permission can be automatically granted to apps that target API levels below API
+
+level 23 (Android 6.0).
+
+
+6. installer - this permission can be automatically granted to system apps that install packages.
+
+
+7. verifier - this permission can be automatically granted to system apps that verify packages.
+
+
+8. preinstalled - this permission can be automatically granted to any application pre-installed on
+
+the system image (not just privileged apps) (the TOE does not prompt the user to approve the
+permission).
+
+
+The Android 15 (Level 35) API (details found here
+[https://developer.android.com/reference/packages) provides services to mobile applications.](https://developer.android.com/reference/packages)
+
+
+While Android provides a large number of individual permissions, they are grouped into categories or
+features that provide similar functionality for the simplicity of the user interaction. These groupings do
+not affect the permissions themselves; it is only a way to group them together for the user presentation.
+Table 32 shows a series of functional categories centered on common functionality.
+
+
+_**Table 32 - Access Control Categories**_
+
+
+Only applications with a common application developer are able to allow sharing of data between the
+applications. Common applications are those signed by a common certificate or key by the developer
+that have permissions to allow data sharing in their manifest. Application data can only be shared under
+this scenario.
+
+
+The TOE provides the ability to create a Knox Separated Apps folder. A Knox Separated Apps folder
+provides an administrator with the ability to isolate applications from the broader system. Access to
+applications placed into the folder does not require separate authentication. Applications within the
+folder are restricted from accessing services provided outside the folder, such as sharing services
+(intents) and data storage.
+
+
+79 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+**FDP_DAR_EXT.1**
+The TOE provides encryption of all data (which includes both user data and TSF data) stored on the data
+partition and on external media (such as an SD Card) of the TOE.
+
+
+The TOE uses FBE to encrypt data using XTS-AES-256 using a unique File Content Encryption Key (FCEK)
+for each file. File metadata (such as filenames) is encrypted separately with AES-CBC-CTS with a unique
+File Name Encryption Key (FNEK) for each file. FBE supports two separate classes of protection,
+credentialed and device. While each class is encrypted, the difference is whether the encryption is
+chained to the userโs credentials. By default, all data is stored in the credential class, and applications
+that will store data in the device class are defined during the installation of the application. Device class
+data can be accessed as soon as the device has started, including prior to the first user authentication.
+
+
+For the protection of data stored on external media (SD Card [7] ), the TOE also provides AES-256-CBC
+encryption of protected data stored using FEKs. The TOE encrypts each individual file stored on the SD
+Card, generating a unique FEK for each file.
+
+
+The TOEโs system executables, libraries, and their configuration data reside in a read-only file system
+outside the data partition.
+
+
+**FDP_DAR_EXT.2** _**(KMD)**_
+For the S25, S24, S23, Tab Active 5, and their equivalent devices, the TOE provides the NIAPSEC library
+for Sensitive Data Protection (SDP) that application developers must use to opt-in for sensitive data
+protection. When developerโs opt-in for SDP, all data that is received on the device destined for that
+application is treated as sensitive. This library calls into the TOE to generate an RSA key that acts as a
+master KEK for the SDP encryption process. When an application that has opted-in for SDP receives
+incoming data while the device is locked, an AES symmetric DEK is generated to encrypt that data. The
+public key from the master RSA KEK above is then used to encrypt the AES DEK. Once the device is
+unlocked, the RSA KEK private key is re-derived and can be used to decrypt the AES DEK for each piece
+of information that was stored while the device was locked. The TOE then takes that decrypted data and
+re-encrypts it following FDP_DAR_EXT.1.
+
+
+For all other devices, the TOE as a part of the Knox Platform for Enterprise, provides mobile applications
+the ability to store sensitive data and have the TOE encrypt it accordingly. This functionality is controlled
+by the administrator through the apps that support sensitive data storage, and is only available for apps
+that have been designed to support sensitive data. When an application stores data as sensitive data,
+the file will be marked as sensitive in the metadata. Based on the environment lock-state, sensitive data
+protected by this mechanism will be encrypted when locked (either directly by the user or via timeout).
+An application can determine whether sensitive data should remain encrypted in this manner or if it
+should be re-encrypted (such as by a symmetric key for better performance). Applications can use this
+to receive and store data securely while the environment is locked (such as an email application).
+
+
+**FDP_IFC_EXT.1**
+**MOD_VPNC_V2.4: FDP_IFC_EXT.1**
+**FDP_VPN_EXT.1**
+
+
+The TOE supports the installation of VPN Client applications, which can make use of the provided VPN
+APIs in order to configure the TOEโs routing functionality to direct all traffic through the VPN. The TOE
+also includes an IPsec VPN Client that ensures all traffic other than traffic necessary to establish the VPN
+
+
+7 Samsung Galaxy XCover6 Pro, Galaxy Tab Active5 Pro, and Galaxy Tab Active5 support removable media.
+
+
+80 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+connection (for example, ARP, 802.11-2012 traffic, and IKEv2) flows through the VPN. The TOE routes all
+packets through the kernelโs IPsec interface (ipsec0) when the VPN is active. The kernel compares
+packets routed through this interface to the SPDs configured for the VPN to determine whether to
+PROTECT, BYPASS, or DISCARD each packet. The vendor developed the TOEโs VPN, when operating in CC
+Mode, to allow no configuration and always force all traffic through the VPN. The TOE ignores any IKEv2
+traffic selector negotiations with the VPN GW and will always create an SPD PROTECT rule that matches
+all traffic. Thus, the kernel will match all packets, subsequently encrypt those packets, and finally
+forward them to the VPN Gateway.
+
+
+**MOD_VPNC_V2.4: FDP_RIP.2**
+The TOE has been designed to ensure that no residual information exists in network packets when the
+VPN is turned on. When the TOE allocates a new buffer for either an incoming or outgoing a network
+packet, the new packet data will be used to overwrite any previous data in the buffer. If an allocated
+buffer exceeds the size of the packet, any additional space will be overwritten (padded) with zeros
+before the packet is forwarded (to the external network or delivered to the appropriate internal
+application).
+
+
+**FDP_STG_EXT.1**
+The TOEโs Trusted Anchor Database consists of the built-in certificates (individually stored in
+`/system/etc/security/cacerts` ) and any additional user or admin/MDM loaded certificates.
+The user can disable the built-in certificates or add new certificates using the TOEโs Android user
+interface [Settings->Security and privacy->More security settings->Credential storage]. The admin is able
+to load new certificates using the MDM. Disabled default certificates and user added certificates reside
+in the `/data/misc/user/0/cacerts-removed` and `/data/misc/user/0/cacerts-`
+`added` directories respectively. The built-in ones are protected, as they are part of the TSFโs read only
+system partition, while the TOE protects user-loaded certificates by storing them with appropriate
+permissions to prevent modification by mobile applications. The TOE also stores the user-loaded
+certificates in the userโs keystore.
+
+
+**FDP_UPC_EXT.1/APPS**
+The TOE provides APIs allowing non-TSF applications (mobile applications) the ability to establish a
+secure channel using IPsec, TLS, and HTTPS. Google provides the NIAPSEC library for application
+developers to use for Hostname Checking, Revocation Checking, and TLS Ciphersuite restriction.
+Application developers must utilize this library to ensure the device behaves in the evaluated
+configuration. Mobile applications can use the following Android APIs for IPsec, TLS and HTTPS
+respectively:
+
+```
+android.net.VpnService
+
+```
+
+[https://developer.android.com/reference/android/net/VpnService.html](https://developer.android.com/reference/android/net/VpnService.html)
+
+```
+com.samsung.android.knox.net.vpn
+
+```
+
+https://seap.samsung.com/api[references/android/reference/com/samsung/android/knox/net/vpn/package-summary.html](https://seap.samsung.com/api-references/android/reference/com/samsung/android/knox/net/vpn/package-summary.html)
+
+```
+javax.net.ssl.SSLContext:
+
+```
+
+[https://developer.android.com/reference/javax/net/ssl/SSLSocket](https://developer.android.com/reference/javax/net/ssl/SSLSocket)
+
+
+Developers then need to swap SocketFactory for SecureSocketFactory, part of a private library provided
+by Google.
+
+
+81 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+[Developers can request this library by emailing: niapsec@google.com](mailto:niapsec@google.com)
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+**FDP_UPC_EXT.1/BT**
+The TOE provides APIs allowing non-TSF applications (mobile applications) the ability to establish a
+secure channel using Bluetooth BR/EDR and Bluetooth LE. Mobile applications can use the following
+Android APIs for Bluetooth:
+
+```
+android.bluetooth
+
+```
+
+[http://developer.android.com/reference/android/bluetooth/package-summary.html](http://developer.android.com/reference/android/bluetooth/package-summary.html)
+
+### 6.4 Identification and Authentication
+
+
+**FIA_AFL_EXT.1**
+The TOE maintains two separate lock screens: the device (Android) lock screen and a lock screen for the
+work profile. Each lock screen maintains individually stored (in separate Flash locations) failed login
+attempt counters.
+
+
+The TOE maintains, for each lock screen, the number of failed logins since the last successful login, and
+upon reaching the maximum number of incorrect logins the TOE performs a full wipe of all protected
+data. For the device lock screen, this would mean a full wipe of all data on the device (a factory reset),
+while for the work profile lock screen this would remove all data associated with the work profile. The
+TOE maintains the number of failed logins across power-cycles (so for example, assuming a configured
+maximum retry of ten incorrect attempts, if one were to enter five incorrect passwords and power cycle
+the phone, the phone would only allow five more incorrect login attempts before wiping) by storing the
+number of logins remaining within its Flash file system. An administrator can adjust the number of failed
+logins to a value between one and 30 through an MDM.
+
+
+For users with biometrics enabled, biometric authentication attempts are maintained along with the
+password attempts. In all cases, biometric or hybrid authentication mechanisms are non-critical and
+cannot be the authentication method that triggers an action (device or work profile wipe).
+
+
+The maximum number of incorrect password authentication attempts can be configured to a value
+between 1 and 30. The maximum number of biometric attempts is 20 (this cannot be configured
+separately and this limit only applies to the device lock screen, not the work profile lock screen). The
+user can attempt 10 biometric attempts followed by the maximum number of password attempts
+before the TOE will wipe itself. For example, if the counter were set to 15, 10 biometric attempts would
+be followed by 15 password attempts before the device was wiped. Alternatively, the user might enter
+14 incorrect passwords, and then twenty failed biometric authentication attempts followed by a final
+incorrect password attempt.
+
+
+The TOEโs work profile provides its own lock screen, which allows password authentication or hybrid
+authentication (biometric and password). The hybrid authentication method requires the user to
+authenticate with a biometric and a password in sequential order. To login, the user must first enter his
+or her Knox biometric and only upon successfully verifying the userโs biometric, the TOE prompts the
+User for their Knox password, and the user must enter their password. Knox will count the number of
+incorrect passwords attempted, and wipe the work profile (and its associated data) after the user
+reaches the configured number of incorrect attempts.
+
+
+The TOE validates passwords by providing them to Androidโs Gatekeeper (which runs in the Trusted
+Execution Environment), and if the presented password fails to validate, the TOE increments the failed
+
+
+82 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+attempt counter before displaying a visual error to the user. The TOE validates biometric attempts
+through the biometric service (which runs in the Trusted Execution Environment), and if the presented
+biometric does not match the registered templates, the TOE increments the failed attempt counter
+before displaying a visual error to the user.
+
+
+**MOD_BT_V1.0: FIA_BLT_EXT.1**
+The TOE requires explicit user authorization before it will pair with a remote Bluetooth device. When
+pairing with another device, the TOE requires that the user either confirm that a displayed numeric
+passcode matches between the two devices or that the user enter (or choose) a numeric passcode that
+the peer device generates (or must enter).
+
+
+**MOD_BT_V1.0: FIA_BLT_EXT.2**
+The TOE requires explicit user authorization or user authorization before data transfers over the link.
+When transferring data with another device, the TOE requires that the user must confirm an
+authorization popup displayed allowing data transfer (Obex Object Push) or confirm the user passkey
+displayed numeric passcode matches between the two devices (RFCOMM).
+
+
+**MOD_BT_V1.0: FIA_BLT_EXT.3**
+The TOE tracks active connections and actively ignores connection attempts from Bluetooth device
+addresses for which the TOE already has an active connection.
+
+
+**MOD_BT_V1.0: FIA_BLT_EXT.4**
+The TOEโs Bluetooth host and controller support Bluetooth Secure Simple Pairing and the TOE utilizes
+this pairing method when the remote host also supports it.
+
+
+**MOD_BT_V1.0: FIA_BLT_EXT.6**
+The TOE requires that OPP and MAP profile connections have explicit user authorization before granting
+access to trusted remote devices on a per service basis (as opposed to a per app basis).
+
+
+**MOD_BT_V1.0: FIA_BLT_EXT.7**
+The TOE requires that untrusted devices have explicit user authorization before granting access to
+untrusted remote devices for the OPP Bluetooth profile on a per service basis (as opposed to a per app
+basis).
+
+
+**FIA_MBE_EXT.1**
+**FIA_MBE_EXT.2/Fingerprint**
+**FIA_MBV_EXT.1/BMFPS**
+**FIA_MBV_EXT.1/UDFPS** _**(KMD)**_
+The TOE provides fingerprint biometric authentication. Table 33 shows which biometric subsystems are
+available on each device.
+
+
+
+
+
+
+
+
+
+
+
+
+
+83 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+_**Table 33 - Device biometric sensor**_
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+The TOE provides a mechanism to enroll user biometrics for authentication. The enrollment process
+requires the user to have a password set and to be authenticated successfully prior to being able to start
+the enrollment process.
+
+
+The TSF determines the quality of a sample before using it to enroll or verify a user. The fingerprint
+systems utilize different sensors to capture the data, but the data analysis of the quality is common.
+Fingerprint sample quality is determined using three measures โ completeness, clarity, and minutia.
+
+
+In the evaluated configuration, the maximum number of authentication attempts is 40 before a wipe
+event is triggered. This is broken down into a maximum of 10 biometric attempts and 30 password
+attempts that could be made before a wipe occurs. Using this as the worst-case scenario leads to a
+maximum of 10 biometric attempts that can be made for the System Authentication False Accept Rate
+(SAFAR) calculations. All devices or configurations provide for fewer attempts (both password and
+biometric), and so any resulting SAFAR would be lower than this scenario. The last attempt before a
+wipe must be a password attempt.
+
+
+For a password-only configuration, the SAFAR claim would be 1:1,000,000 when set for 10 attempts. The
+password minimum length is 4 characters and there are 93 possible characters that can be used in the
+password. This is not claimed since this configuration (i.e. no biometric authentication allowed) would
+not require FIA_BMG_EXT.1, but is shown here for the overall SAFAR calculations.
+
+
+
+= 4.010 โ10 [โ7]
+
+
+
+4
+
+๐๐ด๐น๐ด๐
๐๐๐ ๐ ๐ค๐๐๐ = 1 โ(1 โ [1 ] โ93 )
+
+
+
+30
+
+
+
+The False Accept Rate (FAR) for fingerprint is 1:10,000 and the False Reject Rate (FRR) is 3%. The SAFAR
+when a fingerprint is in use is 1:1,000 based on a maximum of 10 attempts of the biometric as noted in
+the worst-case scenario.
+
+๐๐ด๐น๐ด๐
๐๐๐๐๐๐๐๐๐๐๐ก = 1 โ(1 โ10 [โ4] ) [10] = 9.996 โ10 [โ4]
+
+
+For all SAFAR calculations the password is considered a critical factor for all combined factor SAFARany
+calculations as detailed in PP_MDF_V3.3 section G.4. The values are accepted because they are within
+the 1% margin allowed by MOD_BIO_11.
+
+
+For devices which support fingerprint biometrics, SAFARfingerprint can be used for the calculation of a
+worst-case scenario.
+
+
+๐๐ด๐น๐ด๐
๐๐๐ฆโ๐๐๐๐๐๐๐๐๐๐๐ก = 1 โ(1 โ ๐๐ด๐น๐ด๐
๐๐) โ(1 โ ๐๐ด๐น๐ด๐
๐๐๐ ๐ ๐ค๐๐๐)
+
+
+84 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+๐๐ด๐น๐ด๐
๐๐๐ฆโ๐๐ = 1.00022 โ10 [โ3]
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+The Knox Platform for Enterprise provides hybrid (multi-factor: password and biometric) authentication.
+When using the hybrid authentication mechanism, the user must enter a correct biometric factor and
+then a correct password in order to successfully unlock the work profile.
+
+
+The SAFAR when a hybrid mechanism is in use is equal to SAFARpassword. The maximum number of
+biometric attempts when using hybrid is 50, but eventually the biometric factor must be entered
+correctly and then one must always enter a correct password. Given the potential maximum 50
+biometric attempts, although that could take a very long time given some imposed delays, that factor is
+discounted in calculating the SAFAR. The password minimum length is 4 characters and there are 93
+possible characters that can be used in the password.
+
+
+๐๐ด๐น๐ด๐
โ๐ฆ๐๐๐๐ = ๐๐ด๐น๐ด๐
๐๐๐ ๐ ๐ค๐๐๐
+
+
+The biometric FAR/FRR values are tested internally by two independent groups using different
+methodologies. The first set of tests are โofflineโ in that a specially configured device is connected to a
+test harness and used to enroll biometric samples for storage. The test harness then uses the samples to
+run through numerous combinations of the samples to determine FAR/FRR results that are used to tune
+the algorithms controlling the biometric system. Once testing is complete a second set of tests are
+performed in an โonlineโ manner where the testing is done with users directly testing on a live device.
+
+
+All devices with different hardware combinations that could affect the biometric subsystem are tested.
+For example, both the Exynos and Qualcomm versions of the mobile devices are tested individually since
+the TrustZone components in each device are different. These tests are integrated into the production
+process and so are repeated continually during the development process.
+
+
+**MOD_WLANC_V1.0: FIA_PAE_EXT.1**
+The TOE can join WPA2-802.1X (802.11i) and WPA3-Enterprise wireless networks requiring EAP-TLS
+authentication, acting as a client/supplicant (and in that role connect to the 802.11 access point and
+communicate with the 802.1X authentication server).
+
+
+**FIA_PMG_EXT.1**
+The TOE supports user passwords consisting of basic Latin characters (upper and lower case, numbers,
+and the special characters noted in the selection (see section 5.1.4.14)) for authentication to all lock
+screens (see Table 34). On devices with a boot lock screen, the TOE uses the same configuration for both
+the boot and device lock screens (i.e. there is one setting that applies to both). The TOE can support a
+minimum password length of as few as four (4) characters and a maximum of no more than sixteen (16)
+characters. The TOE defaults to requiring passwords to have a minimum of four characters that contain
+at least one letter and one number. An MDM application can change these defaults and impose
+password restrictions (like quality, specify another minimum length, the minimum number of letters,
+numeric characters, lower case letters, upper case letters, symbols, and non-letters).
+
+
+**FIA_TRT_EXT.1**
+The TOE allows users to authenticate through external ports (either a USB keyboard or a Bluetooth
+keyboard paired in advance of the login attempt). If not using an external keyboard, a user must
+authenticate through the standard User Interface (using the TOE touchscreen). The TOE limits the
+number of authentication attempts through the UI to no more than five attempts within 30 seconds
+(irrespective of what keyboard the operator uses). Thus if the current [the n [th] ] and prior four
+authentication attempts have failed, and the n-4 [th] attempt was less than 30 second ago, the TOE will
+prevent any further authentication attempts until 30 seconds has elapsed. Note as well that the TOE will
+
+
+85 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+wipe itself when it reaches the maximum number of unsuccessful authentication attempts (as described
+in FIA_AFL_EXT.1 above).
+
+
+**FIA_UAU.5**
+The TOE allows the following authentication methods at the different lock screens in CC mode. The
+available biometrics are dependent on the lock screen being used, MDM configuration and enrolled
+templates. Table 34 shows which authentication methods are available at each lock screen.
+
+
+_**Table 34 - Allowed Lock Screen Authentication Methods**_
+
+
+The TOE prohibits other authentication mechanisms such as pattern or swipe. Use of Smart Lock
+mechanisms (on-body detection, trusted places, trusted devices, trusted face, and trusted voice) and
+PIN can be blocked through management controls. Upon restart or power-up the user can only use a
+password for authentication at the first lock screen. Once past this initial authentication screen the user
+is able to use one of the configured methods at the device lock screen to login and the work profile lock
+screen.
+
+
+**FIA_UAU.6/CREDENTIAL**
+**FIA_UAU.6/LOCKED**
+
+
+The TOE requires the user to enter their password or supply their biometric in order to unlock the TOE.
+Additionally, the TOE requires the user to confirm their current password when accessing the โSettings>Lock screen and AOD->Screen lock and biometricsโ menu in the TOEโs user interface. The TOE can
+disable Smart Lock through management controls. Only after entering their current user password can
+the user then elect to change their password.
+
+
+**FIA_UAU.7**
+The TOEโs two lock screens (device lock screen, and work profile lock screen), by default, briefly display
+the most recently entered password character and then obscures the character by replacing the
+displayed character with a dot symbol. The user can configure the TOEโs behavior for the device lock
+screen so that it does not briefly display the last typed character; however, the TOE always briefly
+displays the last entered character for the work profile lock screen. Additionally, the TOEโs device lock
+screen does not provide any feedback other than a notification of a failed biometric (fingerprint)
+authentication attempt (โnot recognizedโ). Similarly, the TOEโs work profile lock screen, when
+configured for hybrid authentication, displays only an indication (โno matchโ) of a failed biometric
+attempt.
+
+
+**FIA_UAU_EXT.1**
+The TOE's Key Hierarchy requires the user's password in order to derive the sHEK in order to decrypt
+other KEKs and DEKs. Thus, until it has the user's password, the TOE cannot decrypt the DEK utilized by
+FBE to decrypt protected data.
+
+
+**FIA_UAU_EXT.2**
+The TOE, when configured to require user authentication (as is the case in CC mode), allows only those
+actions described in section 5.1.4.21. Beyond those actions, a user cannot perform any other actions
+other than observing notifications displayed on the lock screen until after successfully authenticating.
+
+
+The Galaxy Tab S6 devices do not support Edge applications, and are not available on these devices.
+
+
+86 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+**FIA_X509_EXT.1**
+**MOD_WLANC_V1.0: FIA_X509_EXT.1/WLAN**
+The TOE checks the validity of all imported CA certificates by checking for the presence of the
+basicConstraints extension and that the CA flag is set to TRUE as the TOE imports the certificate into the
+TOEโs Trust Anchor Database. If the TOE detects the absence of either the extension or flag, the TOE will
+import the certificate as a user public key and add it to the keystore (not the Trust Anchor Database).
+The TOE also checks for the presence of the basicConstraints extension and CA flag in each CA certificate
+presented in a peer serverโs certificate chain. Similarly, the TOE verifies the extendedKeyUsage Server
+Authentication purpose during certificate validation. The TOEโs certificate validation algorithm examines
+each certificate in the path (starting with the peerโs certificate) and first checks for validity of that
+certificate (e.g., has the certificate expired? or is it not yet valid? whether the certificate contains the
+appropriate X.509 extensions [e.g., the CA flag in the basic constraints extension for a CA certificate, or
+that a server certificate contains the Server Authentication purpose in the extendedKeyUsage field]),
+then verifies each certificate in the chain (applying the same rules as above, but also ensuring that the
+Issuer of each certificate matches the Subject in the next rung โupโ in the chain and that the chain ends
+in a self-signed certificate present in either the TOEโs trusted anchor database or matches a specified
+Root CA), and finally the TOE performs revocation checking for all certificates in the chain.
+
+
+**FIA_X509_EXT.2**
+**MOD_WLANC_V1.0: FIA_X509_EXT.2/WLAN**
+**MOD_WLANC_V1.0: FIA_X509_EXT.6/WLAN**
+The TOE uses X.509v3 certificates as part of EAP-TLS, TLS, HTTPS and IPsec authentication. The TOE
+comes with a built-in set of default Trusted Credentials (Android's set of trusted CA certificates). While
+the user cannot remove any of the built-in default CA certificates, the user can disable any of those
+certificates through the user interface so that certificates issued by disabled CAโs cannot validate
+successfully. In addition, a user can import a new trusted CA certificate into the Keystore or an
+administrator can install a new certificate through an MDM.
+
+
+The TOE does not establish TLS or HTTPS connections itself (beyond EAP-TLS used for WPA3/WPA2 Wi-Fi
+connections), but provides a series of APIs that mobile applications can use to check the validity of a
+peer certificate. When establishing an EAP-TLS connection, the TOE does not check for certificate
+revocation as the revocation servers are not available until after the EAP-TLS connection is established.
+The mobile application, after correctly using the specified APIs, can be assured as to the validity of the
+peer certificate and will not establish the trusted connection if the peer certificate cannot be verified
+(including validity, certification path, and revocation [through CRL and OCSP]).
+
+
+The VPN requires that for each VPN profile, the user specify the client certificate the TOE will use (the
+certificate must have been previously imported into the keystore) and specify the CA certificate to which
+the serverโs certificate must chain. The VPN thus uses the specified certificate when attempting to
+establish that VPN connection. When establishing a connection to a VPN server, the VPN first compares
+the Identification (ID) Payload received from the server against the certificate sent by the server, and if
+the DN of the certificate does not match the ID, then the TOE does not establish the connection.
+
+
+The TOE supports both CRL and OCSP configurations for revocation checking. Only one of these will be
+used at a time (even if both are configured). OCSP takes precedence over CRL if a certificate provides
+information for checking both. The process of checking the revocation status of a certificate depends on
+the configuration on the device set by the admin.
+
+
+If OCSP is configured (and if the Authority Information Access, AIA, extension is present), OCSP will be
+used to check the status. If the certificate lacks AIA, or if OCSP is not configured on the device the TOE
+
+
+87 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+attempts to determine revocation status using CRLs, if the certificate includes a CRL Distribution Point
+(CDP). If the TOE cannot establish a connection with the server acting as the CDP or OCSP server, or does
+not receive a positive confirmation from the OCSP server, the TOE will deem the serverโs certificate as
+invalid and not establish a TLS connection with the server. Note that the VPN only checks OCSP for
+revocation (if it is configured on the device).
+
+
+**FIA_X509_EXT.3**
+The TOEโs Android operating system provides applications the java.security.cert.CertPathValidator API
+Class of methods for validating certificates and certification paths (certificate chains establishing a trust
+chain from a certificate to a trust anchor). This class is also recommended to be used by third-party
+Android developers for certificate validation. However, TrustedCertificateStore must be used to chain
+certificates to the Android System Trust Anchor Database (anchors should be retrieved and provided to
+PKIXParameters used by CertPathValidator). The available APIs may be found here:
+
+
+[http://developer.android.com/reference/java/security/cert/package-summary.html](http://developer.android.com/reference/java/security/cert/package-summary.html)
+
+### 6.5 Security Management
+
+
+**FMT_MOF_EXT.1**
+**FMT_SMF.1**
+The TOE provides the management functions described in Table 8 - Security Management Functions.
+The table includes annotations describing the roles that have access to each service and how to access
+the service. The TOE enforces administrative configured restrictions by rejecting user configuration
+(through the UI) when attempted. It is worth noting that the TOEโs ability to specify authorized
+application repositories takes the form of allowing enterprise applications (i.e., restricting applications
+to only those applications installed by an MDM Agent).
+
+
+**MOD_BT_CLI_V1.0: FMT_SMF_EXT.1/BT**
+The TOE provides the management functions described in Table 9 - Bluetooth Security Management
+Functions. The table includes annotations describing the roles that have access to each service and how
+to access the service. The TOE enforces administrative configured restrictions by rejecting user
+configuration (through the UI) when attempted.
+
+
+Wi-Fi Direct can be blocked to prevent Bluetooth High Speed access between devices and NFC access
+can be blocked to prevent out of band pairing.
+
+
+**MOD_WLANC_V1.0: FMT_SMF_EXT.1/WLAN**
+The TOE provides the management functions described in Table 10 - WLAN Security Management
+Functions. The table includes annotations describing the roles that have access to each service and how
+to access the service. The TOE enforces administrative configured restrictions by rejecting user
+configuration (through the UI) when attempted.
+
+
+**MOD_VPNC_V2.4: FMT_SMF.1/VPN**
+The TOE provides the management functions described in Table 11 - VPN Security Management
+Functions. In addition, the VPN Gateway, acting as administrator, can specify the IKE algorithms,
+protocols and authentication techniques, and the crypto period for session keys.
+
+
+The TOE provides users the ability to specify an X.509v3 certificate (previously loaded into the TOE
+Platformโs keystore) for the TOE to use to authenticate to the VPN gateway during IPsec peer
+authentication as well as an X.509v3 certificate to use as the CA certificate.
+
+
+88 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+**FMT_SMF_EXT.2**
+A user can unenroll an MDM agent from the device in one of two ways. First, a user can revoke the
+MDM agentโs administrative privileges through the Settings app (Settings->Security and privacy->More
+security settings->Device admin apps) and then uninstall the agent. This method assumes that the MDM
+agent does block the user from revoking the agentโs administrator privileges. When unenrolled in this
+fashion, the device will remove the work profile, the work profileโs applications and data. In effect, this
+translates to the selections of wiping all sensitive data (all work profile data), removing all Enterprise
+applications (all work profile applications), removing all device-stored Enterprise application data (all
+work profile application data), and removing Enterprise secondary authentication data (Knox password
+and/or fingerprint).
+
+
+In the case where an MDM agent blocks the user from revoking the agentโs administrative privileges, a
+user can only unenroll by wiping the entire device. By doing this, the user causes the device to wipe all
+protected data (wiping all data, including both the userโs protected data and any Enterprise/work profile
+data) as well as remove MDM policies and disabling CC mode (as the device returns to factory defaults).
+
+
+**FMT_SMF_EXT.3**
+The TOE provides the user with the ability to see all apps installed on the device that have administrative
+capabilities. Each app listing also shows the status of the app privileges for administration (enabled or
+disabled) and the permissions the app has on the device.
+
+### 6.6 Protection of the TSF
+
+
+**FPT_AEX_EXT.1**
+The Linux kernel of the TOEโs Android operating system provides address space layout randomization
+utilizing a non-cryptographic kernel random function to provide 8 unpredictable bits to the base address
+of any user-space memory mapping. The random function, though not cryptographic, ensures that one
+cannot predict the value of the bits.
+
+
+**FPT_AEX_EXT.2**
+**FPT_AEX_EXT.6**
+The TOE's Android 15 operating system utilizes 6.6/6.1/5.15/5.10 Linux kernels, whose memory
+management unit (MMU) enforces read, write, and execute permissions on all pages of virtual memory
+and ensures that write and execute permissions are not simultaneously granted on all memory
+(exceptions are only made for Dalvik JIT compilation). The Android operating system sets the ARM
+eXecute Never (XN) bit on memory pages and the MMU circuitry of the TOEโs ARMv8 Application
+Processor enforces the XN bits. From Androidโs security documentation
+[(https://source.android.com/security/), Android supports โHardware-based No eXecute (NX) to prevent](https://source.android.com/security/)
+code execution on the stack and heapโ. Section D.5 of the ARM v8 Architecture Reference Manual
+contains additional details about the MMU of ARM-based processors:
+[http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.f/index.html.](http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.f/index.html)
+
+
+**FPT_AEX_EXT.3**
+The TOE's Android operating system provides explicit mechanisms to prevent stack buffer overruns
+(enabling -fstack-protector) in addition to taking advantage of hardware-based No eXecute to prevent
+code execution on the stack and heap. Samsung requires and applies these protections to all TSF
+executable binaries and libraries.
+
+
+**FPT_AEX_EXT.4**
+
+
+89 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+The TOE protects itself from modification by untrusted subjects using a variety of methods. The first
+protection employed by the TOE is a Secure Boot process that uses cryptographic signatures to ensure
+the authenticity and integrity of the bootloader and kernels using data fused into the device processor.
+
+
+The TOEโs Secure Boot process employs a series of public keys to form a chain of trust that operates as
+follows. The Application Processor (AP) contains the hash of the Secure Boot Public Key (a key
+embedded in the end of the signed bootloader image), and upon verifying the SBPK attached to the
+bootloader produces the expected hash, the AP uses this public key to verify the signature of the
+bootloader image, to ensure its integrity and authenticity before transitioning execution to the
+bootloader. The bootloader, in turn, contains the Image Signing Public Key (ISPK), which the bootloader
+will use to verify the signature on either kernel image (primary kernel image or recovery kernel image).
+The signing key type and hash type used are listed in Table 35 - Secure Boot Public Keys.
+
+
+_**Table 35 - Secure Boot Public Keys**_
+
+
+Note that when configured for Common Criteria mode, the TOE only accepts updates to the TOE via
+FOTA; however, when not configured for CC mode, the TOE allows updates through the bootloaderโs
+ODIN mode. The primary kernel includes an embedded FOTA Public Key, which the TOE uses to verify
+the authenticity and integrity of FOTA update signatures (which contain a PKCS 2.1 PSS RSA 2048 w/
+SHA-256 signature).
+
+
+The TOE protects access to the REK and derived HEK to only trusted applications [8] within the TEE
+(TrustZone). The TOE key manager includes a TEE module that utilizes the HEK to protect all other keys
+in the key hierarchy. All TEE applications are cryptographically signed, and when invoked at runtime (at
+the behest of an untrusted application), the TEE will only load the trusted application after successfully
+verifying its cryptographic signature. Furthermore, the device encryption library checks the integrity of
+the system by checking the result from both Secure Boot/SecurityManager and from the Integrity Check
+Daemon before servicing any requests. Without this TEE application, no keys within the TOE (including
+keys for ScreenLock, the keystore, and user data) can be successfully decrypted, and thus are useless.
+
+
+The TOE protects biometric data by separating it from the Android operating system. The biometric
+sensor is tied to the TEE such that it cannot be accessed directly from Android but can only be done
+through the biometric software inside the TEE. All biometric data is maintained within the TEE such that
+Android is only able to know the result of a biometric process (such as enrollment or verification), and
+not any of the data used in that process itself.
+
+
+The third protection is the TOEโs internal SecurityManager watchdog service. The SecurityManager
+manages the CC mode of the TOE by looking for unsigned kernels or failures from other, noncryptographic checks on system integrity, and upon detection of a failure in either, disables the CC mode
+and notifies the TEE application. The TEE application then locks itself, again rendering all TOE keys
+useless.
+
+
+Finally, the TOEโs Android OS provides โsandboxingโ that ensures each non-system mobile application
+executes with the file permissions of a unique Linux user ID in a different virtual memory space. This
+ensures that applications cannot access each otherโs memory space (it is possible for two processes to
+
+
+8 A TrustZone application is a trusted application that executes in a hardware-isolated domain.
+
+
+90 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+utilize shared memory, but not directly access the memory of another application) or files and cannot
+access the memory space or files of system-level applications.
+
+
+**FPT_AEX_EXT.5**
+The TOE provides Kernel Address Space Layout Randomization to ensure that the base address of
+kernel-space memory mappings consist of six (6) unpredictable bits. This ensures that at each boot, the
+location of kernel data structures including the core kernel begins at a random physical address,
+mapping the core kernel at a random virtual address in the vmalloc area, loading kernel modules at a
+random virtual address in the vmalloc area, and mapping system memory at a random virtual address in
+the linear area.
+
+
+**FPT_BBD_EXT.1**
+The TOEโs hardware and software architecture ensures separation of the application processor (AP)
+from the baseband or communications processor (CP). While the AP and CP are part of the same SoC,
+they are separate physical components within the SoC with no shared components between them (such
+as memory) and communicate via a non-shared bus (i.e. no other chips can communicate via this bus).
+From a software perspective, the AP and CP communicate logically through the Android Radio Interface
+Layer (RIL) daemon. This daemon, which executes on the AP, coordinates all communication between
+the AP and CP. It makes requests of the CP and accepts the response from the CP; however, the RIL
+daemon does not provide any reciprocal mechanism for the CP to make requests of the AP. Because the
+mobile architecture provides only the RIL daemon interface, the CP has no method to access the
+resources of the software executing on the AP.
+
+
+**MOD_CPP_BIO_V1.1:FPT_BDP_EXT.1 (KMD)**
+The complete biometric authentication process happens inside the TEE (including image capture, all
+processing and match determination). All software in the biometric system is inside the TEE boundary,
+while the sensors are accessible from within Android. The TEE handles calls for authentication made
+from Android with only the success or failure of the match provided back to Android (and when
+applicable, to the calling app). The image taken by the capture sensor is processed by the biometric
+service to check the enrolled templates for a match to the captured image.
+
+
+**FPT_JTA_EXT.1**
+The TOE prevents access to its processorโs JTAG interface by only enabling JTAG when the TOE has a
+special image written to its bootloader/TEE partitions. That special image must be signed by the
+appropriate key (corresponding to the public key that has its SHA-256 hash programmed into the
+processorโs fuses).
+
+
+**FPT_KST_EXT.1** _**(KMD)**_
+The TOE does not store any plaintext key material in its internal Flash; instead, the TOE does not store
+any plaintext key or biometrics material in its internal Flash; instead, the TOE encrypts all keys and
+biometric data before storing them. This ensures that irrespective of how the TOE powers down (e.g., a
+user commands the TOE to power down, the TOE reboots itself, or battery is removed), all keys and
+biometric data stored in internal Flash are wrapped with a KEK. Please refer to section 6.2 for further
+information (including the KEK used) regarding the encryption of keys stored in the internal Flash. As the
+TOE encrypts all keys stored in Flash, upon boot-up, the TOE must first decrypt and utilize keys. Note as
+well that the TOE does not use a userโs biometric fingerprint to encrypt/protect key material. Rather the
+TOE always requires the user enter his or her password after a reboot (in order to derive the necessary
+keys to decrypt the user data partition and other keys in the key hierarchy).
+
+
+**FPT_KST_EXT.2** _**(KMD)**_
+
+
+91 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+The TOE utilizes a cryptographic library consisting of an implementation of BoringSSL, the Kernel Crypto
+module, the SCrypto module, and the following system-level executables that utilize KEKs: fscrypt (on
+devices with FBE), eCryptfs, wpa_supplicant, and the keystore.
+
+
+The TOE ensures that plaintext key material is not exported by not allowing the REK to be exported and
+by ensuring that only authenticated entities can request utilization of the REK. Furthermore, the TOE
+only allows the system-level executables access to plaintext DEK values needed for their operation. The
+TSF software (the system-level executables) protects those plaintext DEK values in memory both by not
+providing any access to these values and by clearing them when no longer needed (in compliance with
+FCS_CKM_EXT.4). Note again that the TOE does not use the userโs biometric fingerprint to
+encrypt/protect key material (and instead only relies upon the userโs password).
+
+
+The TOE also ensures that biometric data used for enrolling and authenticating users cannot be
+exported. During authentication or enrollment, the calling program (the TSF or an app) is able to request
+biometric actions, but the data resulting from that action is not provided back to the calling program.
+The calling program only receives a notice of success of failure about the process.
+
+
+**FPT_KST_EXT.3** _**(KMD)**_
+The TOE does not provide any way to export plaintext DEKs or KEKs (including all keys stored in the
+keystore) as the TOE chains all KEKs to the HEK/REK.
+
+
+**FPT_NOT_EXT.1**
+When the TOE encounters a self-test failure or when the TOE software integrity verification fails, the
+TOE transitions to a non-operational mode. The user may attempt to power-cycle the TOE to see if the
+failure condition persists, and if it does persist, the user may attempt to boot to the recovery
+mode/kernel to wipe data and perform a factory reset in order to recover the device.
+
+
+**MOD_CPP_BIO_V1.1:FPT_PBT_EXT.1 (KMD)**
+
+
+The TOE requires the user to enter their password to enroll, re-enroll or unenroll any biometric
+templates. When the user attempts biometric authentication to the TOE, the biometric sensor takes an
+image of the presented biometric for comparison to the enrolled templates. The biometric system
+compares the captured image to all the stored templates on the device to determine if there is a match
+
+
+**FPT_STM.1**
+The TOE requires time for the Package Manager, FOTA image verifier, TLS certificate validation,
+wpa_supplicant, audit system and keystore applications. These TOE components obtain time from the
+TOE using system API calls [e.g., time() or gettimeofday()]. An application cannot modify the system time
+as mobile applications need the Android โSET_TIMEโ permission to do so. Likewise, only a process with
+system privileges can directly modify the system time using system-level APIs. The TOE uses the Cellular
+Carrier time (obtained through the Carrierโs network timeserver) as a trusted source; however, the user
+can also manually set the time through the TOEโs user interface.
+
+
+**FPT_TST_EXT.1**
+The TOE performs known answer power on self-tests (POST) on its cryptographic algorithms to ensure
+that they are functioning correctly. The kernel itself performs known answer tests on its cryptographic
+algorithms to ensure they are working correctly and the SecurityManager service invokes the self-tests
+of BoringSSL at start-up to ensure that those cryptographic algorithms are working correctly. The
+Chipset hardware performs a power-up self-test to ensure that its AES implementation is working, as
+does the TEE SCrypto cryptographic library. Should any of the tests fail, the TOE will reboot to see if that
+will clear the error.
+
+
+92 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+_**Table 36 - Power-up Cryptographic Algorithm Self-Tests**_
+
+
+**MOD_WLANC_V1.0: FPT_TST_EXT.1/WLAN**
+**MOD_VPNC_V2.4: FPT_TST_EXT.1/VPN**
+The TOE platform performs the previously mentioned self-tests to ensure the integrity of the WLAN
+client (wpa_supplicant) and the VPN client (libcharon.so) in addition to the cryptographic libraries used
+by the clients.
+
+
+**FPT_TST_EXT.2/PREKERNEL**
+**FPT_TST_EXT.2/POSTKERNEL**
+The TOE ensures a secure boot process in which the TOE verifies the digital signature of the bootloader
+software for the Application Processor (using a public key whose hash resides in the processorโs internal
+fuses) before transferring control. The bootloader, in turn, verifies the signature of the Linux kernel
+(either the primary or the recovery kernel) it loads.
+
+
+Once the kernel has been loaded, the TOE uses dm-verity in EIO mode to protect the integrity of the
+system partition. After verifying the digital signature of the dm-verity hash tree (using the same public
+key that verifies the kernel image), the TOE will reject the loading of file system blocks where the
+integrity does not match, and return an I/O error (as if the block were unreadable).
+
+
+**FPT_TUD_EXT.1**
+The TOEโs user interface provides a method to query the current version of the TOE software/firmware
+(Android version, baseband version, kernel version, build number, and security software version) and
+hardware (model and version). Additionally, the TOE provides users the ability to review the currently
+installed apps (including 3 [rd] party โbuilt-inโ applications) and their version.
+
+
+**FPT_TUD_EXT.2** _**(KMD)**_
+When in CC mode, the TOE verifies all updates to the TOE software using a public key (FOTA public key)
+chaining ultimately to the Secure Boot Public Key (SBPK), a hardware protected key whose SHA-256 hash
+resides inside the application processor (note that when not in CC mode, the TOE allows updates to the
+TOE software through the Download mode of the bootloader). After verifying an updateโs FOTA
+signature, the TOE will then install those updates to the TOE.
+
+
+The application processing verifies the bootloaderโs authenticity and integrity (thus tying the bootloader
+and subsequent stages to a hardware root of trust: the SHA-256 hash of the SBPK, which cannot be
+reprogrammed after the โwrite-enableโ fuse, has been blown).
+
+
+The Android OS on the TOE requires that all applications bear a valid signature before Android will install
+the application.
+
+
+93 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+**FPT_TUD_EXT.3**
+The TOE requires that all applications be signed before they can be installed. Android uses a file format
+called APK to package the application installation. The contents of the APK are hashed and then signed,
+with the resulting APK Signing Block then inserted into the APK or saved as a separate file (depending on
+the APK Signature Scheme in use).
+
+
+Once an application has been downloaded, the Signing Block information is used to verify the software
+before installation. The app contents are verified against the hash values that have been calculated and
+signed before approving the installation.
+
+
+In addition to the hash check, there are several rules related to the contents of the Signing Block which
+[can be found here: https://source.android.com/security/apksigning/v3.](https://source.android.com/security/apksigning/v3)
+
+
+**FPT_TUD_EXT.6** _**(KMD)**_
+The TOE maintains a monotonic version counter for the TOE software. Before a new update can be
+installed, the version of the new software is verified to the version counter. If the new image is older
+than the current version, the update will be rejected and not installed; only version numbers that are
+equal to or greater than the currently set number can be installed on the device.
+
+
+**ALC_TSU_EXT**
+Samsung utilizes industry best practices to ensure their devices are patched to mitigate security flaws.
+Samsung provides a web portal for reporting potential security issues
+[(https://security.samsungmobile.com/securityReporting.smsb) with instructions about how to securely](https://security.samsungmobile.com/securityReporting.smsb)
+contact and communicate with Samsung. As an Android OEM, also works with Google on reported
+[Android issues (https://source.android.com/source/report-bugs.html) to ensure customer devices are](https://source.android.com/source/report-bugs.html)
+secure.
+
+
+Samsung will create updates and patches to resolve reported issues as quickly as possible, at which
+point the update is provided to the wireless carriers. The delivery time for resolving an issue depends on
+the severity, and can be as rapid as a few days before the carrier handoff for high priority cases. The
+wireless carriers perform additional tests to ensure the updates will not adversely impact their networks
+and then plan device rollouts once that testing is complete. Carrier updates usually take at least two
+weeks to as much as two months (depending on the type and severity of the update) to be rolled out to
+customers. However, the Carriers also release monthly Maintenance Releases in order to address
+security-critical issues, and Samsung itself maintains a security blog
+[(https://security.samsungmobile.com) in order to disseminate information directly to the public.](https://security.samsungmobile.com/)
+
+
+Samsung communicates with the reporting party to inform them of the status of the reported issue.
+Further information about updates is handled through the carrier release notes. Issues reported to Google
+directly are handled through Googleโs notification processes.
+
+### 6.7 TOE Access
+
+
+**FTA_SSL_EXT.1**
+The TOE transitions to its locked state either immediately after a user initiates a lock by pressing the
+power button or after a configurable period of inactivity. As part of that transition, the TOE will display a
+lock screen to obscure the previous contents; however, the TOEโs lock screen still allows a user to
+perform the functions listed in section 5.1.4.21 before authenticating. However, without authenticating
+first, a user cannot perform any related actions based upon these notifications (for example, they
+cannot respond to emails, calendar appointment requests, or text messages) other than answering an
+incoming phone call.
+
+
+94 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+On power up the TOE boots to the device lock screen. On the first boot, the user can only make
+emergency calls, receive calls, enter their password or see notifications from apps that do not require
+user authentication (apps that have requested the use of Device Encrypted `storage during installation).
+
+
+**FTA_TAB.1**
+The TOE can be configured by an administrator to display a message on the lock screen using an MDM.
+
+
+**MOD_WLANC_V1.0: FTA_WSE_EXT.1**
+The TOE allows an administrator to specify (using an MDM) a list of wireless networks (SSIDs) to which
+the user may direct the TOE to connect. When not enrolled with an MDM, the TOE allows the user to
+control to which wireless networks the TOE should connect, but does not provide an explicit list of such
+networks, rather the user may scan for available wireless network (or directly enter a specific wireless
+network), and then connect. Once a user has connected to a wireless network, the TOE will
+automatically reconnect to that network when in range and the user has enabled the TOEโs Wi-Fi radio.
+
+### 6.8 Trusted Path/Channels
+
+
+**MOD_BT_V1.0: FTP_BLT_EXT.1**
+**MOD_BT_V1.0: FTP_BLT_EXT.3/BR**
+**MOD_BT_V1.0: FTP_BLT_EXT.3/LE**
+The TOE provides support for both Bluetooth BR/EDR and Bluetooth LE connections. The TSF ensures
+that all connections are encrypted by default using keys of at least 128-bits (regardless of the type of
+connection).
+
+
+**MOD_BT_V1.0: FTP_BLT_EXT.2**
+Since the TOE requires an encrypted connection between itself and another Bluetooth device, if the
+remote device stops encryption, the TSF will force the termination of the connection. A new connection
+should re-establish the encrypted channel (and if not, the connection will not be successful).
+
+
+**FTP_ITC_EXT.1**
+**MOD_WLANC_V1.0: FTP_ITC.1/WLAN**
+The TOE provides secured (encrypted and mutually authenticated) communication channels between
+itself and other trusted IT products through the use of 802.11-2012, 802.1X, and EAP-TLS, TLS, HTTPS
+and IPsec. The TOE permits itself and applications to initiate communications via the trusted channel,
+and the TOE initiates communication via the trusted channel for connection to a wireless access point.
+The TOE provides access to TLS and HTTPS via published APIs that are accessible to any application that
+needs an encrypted end-to-end trusted channel. The TOE also meets the PP-Module for Virtual Private
+Network (VPN) Clients.
+
+### 6.9 Work Profile Functionality
+
+
+This section specifically enumerates the functionality specifically provided when a work profile has been
+created.
+
+
+**FDP_ACF_EXT.1.2**
+The TOE, through a combination of Androidโs multi-user capabilities and Security Enhancements (SE) for
+Android, provides the ability to create an isolated profile within the device. Within a work profile a
+group of applications can be installed, and access to those applications is then restricted to usage solely
+within the work profile. The work profile boundary restricts the ability of sharing data such that
+applications outside the work profile cannot see, share or even copy data to those inside the work
+profile and vice versa. Exceptions to the boundary (such as allowing a copy operation) must be
+
+
+95 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+configured by the administrator via policy. Furthermore, the work profile boundary policy can control
+access to hardware features, such as the camera or microphone, and restrict the ability of applications
+within the work profile to access those services.
+
+
+**FIA_AFL_EXT.1**
+The work profile maintains, in flash, the number of failed logins since the last successful login, and upon
+reaching the maximum number of incorrect logins, the work profile performs a full wipe of data
+protected by Knox (i.e. data inside the work profile). An administrator can adjust the number of failed
+logins for the hybrid and password login mechanism from the default of twenty failed logins to a value
+between one and thirty through an MDM.
+
+
+**FIA_UAU_EXT.4** _**(KMD)**_
+The TOE requires a separate password or hybrid authentication for its work profile, thus protecting all
+Enterprise application data and shared resource data. The user must enter either their password or both
+their password and biometric (if the user has configured hybrid authentication and enrolled a biometric)
+in order to access any of the Enterprise application data.
+
+
+**FIA_UAU.5**
+The work profile allows the user to authenticate using a password, or a hybrid method requiring both a
+biometric and the password at the same time. The TOE prohibits other authentication mechanisms, such
+as pattern, PIN, or biometric by themselves.
+
+
+**FIA_UAU.6/LOCKED**
+The work profile requires the user to enter their password in order to unlock the work profile.
+Additionally, the work profile requires the user to confirm their current password when accessing the
+โKnox Settings -> Knox unlock methodโ menu in the work profile user interface. Only after entering their
+current user password can the user then elect to change their password.
+
+
+**FIA_UAU.7**
+The work profile allows the user to enter the user's password from the lock screen. The work profile will,
+by default display the most recently entered character of the password briefly or until the user enters
+the next character in the password, at which point the work profile obscures the character by replacing
+the character with a dot symbol.
+
+
+The work profile can also be configured for hybrid authentication. In this case the user is prompted to
+first scan their biometric successfully before being prompted to enter their password. If the biometric
+attempt is unsuccessful, the user is prompted again to enter the biometric. To successfully login, both a
+valid biometric and the correct password must be entered.
+
+
+**FMT_MOF_EXT.1 &**
+**FMT_SMF_EXT.1**
+The work profile grants the admin additional controls over the work profile beyond those available to
+the device as a whole. The primary additional control is over sharing data to and from the work profile.
+
+
+The control over the camera and microphone within the work profile only affects access to those
+resources inside the work profile, not outside the work profile. If either of these is disabled outside the
+work profile then they will not be available within the work profile, even if they are enabled.
+
+
+In general, the management functions for the work profile are the same as those of the device as a
+whole. Specific differences of the impact of a work profile function are noted in Table 8 - Security
+Management Functions.
+
+
+**FTA_SSL_EXT.1**
+
+
+96 of 96
+
+
+Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 15 โ
+Spring Security Target
+
+
+
+Version: 0.4
+Date: 07/01/2025
+
+
+
+The work profile transitions to its locked state either immediately after a user initiates a lock by pressing
+the work profile lock button from the notification bar or after a configurable period of inactivity, and as
+part of that transition, the work profile will display a lock screen to obscure the previous contents. When
+the work profile is locked, it can still display calendar appointments and other notifications allowed by
+the administrator to be shown outside the work profile (in the notification area). However, without
+authenticating first to the work profile, a user cannot perform any related actions based upon these
+work profile notifications (they cannot respond to emails, calendar appointments, or text messages).
+
+
+The work profile timeout is independent of the TOE timeout and as such can be set to different values.
+
+
+97 of 96
+
+
+
diff --git a/niap-cc/sdp-file-encrypt/doc/security_traceability.md b/niap-cc/sdp-file-encrypt/doc/security_traceability.md
new file mode 100644
index 0000000..0598348
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/doc/security_traceability.md
@@ -0,0 +1,29 @@
+# Security Traceability Matrix (STM)
+
+This document maps the Security Functional Requirements (SFRs) from the Protection Profile (PP_MDF_V3.3) to the specific implementation details within the application source code.
+
+## 1. Traceability Table
+
+| SFR ID | Requirement Name | Implementation Class | Location / Method | Rationale & Evidence |
+| :--- | :--- | :--- | :--- | :--- |
+| **FDP_DAR_EXT.2** | Sensitive Data Encryption | `HybridKeyProvider` | `encrypt()` | **Compliant:** Uses an asymmetric key scheme (ECIES-AEAD-HKDF via Tink) to allow data encryption even when the device is locked (B/F/U states). |
+| **FDP_DAR_EXT.2** | Sensitive Data Encryption | `RawHybridKeyProvider` | `encrypt()` | **Compliant:** Implements JCA-based asymmetric encryption to support data ingestion in the Locked State without requiring private key access. |
+| **FCS_STG_EXT.2** | Encrypted Key Storage | `HybridKeyProvider` | `getAead()` / `AndroidKeysetManager` | **Compliant:** Private keysets are stored in SharedPreferences wrapped by a Master Key held in the Android Keystore. |
+| **FCS_STG_EXT.2** | Encrypted Key Storage | `RawHybridKeyProvider` | `generateAndStoreKeyPairIfNeeded()` | **Compliant:** Private keys are generated and stored directly within the `AndroidKeyStore` provider, ensuring hardware-backed protection. |
+| **FCS_CKM_EXT.4** | Key Destruction (Volatile) | `RawHybridKeyProvider` | `encrypt()`, `decrypt()` / `finally` block | **Compliant:** Explicitly zeroes out (`fill(0)`) DEK, KEK, and Shared Secret byte arrays immediately after use to prevent memory remanence. |
+| **FCS_CKM_EXT.4** | Key Destruction (Storage) | `RawHybridKeyProvider` | `destroy()` | **Compliant:** Invokes `KeyStore.deleteEntry()` and `SharedPreferences.Editor.clear()` to remove persistent key material. |
+| **FIA_UAU_EXT.1** | Auth for Crypto Operation | `HybridKeyProvider` | `createMasterKeyIfNeeded()` | **Compliant:** Configures the Master Key with `.setUnlockedDeviceRequired(true)`, enforcing user authentication for keyset unwrapping. |
+| **FIA_UAU_EXT.1** | Auth for Crypto Operation | `RawHybridKeyProvider` | `generateAndStoreKeyPairIfNeeded()` | **Compliant:** Sets `.setUnlockedDeviceRequired(true)` on the private key, ensuring the OS rejects decryption attempts without user authentication. |
+| **FCS_CKM.2/LOCKED** | Key Establishment (Locked) | `HybridKeyProvider` | `getAead()` / `AndroidKeysetManager` | **Compliant:** Sets Uses standard ECIES-AEAD-HKDF schemes provided by Google Tink, which allow key establishment for encryption while the device is locked. |
+
+## 2. Implementation Notes
+
+### HybridKeyProvider (Tink-based)
+* **Role**: Primary encryption provider using Google Tink library.
+* **Key Management**: Relies on Tink's validated schemes for key establishment.
+* **Memory Safety**: Volatile memory clearing relies on Tink's internal implementation and JVM Garbage Collection.
+
+### RawHybridKeyProvider (JCA-based)
+* **Role**: Alternative implementation for high-assurance memory handling.
+* **Key Management**: Manually composes JCA primitives.
+* **Memory Safety**: **Explicitly implements volatile memory zeroization** to satisfy strict interpretations of FCS_CKM_EXT.4.
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/encryption-lib/build.gradle.kts b/niap-cc/sdp-file-encrypt/encryption-lib/build.gradle.kts
new file mode 100644
index 0000000..375edc2
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/encryption-lib/build.gradle.kts
@@ -0,0 +1,73 @@
+/*
+* Copyright (C) 2026 The Android Open Source Project
+*
+* Licensed under the Apache License, Version 2.0 (the "License");
+* you may not use this file except in compliance with the License.
+* You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing, software
+* distributed under the License is distributed on an "AS IS" BASIS,
+* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+* See the License for the specific language governing permissions and
+* limitations under the License.
+*/
+import java.text.SimpleDateFormat
+import java.util.Date
+
+plugins {
+ id("com.android.library")
+ alias(libs.plugins.kotlin.android)
+}
+
+android {
+ namespace = "com.android.niapsec.encryption"
+ compileSdk = 36
+
+ defaultConfig {
+ minSdk = 28
+ testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
+ }
+
+ buildFeatures.buildConfig = true
+
+ buildTypes {
+ release {
+ isMinifyEnabled = false
+ proguardFiles(
+ getDefaultProguardFile("proguard-android-optimize.txt"),
+ "proguard-rules.pro"
+ )
+ }
+ }
+ compileOptions {
+ sourceCompatibility = JavaVersion.VERSION_11
+ targetCompatibility = JavaVersion.VERSION_11
+ }
+ kotlinOptions {
+ jvmTarget = "11"
+ }
+ defaultConfig {
+ val dateFormat = SimpleDateFormat("yyMMdd")
+ val buildTime = dateFormat.format(Date())
+ buildConfigField("String", "BUILD_DATE", "\"${buildTime}\"")
+ }
+}
+
+configurations.all {
+ resolutionStrategy {
+ force("com.google.crypto.tink:tink-android:1.20.0")
+ force("com.google.crypto.tink:tink-core:1.20.0")
+ }
+}
+
+dependencies {
+ implementation(libs.androidx.core.ktx)
+ implementation("com.google.crypto.tink:tink-android:1.20.0")
+ implementation("org.bouncycastle:bcprov-jdk18on:1.77")
+
+ testImplementation(libs.junit)
+ androidTestImplementation(libs.androidx.junit)
+ androidTestImplementation(libs.androidx.espresso.core)
+}
diff --git a/niap-cc/sdp-file-encrypt/encryption-lib/src/androidTest/java/com/android/niapsec/demo/EncryptionProviderTest.kt b/niap-cc/sdp-file-encrypt/encryption-lib/src/androidTest/java/com/android/niapsec/demo/EncryptionProviderTest.kt
new file mode 100644
index 0000000..6ee8029
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/encryption-lib/src/androidTest/java/com/android/niapsec/demo/EncryptionProviderTest.kt
@@ -0,0 +1,142 @@
+/*
+* Copyright (C) 2026 The Android Open Source Project
+*
+* Licensed under the Apache License, Version 2.0 (the "License");
+* you may not use this file except in compliance with the License.
+* You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing, software
+* distributed under the License is distributed on an "AS IS" BASIS,
+* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+* See the License for the specific language governing permissions and
+* limitations under the License.
+*/
+package com.android.niapsec.demo
+
+import androidx.test.ext.junit.runners.AndroidJUnit4
+import androidx.test.platform.app.InstrumentationRegistry
+import com.android.niapsec.encryption.api.EncryptionManager
+import com.android.niapsec.encryption.api.KeyProviderType
+import org.junit.After
+import org.junit.Assert.assertEquals
+import org.junit.Before
+import org.junit.Test
+import org.junit.runner.RunWith
+import java.io.File
+
+@RunWith(AndroidJUnit4::class)
+class EncryptionProviderTest {
+
+ private val context = InstrumentationRegistry.getInstrumentation().targetContext
+ private val filesToClean = mutableListOf()
+
+ @Before
+ fun setup() {
+ // Ensure we start from a clean state before each test
+ clearAllData()
+ }
+
+ @After
+ fun teardown() {
+ // Clean up all generated keys and files after each test
+ clearAllData()
+ filesToClean.forEach { it.delete() }
+ filesToClean.clear()
+ }
+
+ @Test
+ fun testHybridProvider_EncryptDecrypt_Succeeds() {
+ val manager = createManager(KeyProviderType.HYBRID)
+ val testFile = createTestFile("hybrid_test.txt")
+ val originalText = "This is a hybrid message."
+
+ // Encrypt
+ manager.encryptToFile(testFile).use { it.write(originalText.toByteArray()) }
+
+ // Decrypt
+ val decryptedText = manager.decryptFromFile(testFile).use { it.reader().readText() }
+ assertEquals("Decrypted content should match original", originalText, decryptedText)
+ }
+
+ @Test
+ fun testRawProvider_EncryptDecrypt_Succeeds() {
+ val manager = createManager(KeyProviderType.RAW)
+ val testFile = createTestFile("raw_test.txt")
+ val originalText = "This is a raw message."
+
+ // Encrypt
+ manager.encryptToFile(testFile).use { it.write(originalText.toByteArray()) }
+
+ // Decrypt
+ val decryptedText = manager.decryptFromFile(testFile).use { it.reader().readText() }
+ assertEquals("Decrypted content should match original", originalText, decryptedText)
+ }
+
+ @Test
+ fun testHybridProvider_EncryptDecrypt_TwoFiles_Succeeds() {
+ val manager = createManager(KeyProviderType.HYBRID)
+
+ val testFile1 = createTestFile("hybrid_test_1.txt")
+ val originalText1 = "This is the first hybrid message."
+ manager.encryptToFile(testFile1).use { it.write(originalText1.toByteArray()) }
+
+ val testFile2 = createTestFile("hybrid_test_2.txt")
+ val originalText2 = "This is the second hybrid message."
+ manager.encryptToFile(testFile2).use { it.write(originalText2.toByteArray()) }
+
+ val decryptedText1 = manager.decryptFromFile(testFile1).use { it.reader().readText() }
+ assertEquals("Decrypted content for file 1 should match original", originalText1, decryptedText1)
+
+ val decryptedText2 = manager.decryptFromFile(testFile2).use { it.reader().readText() }
+ assertEquals("Decrypted content for file 2 should match original", originalText2, decryptedText2)
+ }
+
+ @Test
+ fun testRawProvider_EncryptDecrypt_TwoFiles_Succeeds() {
+ val manager = createManager(KeyProviderType.RAW)
+
+ val testFile1 = createTestFile("raw_test_1.txt")
+ val originalText1 = "This is the first raw message."
+ manager.encryptToFile(testFile1).use { it.write(originalText1.toByteArray()) }
+
+ val testFile2 = createTestFile("raw_test_2.txt")
+ val originalText2 = "This is the second raw message."
+ manager.encryptToFile(testFile2).use { it.write(originalText2.toByteArray()) }
+
+ val decryptedText1 = manager.decryptFromFile(testFile1).use { it.reader().readText() }
+ assertEquals("Decrypted content for file 1 should match original", originalText1, decryptedText1)
+
+ val decryptedText2 = manager.decryptFromFile(testFile2).use { it.reader().readText() }
+ assertEquals("Decrypted content for file 2 should match original", originalText2, decryptedText2)
+ }
+
+ private fun createManager(providerType: KeyProviderType): EncryptionManager {
+ val keyUri = "android-keystore://test_key_for_${providerType.name}"
+ return EncryptionManager(
+ context = context,
+ masterKeyUri = keyUri,
+ providerType = providerType,
+ unlockedDeviceRequired = false // Use false for automated tests
+ )
+ }
+
+ private fun createTestFile(filename: String): File {
+ val file = File(context.filesDir, filename)
+ filesToClean.add(file)
+ return file
+ }
+
+ private fun clearAllData() {
+ // A simple way to clear all provider keys and files
+ for (providerType in KeyProviderType.values()) {
+ try {
+ val manager = createManager(providerType)
+ manager.destroy()
+ } catch (e: Exception) {
+ // Ignore errors during cleanup
+ }
+ }
+ }
+}
diff --git a/niap-cc/sdp-file-encrypt/encryption-lib/src/androidTest/java/com/android/niapsec/encryption/EncryptionManagerTest.kt b/niap-cc/sdp-file-encrypt/encryption-lib/src/androidTest/java/com/android/niapsec/encryption/EncryptionManagerTest.kt
new file mode 100644
index 0000000..564c3f1
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/encryption-lib/src/androidTest/java/com/android/niapsec/encryption/EncryptionManagerTest.kt
@@ -0,0 +1,193 @@
+/*
+* Copyright (C) 2026 The Android Open Source Project
+*
+* Licensed under the Apache License, Version 2.0 (the "License");
+* you may not use this file except in compliance with the License.
+* You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing, software
+* distributed under the License is distributed on an "AS IS" BASIS,
+* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+* See the License for the specific language governing permissions and
+* limitations under the License.
+*/
+package com.android.niapsec.encryption
+
+import android.app.KeyguardManager
+import android.content.Context
+import androidx.test.ext.junit.runners.AndroidJUnit4
+import androidx.test.platform.app.InstrumentationRegistry
+import com.android.niapsec.encryption.api.EncryptionManager
+import com.android.niapsec.encryption.api.KeyProviderType
+import org.junit.After
+import org.junit.Assert.assertEquals
+import org.junit.Assert.assertThrows
+import org.junit.Assert.assertTrue
+import org.junit.Assert.fail
+import org.junit.Assume.assumeTrue
+import org.junit.Before
+import org.junit.Test
+import org.junit.runner.RunWith
+import java.io.File
+import java.nio.charset.StandardCharsets
+import java.security.GeneralSecurityException
+import java.util.UUID
+
+@RunWith(AndroidJUnit4::class)
+class EncryptionManagerTest {
+
+ private lateinit var context: Context
+ private lateinit var keyguardManager: KeyguardManager
+ private val managersToDestroy = mutableListOf()
+ private val filesToClean = mutableListOf()
+
+ @Before
+ fun setup() {
+ context = InstrumentationRegistry.getInstrumentation().targetContext
+ keyguardManager = context.getSystemService(Context.KEYGUARD_SERVICE) as KeyguardManager
+ }
+
+ @After
+ fun tearDown() {
+ managersToDestroy.forEach { it.destroy() }
+ managersToDestroy.clear()
+
+ filesToClean.forEach { if (it.exists()) it.delete() }
+ filesToClean.clear()
+ }
+
+ private fun createManager(providerType: KeyProviderType, unlockedDeviceRequired: Boolean = false): EncryptionManager {
+ val masterKeyUri = "android-keystore://test_key_${UUID.randomUUID()}"
+ val manager = EncryptionManager(context, masterKeyUri, providerType, unlockedDeviceRequired)
+ managersToDestroy.add(manager)
+ return manager
+ }
+
+ private fun getTestFile(fileName: String): File {
+ val file = File(context.cacheDir, fileName)
+ filesToClean.add(file)
+ return file
+ }
+
+ /**
+ * Helper to generate a large string of approximately specific size (in bytes).
+ */
+ private fun generateLargeString(sizeInBytes: Int): String {
+ val sb = StringBuilder(sizeInBytes)
+ val chunk = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz" // 62 chars
+
+ while (sb.length < sizeInBytes) {
+ sb.append(chunk)
+ }
+ return sb.substring(0, sizeInBytes)
+ }
+
+ // --- Stream API Tests (StreamingAead) ---
+
+ @Test
+ fun testRawHybridProvider_encryptAndDecryptStream_1MB_works() {
+ // Test StreamingAead with ~1MB of data
+ val encryptionManager = createManager(KeyProviderType.RAW_HYBRID)
+ val testFile = getTestFile("stream_1mb_test.dat")
+
+ // Generate 1MB String (1024 * 1024 bytes)
+ val targetSize = 1024 * 1024
+ val originalContent = generateLargeString(targetSize)
+
+ // Encrypt using Stream API
+ encryptionManager.encryptToFileStream(testFile).use { outputStream ->
+ // Convert to bytes explicitly to ensure size match
+ outputStream.write(originalContent.toByteArray(StandardCharsets.UTF_8))
+ }
+
+ // Verify file was created and has some size (overhead + content)
+ assertTrue("File should exist", testFile.exists())
+ assertTrue("File should be larger than plain content due to IV/AuthTag", testFile.length() > targetSize)
+
+ // Decrypt using Stream API
+ val decryptedContent = encryptionManager.decryptFromFileStream(testFile).use { inputStream ->
+ inputStream.reader(StandardCharsets.UTF_8).readText()
+ }
+
+ assertEquals("Decrypted content length should match", originalContent.length, decryptedContent.length)
+ assertEquals("Decrypted content should match original", originalContent, decryptedContent)
+ }
+
+ @Test
+ fun testRawHybridProvider_encryptFile_deletesOriginalByDefault() {
+ val encryptionManager = createManager(KeyProviderType.RAW_HYBRID)
+ val sourceFile = getTestFile("source_to_delete.txt")
+ val destFile = getTestFile("dest_encrypted.enc")
+
+ val randomText = "Some random text for encryptFile. " + generateLargeString(1000)
+ sourceFile.writeText(randomText)
+
+ // Use the new encryptFile API (default deleteOriginal = true)
+ encryptionManager.encryptFile(sourceFile, destFile)
+
+ assertTrue("Destination file should exist", destFile.exists())
+ assertTrue("Source file should be deleted", !sourceFile.exists())
+
+ val decryptedText = encryptionManager.decryptFromFileStream(destFile).use { it.reader().readText() }
+ assertEquals("Decrypted text should match", randomText, decryptedText)
+ }
+
+ @Test
+ fun testRawHybridProvider_encryptFile_preservesOriginalWhenRequested() {
+ val encryptionManager = createManager(KeyProviderType.RAW_HYBRID)
+ val sourceFile = getTestFile("source_to_keep.txt")
+ val destFile = getTestFile("dest_encrypted_keep.enc")
+
+ val randomText = "Some random text that must be kept. " + generateLargeString(1000)
+ sourceFile.writeText(randomText)
+
+ // Use the new encryptFile API with deleteOriginal = false
+ encryptionManager.encryptFile(sourceFile, destFile, deleteOriginal = false)
+
+ assertTrue("Destination file should exist", destFile.exists())
+ assertTrue("Source file should still exist", sourceFile.exists())
+
+ val decryptedText = encryptionManager.decryptFromFileStream(destFile).use { it.reader().readText() }
+ assertEquals(randomText, decryptedText)
+ }
+
+ @Test
+ fun testRawProvider_encryptStream_throwsUnsupportedOperation() {
+ // RAW provider (and others not updated) should NOT support streaming
+ val encryptionManager = createManager(KeyProviderType.RAW)
+ val testFile = getTestFile("raw_stream_fail_test.dat")
+
+ assertThrows(UnsupportedOperationException::class.java) {
+ encryptionManager.encryptToFileStream(testFile)
+ }
+ }
+
+ // --- Legacy File API Tests (Aead / In-Memory) ---
+
+ // --- String Encryption Tests ---
+
+ @Test
+ fun testStringEncryption_works_rawHybrid() {
+ val encryptionManager = createManager(KeyProviderType.RAW_HYBRID)
+ val originalText = "Hello World! String encryption test with RawHybrid."
+
+ val ciphertext = encryptionManager.encryptToString(originalText)
+ val decryptedText = encryptionManager.decryptFromString(ciphertext)
+
+ assertEquals(originalText, decryptedText)
+ }
+
+ @Test
+ fun testRawHybridProvider_encryptUsesSymmetricWhenUnlocked() {
+ val encryptionManager = createManager(KeyProviderType.RAW_HYBRID)
+ val originalText = "Asserting symmetric magic byte (Solution 1)"
+ val ciphertextBase64 = encryptionManager.encryptToString(originalText)
+
+ val ciphertextBytes = android.util.Base64.decode(ciphertextBase64, android.util.Base64.DEFAULT)
+
+ // Assert first byte is 0x02 (MAGIC_BYTE_SYMMETRIC) after skipping the 4-byte provider header ("EHBR")
+ assertEquals("Ciphertext should start with 0x02 representing symmetric encryption (no fallback)", 0x02.toByte(), ciphertextBytes[4])
+ }
+}
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/encryption-lib/src/androidTest/res/raw/sample_text.txt b/niap-cc/sdp-file-encrypt/encryption-lib/src/androidTest/res/raw/sample_text.txt
new file mode 100644
index 0000000..d64f222
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/encryption-lib/src/androidTest/res/raw/sample_text.txt
@@ -0,0 +1 @@
+This is a sample file from the app's resources.
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/encryption-lib/src/main/AndroidManifest.xml b/niap-cc/sdp-file-encrypt/encryption-lib/src/main/AndroidManifest.xml
new file mode 100644
index 0000000..9a40236
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/encryption-lib/src/main/AndroidManifest.xml
@@ -0,0 +1,3 @@
+
+
+
diff --git a/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/api/EncryptionManager.kt b/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/api/EncryptionManager.kt
new file mode 100644
index 0000000..b703067
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/api/EncryptionManager.kt
@@ -0,0 +1,171 @@
+/*
+* Copyright (C) 2026 The Android Open Source Project
+*
+* Licensed under the Apache License, Version 2.0 (the "License");
+* you may not use this file except in compliance with the License.
+* You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing, software
+* distributed under the License is distributed on an "AS IS" BASIS,
+* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+* See the License for the specific language governing permissions and
+* limitations under the License.
+*/
+package com.android.niapsec.encryption.api
+
+import android.content.Context
+import android.util.Base64
+import android.util.Log
+import com.android.niapsec.encryption.internal.EncryptionProvider
+import com.android.niapsec.encryption.internal.TinkEncryptionProvider
+import com.android.niapsec.encryption.internal.keymanagement.HybridKeyProvider
+import com.android.niapsec.encryption.internal.keymanagement.RawHybridKeyProvider
+import com.android.niapsec.encryption.internal.keymanagement.RawKeyProvider
+import java.io.File
+import java.io.InputStream
+import java.io.OutputStream
+
+/**
+ * Manages encryption and decryption operations for files and strings using a configurable KeyProvider.
+ */
+class EncryptionManager(
+ context: Context,
+ masterKeyUri: String,
+ providerType: KeyProviderType = KeyProviderType.HYBRID,
+ unlockedDeviceRequired: Boolean = false,
+ lockStatePollCount: Int = 5,
+ lockStatePollIntervalMs: Long = 100,
+ private val encryptionProvider: EncryptionProvider = TinkEncryptionProvider(context,
+ when (providerType) {
+ KeyProviderType.RAW ->
+ RawKeyProvider(context, masterKeyUri.replace("android-keystore://", ""), unlockedDeviceRequired)
+ KeyProviderType.HYBRID ->
+ HybridKeyProvider(context, masterKeyUri, unlockedDeviceRequired, "tink_keyset_${masterKeyUri.replace("android-keystore://", "")}")
+ KeyProviderType.RAW_HYBRID ->
+ RawHybridKeyProvider(context, masterKeyUri, unlockedDeviceRequired, "tink_keyset_${masterKeyUri.replace("android-keystore://", "")}", lockStatePollCount, lockStatePollIntervalMs)
+ },
+ when (providerType) {
+ KeyProviderType.RAW -> "ERAW".toByteArray()
+ KeyProviderType.HYBRID -> "EHBT".toByteArray()
+ KeyProviderType.RAW_HYBRID -> "EHBR".toByteArray()
+ }
+ )
+) {
+
+ fun destroy() {
+ encryptionProvider.destroy()
+ }
+
+ fun getUnlockDeviceRequired(): Boolean {
+ return (encryptionProvider as TinkEncryptionProvider).keyProvider.getUnlockDeviceRequired()
+ }
+
+ /**
+ * Encrypts a file using in-memory processing.
+ * Suitable for small files.
+ */
+ fun encryptToFile(file: File): OutputStream {
+ val encryptedContent = encryptionProvider.encrypt(file);
+ return encryptedContent
+ }
+
+ /**
+ * Decrypts a file using in-memory processing.
+ */
+ fun decryptFromFile(file: File): InputStream {
+ return encryptionProvider.decrypt(file)
+ }
+
+ /**
+ * Encrypts a file using streaming processing.
+ * Suitable for large files. Throws UnsupportedOperationException if the provider doesn't support streaming.
+ */
+ fun encryptToFileStream(file: File): OutputStream {
+ return encryptionProvider.encryptStream(file)
+ }
+
+ /**
+ * Encrypts a source file to a destination file using streaming processing.
+ * Uses a temporary `.tmp` file during encryption to prevent corruption if interrupted,
+ * and atomically renames it to the destination file upon successful completion.
+ *
+ * @param sourceFile The plaintext input file.
+ * @param destFile The target encrypted output file (e.g., `.enc`).
+ * @param deleteOriginal If true, safely deletes the source file upon success.
+ */
+ fun encryptFile(sourceFile: File, destFile: File, deleteOriginal: Boolean = true) {
+ val tmpFile = File(destFile.absolutePath + ".tmp")
+ try {
+ sourceFile.inputStream().use { input ->
+ try {
+ encryptToFileStream(tmpFile).use { output ->
+ input.copyTo(output)
+ }
+ } catch (e: java.lang.UnsupportedOperationException) {
+ // Fallback to in-memory encryption if streaming is not supported
+ encryptToFile(tmpFile).use { output ->
+ input.copyTo(output)
+ }
+ }
+ }
+ // Stream writing completed and closed successfully. Atomic rename:
+ if (!tmpFile.renameTo(destFile)) {
+ throw java.io.IOException("Failed to rename temporary encrypted file to target destination.")
+ }
+ // If successful and requested, delete original
+ if (deleteOriginal) {
+ if (!sourceFile.delete()) {
+ throw java.io.IOException("Failed to delete original plaintext file after encryption.")
+ }
+ }
+ } catch (e: Exception) {
+ // Clean up temporary file on failure
+ if (tmpFile.exists()) {
+ tmpFile.delete()
+ }
+ throw e
+ }
+ }
+
+ /**
+ * Decrypts a file using streaming processing.
+ */
+ fun decryptFromFileStream(file: File): InputStream {
+ return encryptionProvider.decryptStream(file)
+ }
+
+ /**
+ * Encrypts a string and returns it as a Base64-encoded ciphertext.
+ */
+ fun encryptToString(plaintext: String): String {
+ val ciphertext = encryptionProvider.encrypt(plaintext)
+ return Base64.encodeToString(ciphertext, Base64.DEFAULT)
+ }
+
+ /**
+ * Decrypts a Base64-encoded ciphertext string and returns the plaintext.
+ */
+ fun decryptFromString(ciphertext: String): String {
+ val ciphertextBytes = Base64.decode(ciphertext, Base64.DEFAULT)
+ return encryptionProvider.decrypt(ciphertextBytes)
+ }
+
+ /**
+ * Re-wraps the file key from asymmetric to symmetric scheme.
+ * This is useful for transitioning data received while locked to a more permanent
+ * symmetric protection after the device is unlocked (FDP_DAR_EXT.2.4 compliance).
+ */
+ fun rewrapFileKey(file: File): Boolean {
+ return encryptionProvider.rewrapFileKey(android.net.Uri.fromFile(file))
+ }
+
+ /**
+ * Sweeps the app's files directory and re-wraps all pending encrypted files
+ * to the symmetric scheme.
+ */
+ fun sweepAndRewrapPendingFiles() {
+ encryptionProvider.sweepAndRewrapPendingFiles()
+ }
+}
diff --git a/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/api/KeyProviderType.kt b/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/api/KeyProviderType.kt
new file mode 100644
index 0000000..6c75c3e
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/api/KeyProviderType.kt
@@ -0,0 +1,39 @@
+/*
+* Copyright (C) 2026 The Android Open Source Project
+*
+* Licensed under the Apache License, Version 2.0 (the "License");
+* you may not use this file except in compliance with the License.
+* You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing, software
+* distributed under the License is distributed on an "AS IS" BASIS,
+* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+* See the License for the specific language governing permissions and
+* limitations under the License.
+*/
+
+package com.android.niapsec.encryption.api
+
+/**
+ * Defines the available KeyProvider implementations that can be used by the EncryptionManager.
+ */
+enum class KeyProviderType {
+ /**
+ * Uses the HybridKeyProvider, which uses a P-521 elliptic curve key pair as the KEK
+ * and AES256-GCM as the DEK for hybrid encryption.
+ */
+ HYBRID,
+
+ /**
+ * Uses the RawEncryptionProvider, which uses the standard Android Keystore and JCA
+ * without the Tink library.
+ */
+ RAW,
+
+ /**
+ * Uses the RawHybridKeyProvider, which implements a hybrid encryption scheme using raw JCA.
+ */
+ RAW_HYBRID
+}
diff --git a/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/internal/EncryptionProvider.kt b/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/internal/EncryptionProvider.kt
new file mode 100644
index 0000000..9a03ac8
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/internal/EncryptionProvider.kt
@@ -0,0 +1,71 @@
+/*
+* Copyright (C) 2026 The Android Open Source Project
+*
+* Licensed under the Apache License, Version 2.0 (the "License");
+* you may not use this file except in compliance with the License.
+* You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing, software
+* distributed under the License is distributed on an "AS IS" BASIS,
+* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+* See the License for the specific language governing permissions and
+* limitations under the License.
+*/
+
+package com.android.niapsec.encryption.internal
+
+import android.net.Uri
+import java.io.File
+import java.io.InputStream
+import java.io.OutputStream
+
+/**
+ * An interface for providing encryption and decryption operations.
+ */
+interface EncryptionProvider {
+
+ /**
+ * Encrypts a file using in-memory processing (Aead).
+ * Best for small files.
+ */
+ fun encrypt(file: File): OutputStream
+
+ /**
+ * Encrypts a file using streaming processing (StreamingAead).
+ * Best for large files. Throws exception if not supported by the provider.
+ */
+ fun encryptStream(file: File): OutputStream
+
+ /**
+ * Encrypts a plaintext string into a ciphertext byte array.
+ */
+ fun encrypt(plaintext: String): ByteArray
+
+ /**
+ * Decrypts a file using in-memory processing (Aead).
+ */
+ fun decrypt(file: File): InputStream
+
+ /**
+ * Decrypts a file using streaming processing (StreamingAead).
+ * Throws exception if not supported by the provider.
+ */
+ fun decryptStream(file: File): InputStream
+
+ /**
+ * Decrypts a ciphertext byte array into a plaintext string.
+ */
+ fun decrypt(ciphertext: ByteArray): String
+
+ //new methods for rewrap with symmetric keys
+ fun rewrapFileKey(fileUri: Uri): Boolean
+
+ fun sweepAndRewrapPendingFiles()
+
+ /**
+ * Destroys any cryptographic material associated with this provider.
+ */
+ fun destroy()
+}
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/internal/TinkEncryptionProvider.kt b/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/internal/TinkEncryptionProvider.kt
new file mode 100644
index 0000000..eec23df
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/internal/TinkEncryptionProvider.kt
@@ -0,0 +1,167 @@
+/*
+* Copyright (C) 2026 The Android Open Source Project
+*
+* Licensed under the Apache License, Version 2.0 (the "License");
+* you may not use this file except in compliance with the License.
+* You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing, software
+* distributed under the License is distributed on an "AS IS" BASIS,
+* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+* See the License for the specific language governing permissions and
+* limitations under the License.
+*/
+
+package com.android.niapsec.encryption.internal
+
+import android.content.Context
+import android.net.Uri
+import android.util.Log
+import com.android.niapsec.encryption.internal.keymanagement.KeyProvider
+import java.io.ByteArrayInputStream
+import java.io.ByteArrayOutputStream
+import java.io.File
+import java.io.FileInputStream
+import java.io.FileOutputStream
+import java.io.InputStream
+import java.io.OutputStream
+import java.security.GeneralSecurityException
+
+class TinkEncryptionProvider(
+ private val context: Context,
+ val keyProvider: KeyProvider,
+ private val providerHeader: ByteArray // [MDFPP] 4-byte Magic Header: ERAW, EHBT, or EHBR
+) : EncryptionProvider {
+
+ // --- File Operations (In-Memory) ---
+
+ override fun encrypt(file: File): OutputStream {
+ val aead = keyProvider.getAead()
+ val fileOutputStream = FileOutputStream(file)
+ fileOutputStream.write(providerHeader)
+
+ return object : ByteArrayOutputStream() {
+ override fun close() {
+ try {
+ val ciphertext = aead.encrypt(toByteArray(), providerHeader)
+ fileOutputStream.write(ciphertext)
+ } finally {
+ fileOutputStream.close()
+ super.close()
+ }
+ }
+ }
+ }
+
+ override fun decrypt(file: File): InputStream {
+ val fileInputStream = FileInputStream(file)
+ try {
+ val header = ByteArray(providerHeader.size)
+ if (fileInputStream.read(header) != header.size || !header.contentEquals(providerHeader)) {
+ throw GeneralSecurityException("Invalid provider header.")
+ }
+ val ciphertext = fileInputStream.readBytes()
+ val aead = keyProvider.getAead()
+ val plaintext = aead.decrypt(ciphertext, providerHeader)
+ return ByteArrayInputStream(plaintext)
+ } finally {
+ fileInputStream.close()
+ }
+ }
+
+ // --- Stream Operations (StreamingAead) ---
+
+ override fun encryptStream(file: File): OutputStream {
+ val streamingAead = keyProvider.getStreamingAead() ?: throw UnsupportedOperationException("Streaming not supported")
+ val fileOutputStream = FileOutputStream(file)
+ try {
+ fileOutputStream.write(providerHeader)
+ return streamingAead.newEncryptingStream(fileOutputStream, providerHeader)
+ } catch (e: Exception) {
+ fileOutputStream.close()
+ throw e
+ }
+ }
+
+ override fun decryptStream(file: File): InputStream {
+ val streamingAead = keyProvider.getStreamingAead() ?: throw UnsupportedOperationException("Streaming not supported")
+ val fileInputStream = FileInputStream(file)
+ try {
+ val header = ByteArray(providerHeader.size)
+ if (fileInputStream.read(header) != header.size || !header.contentEquals(providerHeader)) {
+ throw GeneralSecurityException("Invalid provider header.")
+ }
+ return streamingAead.newDecryptingStream(fileInputStream, providerHeader)
+ } catch (e: Exception) {
+ fileInputStream.close()
+ throw e
+ }
+ }
+
+ // --- String / Misc Operations ---
+
+ override fun encrypt(plaintext: String): ByteArray {
+ val aead = keyProvider.getAead()
+ val ciphertext = aead.encrypt(plaintext.toByteArray(), providerHeader)
+ return providerHeader + ciphertext
+ }
+
+ override fun decrypt(ciphertext: ByteArray): String {
+ if (ciphertext.size < providerHeader.size) {
+ throw GeneralSecurityException("Invalid ciphertext size.")
+ }
+
+ val header = ciphertext.copyOfRange(0, providerHeader.size)
+ val actualCiphertext = ciphertext.copyOfRange(providerHeader.size, ciphertext.size)
+
+ if (!header.contentEquals(providerHeader)) {
+ throw GeneralSecurityException("Invalid provider header.")
+ }
+
+ val aead = keyProvider.getAead()
+ val plaintext = aead.decrypt(actualCiphertext, providerHeader)
+ return String(plaintext)
+ }
+
+ override fun rewrapFileKey(fileUri: Uri): Boolean {
+ val path = fileUri.path ?: return false
+ val file = File(path)
+ if (!file.exists() || !file.isFile) return false
+
+ return try {
+ val fileBytes = file.readBytes()
+ if (fileBytes.size <= providerHeader.size) return false
+
+ val header = fileBytes.copyOfRange(0, providerHeader.size)
+ val actualCiphertext = fileBytes.copyOfRange(providerHeader.size, fileBytes.size)
+
+ if (!header.contentEquals(providerHeader)) return false
+
+ if (keyProvider.isSymmetricallyWrapped(actualCiphertext)) {
+ return true
+ }
+
+ val newCiphertext = keyProvider.rewrapKeyToSymmetricUdr(actualCiphertext)
+ file.writeBytes(providerHeader + newCiphertext)
+ true
+ } catch (e: Exception) {
+ Log.e("TinkEncryptionProvider", "Failed to rewrap file: $path", e)
+ false
+ }
+ }
+
+ override fun sweepAndRewrapPendingFiles() {
+ val filesDir = context.filesDir
+ filesDir.listFiles()?.forEach { file ->
+ if (file.isFile) {
+ rewrapFileKey(Uri.fromFile(file))
+ }
+ }
+ }
+
+ override fun destroy() {
+ keyProvider.destroy()
+ }
+}
diff --git a/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/internal/keymanagement/HybridKeyProvider.kt b/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/internal/keymanagement/HybridKeyProvider.kt
new file mode 100644
index 0000000..5fb6769
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/internal/keymanagement/HybridKeyProvider.kt
@@ -0,0 +1,276 @@
+/*
+* Copyright (C) 2026 The Android Open Source Project
+*
+* Licensed under the Apache License, Version 2.0 (the "License");
+* you may not use this file except in compliance with the License.
+* You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing, software
+* distributed under the License is distributed on an "AS IS" BASIS,
+* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+* See the License for the specific language governing permissions and
+* limitations under the License.
+*/
+package com.android.niapsec.encryption.internal.keymanagement
+
+import android.content.Context
+import android.security.keystore.KeyGenParameterSpec
+import android.security.keystore.KeyProperties
+import android.util.Log
+import androidx.core.content.edit
+import com.google.crypto.tink.Aead
+import com.google.crypto.tink.CleartextKeysetHandle
+import com.google.crypto.tink.HybridDecrypt
+import com.google.crypto.tink.HybridEncrypt
+import com.google.crypto.tink.JsonKeysetReader
+import com.google.crypto.tink.JsonKeysetWriter
+import com.google.crypto.tink.KeyTemplate
+import com.google.crypto.tink.KeysetHandle
+import com.google.crypto.tink.aead.AeadConfig
+import com.google.crypto.tink.hybrid.HybridConfig
+import com.google.crypto.tink.integration.android.AndroidKeysetManager
+import com.google.crypto.tink.proto.AesGcmKeyFormat
+import com.google.crypto.tink.proto.EcPointFormat
+import com.google.crypto.tink.proto.EciesAeadDemParams
+import com.google.crypto.tink.proto.EciesAeadHkdfKeyFormat
+import com.google.crypto.tink.proto.EciesAeadHkdfParams
+import com.google.crypto.tink.proto.EciesHkdfKemParams
+import com.google.crypto.tink.proto.EllipticCurveType
+import com.google.crypto.tink.proto.HashType
+import java.io.ByteArrayOutputStream
+import java.security.GeneralSecurityException
+import java.security.KeyStore
+import javax.crypto.KeyGenerator
+
+/**
+ * [Security Component: Tink-based Hybrid Encryption]
+ * * Implementation relies on Google Tink's `AndroidKeysetManager` and `KeysetHandle`.
+ * * This class leverages validated library implementations for cryptographic schemes.
+ *
+ * [Compliance Note]
+ * * **FCS_CKM.2/LOCKED (Cryptographic Key Establishment):**
+ * - SATISFIED: Uses Tink's ECIES-AEAD-HKDF implementation to establish keys for encryption
+ * even while the device is in a Locked State.
+ *
+ * * **FCS_STG_EXT.2 (Encrypted Key Storage):**
+ * - SATISFIED: Private keysets are stored in SharedPreferences wrapped (encrypted) by a Master Key
+ * held in the Android Keystore. The keyset is never stored in plaintext on the filesystem.
+ *
+ * * **FDP_DAR_EXT.2 (Sensitive Data Encryption):**
+ * - SATISFIED: Implements public key encryption (ECIES-AEAD-HKDF) allowing data ingestion and protection
+ * while the device is in a Locked State (B/F/U states).
+ *
+ * * **FIA_UAU_EXT.1 (Authentication for Cryptographic Operation):**
+ * - SATISFIED: The Master Key (wrapping key) is configured with `.setUnlockedDeviceRequired(true)`.
+ * Tink cannot unwrap (decrypt) the Keyset containing the private key unless the user has authenticated.
+ *
+ * * **FCS_CKM_EXT.4 (Key Destruction):**
+ * - PARTIALLY SATISFIED (Storage Only): `destroy()` removes the encrypted keyset and the Master Key alias.
+ * - NOTE: Volatile memory zeroization relies on the underlying Tink library implementation and JVM
+ * Garbage Collection. (For explicit memory zeroization requirements, see `RawHybridKeyProvider`).
+ */
+class HybridKeyProvider(
+ private val context: Context,
+ private val masterKeyUri: String,
+ _unlockedDeviceRequired: Boolean,
+ private val keysetPrefName: String
+) : KeyProvider {
+
+ private val deviceProtectedContext = context.createDeviceProtectedStorageContext()
+ companion object {
+ val P521_AES256_GCM_TEMPLATE: KeyTemplate by lazy {
+ val demAeadKeyFormat = AesGcmKeyFormat.newBuilder().setKeySize(32).build()
+ val demKeyTemplate = com.google.crypto.tink.proto.KeyTemplate.newBuilder()
+ .setValue(demAeadKeyFormat.toByteString())
+ .setTypeUrl("type.googleapis.com/google.crypto.tink.AesGcmKey")
+ .setOutputPrefixType(com.google.crypto.tink.proto.OutputPrefixType.TINK)
+ .build()
+ val demParams = EciesAeadDemParams.newBuilder().setAeadDem(demKeyTemplate).build()
+ val kemParams = EciesHkdfKemParams.newBuilder()
+ .setCurveType(EllipticCurveType.NIST_P521)
+ .setHkdfHashType(HashType.SHA256)
+ .build()
+ val eciesParams = EciesAeadHkdfParams.newBuilder()
+ .setKemParams(kemParams)
+ .setDemParams(demParams)
+ .setEcPointFormat(EcPointFormat.UNCOMPRESSED)
+ .build()
+ val keyFormat = EciesAeadHkdfKeyFormat.newBuilder()
+ .setParams(eciesParams)
+ .build()
+ KeyTemplate.create(
+ "type.googleapis.com/google.crypto.tink.EciesAeadHkdfPrivateKey",
+ keyFormat.toByteString().toByteArray(),
+ KeyTemplate.OutputPrefixType.TINK
+ )
+ }
+ }
+
+ private val PRIVATE_KEYSET_NAME = "hybrid_private_keyset"
+ private val PUBLIC_KEYSET_PREF_NAME = "hybrid_public_keyset_pref"
+ private val PUBLIC_KEYSET_KEY = "public_keyset"
+ val unlockedDeviceRequired: Boolean = _unlockedDeviceRequired
+
+ init {
+ AeadConfig.register()
+ HybridConfig.register()
+ try {
+ createMasterKeyIfNeeded()
+ synchronizePublicKeyset()
+ } catch (e: Exception) {
+ Log.w("HybridKeyProvider", "Initialization sync failed, will retry later: ${e.message}")
+ }
+ }
+
+ private fun getPublicKeysetHandle(): KeysetHandle {
+ val prefs = deviceProtectedContext.getSharedPreferences(PUBLIC_KEYSET_PREF_NAME, Context.MODE_PRIVATE)
+ var serializedPublicKeyset = prefs.getString(PUBLIC_KEYSET_KEY, null)
+
+ if (serializedPublicKeyset == null) {
+ // Public keyset is not found, so we need to generate and save it now.
+ // This might fail if the device is locked.
+ synchronizePublicKeyset()
+ serializedPublicKeyset = prefs.getString(PUBLIC_KEYSET_KEY, null)
+ }
+
+ return serializedPublicKeyset?.let {
+ CleartextKeysetHandle.read(JsonKeysetReader.withString(it))
+ } ?: throw GeneralSecurityException(
+ "Could not get or create public keyset. Device might be locked."
+ )
+ }
+
+ private fun synchronizePublicKeyset() {
+ try {
+ // Get the private keyset, which may trigger key generation if it doesn't exist
+ val privateKeysetManager: AndroidKeysetManager by lazy {
+ AndroidKeysetManager.Builder()
+ .withSharedPref( deviceProtectedContext, PRIVATE_KEYSET_NAME, keysetPrefName)
+ .withKeyTemplate(P521_AES256_GCM_TEMPLATE)
+ .withMasterKeyUri(masterKeyUri)
+ .build()
+ }
+ //Extract the public keyset
+ val publicKeysetHandle = privateKeysetManager.keysetHandle.publicKeysetHandle
+
+ // Serialize the public keyset to a string
+ val outputStream = ByteArrayOutputStream()
+ CleartextKeysetHandle.write(
+ publicKeysetHandle, JsonKeysetWriter.withOutputStream(outputStream)
+ )
+ val serializedPublicKeyset = outputStream.toString()
+
+ // Manually write the serialized public keyset to a separate shared preference.
+ deviceProtectedContext.getSharedPreferences(PUBLIC_KEYSET_PREF_NAME, Context.MODE_PRIVATE)
+ .edit(commit = true) {
+ putString(PUBLIC_KEYSET_KEY, serializedPublicKeyset)
+ }
+ } catch (e: GeneralSecurityException) {
+ // This can happen if the device is locked and the private key is not in memory.
+ Log.w(
+ "HybridKeyProvider",
+ "Could not synchronize public keyset, device might be locked.",
+ e
+ )
+ // Re-throw the exception to notify the caller that the operation failed.
+ throw e
+ }
+ }
+
+ override fun getUnlockDeviceRequired(): Boolean {
+ return unlockedDeviceRequired
+ }
+
+ override fun rewrapKeyToSymmetricUdr(encryptedDek: ByteArray): ByteArray {
+ TODO("Not yet implemented")
+ }
+
+ override fun isSymmetricallyWrapped(encryptedDek: ByteArray): Boolean {
+ TODO("Not yet implemented")
+ }
+
+ private fun createMasterKeyIfNeeded() {
+ val keyAlias = masterKeyUri.removePrefix("android-keystore://")
+ val keyStore = KeyStore.getInstance("AndroidKeyStore")
+ keyStore.load(null)
+ if (!keyStore.containsAlias(keyAlias)) {
+ val keyGenerator =
+ KeyGenerator.getInstance(KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore")
+ val specBuilder = KeyGenParameterSpec.Builder(
+ keyAlias,
+ KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT
+ )
+ .setBlockModes(KeyProperties.BLOCK_MODE_GCM)
+ .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
+ .setKeySize(256)
+
+ // [FIA_UAU_EXT.1] Authentication for Cryptographic Operation
+ // * REQUIREMENT: The TSF shall require the user to be authenticated before performing specific cryptographic operations.
+ // * IMPLEMENTATION: By invoking `setUnlockedDeviceRequired(true)`, we mandate that the Android Keystore system
+ // blocks any access to this key material unless the device is in an unlocked state (user authenticated).
+ if (unlockedDeviceRequired) {
+ specBuilder.setUnlockedDeviceRequired(true)
+ }
+ keyGenerator.init(specBuilder.build())
+ keyGenerator.generateKey()
+ }
+ }
+
+ override fun getAead(): Aead {
+
+ // [FCS_CKM.2/LOCKED] & [FDP_DAR_EXT.2]
+ // Public key from Keyset allows key establishment and encryption in Locked State.
+ // This does not require the device to be unlocked as the public key is stored in cleartext.
+ val publicKeysetHandle = getPublicKeysetHandle()
+ val hybridEncrypt = publicKeysetHandle.getPrimitive(HybridEncrypt::class.java)
+
+ return object : Aead {
+ override fun encrypt(plaintext: ByteArray, associatedData: ByteArray): ByteArray {
+ // [FDP_DAR_EXT.2] Public key encryption allows operation in Locked State
+ return hybridEncrypt.encrypt(plaintext, associatedData)
+ }
+
+ override fun decrypt(ciphertext: ByteArray, associatedData: ByteArray): ByteArray {
+ // [FCS_STG_EXT.2] Private key is wrapped by Android Keystore (Master Key)
+ //Don't hold the private key and Manager in memory.
+ AndroidKeysetManager.Builder()
+ .withSharedPref( deviceProtectedContext, PRIVATE_KEYSET_NAME, keysetPrefName)
+ .withKeyTemplate(P521_AES256_GCM_TEMPLATE)
+ .withMasterKeyUri(masterKeyUri)
+ .build().let { privateKeysetManager ->
+ val privateKeysetHandle = privateKeysetManager.keysetHandle
+ val hybridDecrypt = privateKeysetHandle.getPrimitive(HybridDecrypt::class.java)
+ return hybridDecrypt.decrypt(ciphertext, associatedData)
+ }
+
+ }
+ }
+ }
+
+ override fun destroy() {
+ // Clear the private keyset preference file
+ deviceProtectedContext.getSharedPreferences(keysetPrefName, Context.MODE_PRIVATE).edit(commit = true) {
+ clear()
+ }
+ // Clear the public keyset preference file
+ deviceProtectedContext.getSharedPreferences(PUBLIC_KEYSET_PREF_NAME, Context.MODE_PRIVATE)
+ .edit(commit = true) {
+ clear()
+ }
+
+ try {
+ val keyStore = KeyStore.getInstance("AndroidKeyStore")
+ keyStore.load(null)
+ val keyAlias = masterKeyUri.removePrefix("android-keystore://")
+ if (keyStore.containsAlias(keyAlias)) {
+ keyStore.deleteEntry(keyAlias)
+ }
+ } catch (e: Exception) {
+ Log.e("HybridKeyProvider", "Failed to destroy master key", e)
+ }
+ }
+}
+
+
diff --git a/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/internal/keymanagement/KeyProvider.kt b/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/internal/keymanagement/KeyProvider.kt
new file mode 100644
index 0000000..1ee2bd7
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/internal/keymanagement/KeyProvider.kt
@@ -0,0 +1,49 @@
+/*
+* Copyright (C) 2026 The Android Open Source Project
+*
+* Licensed under the Apache License, Version 2.0 (the "License");
+* you may not use this file except in compliance with the License.
+* You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing, software
+* distributed under the License is distributed on an "AS IS" BASIS,
+* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+* See the License for the specific language governing permissions and
+* limitations under the License.
+*/
+package com.android.niapsec.encryption.internal.keymanagement
+
+import com.google.crypto.tink.Aead
+import com.google.crypto.tink.StreamingAead
+
+/**
+ * A common interface for key providers, allowing different underlying key management
+ * strategies (hardware-backed, software-only, etc.) to be used interchangeably.
+ */
+interface KeyProvider {
+ /**
+ * Retrieves the AEAD primitive for performing cryptographic operations.
+ */
+ fun getAead(): Aead
+
+ /**
+ * Retrieves the StreamingAead primitive for performing streaming cryptographic operations.
+ * Returns null if streaming is not supported by this provider.
+ */
+ fun getStreamingAead(): StreamingAead? = null
+
+ fun getUnlockDeviceRequired(): Boolean
+
+ //new methods for rewrapping with UDR symmetric keys
+ fun rewrapKeyToSymmetricUdr(encryptedDek: ByteArray): ByteArray
+
+ fun isSymmetricallyWrapped(encryptedDek: ByteArray): Boolean
+
+ /**
+ * Destroys all cryptographic material associated with this provider.
+ */
+ fun destroy()
+}
+
diff --git a/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/internal/keymanagement/RawHybridKeyProvider.kt b/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/internal/keymanagement/RawHybridKeyProvider.kt
new file mode 100644
index 0000000..e31757d
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/internal/keymanagement/RawHybridKeyProvider.kt
@@ -0,0 +1,1157 @@
+/*
+ * Copyright (C) 2026 The Android Open Source Project
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package com.android.niapsec.encryption.internal.keymanagement
+
+import android.content.Context
+import android.security.keystore.KeyGenParameterSpec
+import android.security.keystore.KeyProperties
+import android.util.Base64
+import android.util.Log
+import androidx.core.content.edit
+import com.android.niapsec.encryption.tools.CleanSecretKeySpec
+import com.android.niapsec.encryption.tools.SafeHkdf
+import com.android.niapsec.encryption.tools.SecurityAuditLogger
+import com.google.crypto.tink.Aead
+import com.google.crypto.tink.StreamingAead
+import java.io.ByteArrayOutputStream
+import java.io.DataInputStream
+import java.io.DataOutputStream
+import java.io.InputStream
+import java.io.OutputStream
+import java.nio.ByteBuffer
+import java.nio.channels.ReadableByteChannel
+import java.nio.channels.SeekableByteChannel
+import java.nio.channels.WritableByteChannel
+import java.security.GeneralSecurityException
+import java.security.Key
+import java.security.KeyFactory
+import java.security.KeyPair
+import java.security.KeyPairGenerator
+import java.security.KeyStore
+import java.security.PrivateKey
+import java.security.PublicKey
+import java.security.SecureRandom
+import java.security.spec.ECGenParameterSpec
+import java.security.spec.X509EncodedKeySpec
+import javax.crypto.Cipher
+import javax.crypto.CipherInputStream
+import javax.crypto.CipherOutputStream
+import javax.crypto.KeyAgreement
+import javax.crypto.spec.GCMParameterSpec
+import javax.crypto.spec.SecretKeySpec
+
+/**
+ * [Security Component: Raw JCA Hybrid Encryption]
+ * * Custom implementation using Java Cryptography Architecture (JCA) primitives.
+ * * This class provides direct control over key material life-cycle and memory management.
+ *
+ * [Compliance Note]
+ * * **FCS_STG_EXT.2 (Encrypted Key Storage):**
+ * - SATISFIED: Private keys are generated and stored directly within the Android Keystore
+ * (`AndroidKeyStore` provider), ensuring they are never exposed in plaintext to the application layer.
+ *
+ * * **FCS_CKM_EXT.4 (Key Destruction):**
+ * - SATISFIED: This implementation explicitly overwrites sensitive key material (DEK, Shared Secret)
+ * with zeros in `finally` blocks immediately after use. This provides deterministic destruction
+ * of keys in volatile memory, independent of Garbage Collection timing.
+ * - SATISFIED: Persistent keys are destroyed via `KeyStore.deleteEntry()` and `SharedPreferences.Editor.clear()`.
+ *
+ * * **FDP_DAR_EXT.2 (Sensitive Data Encryption):**
+ * - SATISFIED: Uses an asymmetric key scheme to allow data encryption even when the device is locked
+ * and the private key is unavailable.
+ *
+ * * **FIA_UAU_EXT.1 (Authentication for Cryptographic Operation):**
+ * - SATISFIED: Enforces user authentication policies at the OS level by configuring
+ * `KeyGenParameterSpec.Builder.setUnlockedDeviceRequired(true)`. This ensures that decryption
+ * operations fail if the device is not unlocked.
+ */
+class RawHybridKeyProvider(
+ private val context: Context,
+ private val masterKeyUri: String,
+ _unlockedDeviceRequired: Boolean,
+ private val keysetPrefName: String,
+ private val lockStatePollCount: Int = 5,
+ private val lockStatePollIntervalMs: Long = 100
+) : KeyProvider {
+
+ private val masterKeyAlias = masterKeyUri.removePrefix("android-keystore://")
+ private val symmetricMasterKeyAlias = "${masterKeyAlias}_symmetric"
+ private val keyStore = KeyStore.getInstance(ANDROID_KEYSTORE).apply { load(null) }
+ val unlockedDeviceRequired: Boolean = _unlockedDeviceRequired
+
+ private val storageContext: Context = context.createDeviceProtectedStorageContext()
+
+ private val prefs = storageContext.getSharedPreferences(keysetPrefName, Context.MODE_PRIVATE)
+
+ companion object {
+ private const val ANDROID_KEYSTORE = "AndroidKeyStore"
+ private const val KEY_PUBLIC_KEY_PREF = "master_public_key"
+ private const val EC_KEY_ALGORITHM = KeyProperties.KEY_ALGORITHM_EC
+ private const val KEY_AGREEMENT_ALGORITHM = "ECDH"
+ private const val DEK_ALGORITHM = "AES"
+ private const val DEK_WRAPPING_CIPHER = "AES/GCM/NoPadding"
+ private const val DEK_SIZE_BITS = 256
+ private const val DATA_CIPHER = "AES/GCM/NoPadding"
+ private const val GCM_TAG_LENGTH_BITS = 128
+ const val MAGIC_BYTE_ASYMMETRIC: Byte = 0x01 // Temporary storage while locked (current Hybrid scheme)
+ const val MAGIC_BYTE_SYMMETRIC: Byte = 0x02 // Re-encrypted after unlock (symmetric UDR scheme)
+ val dummyPubKey: PublicKey by lazy {
+ val kpg = KeyPairGenerator.getInstance("EC")
+ kpg.initialize(java.security.spec.ECGenParameterSpec("secp521r1"))
+ kpg.generateKeyPair().public
+ }
+ }
+
+ init {
+ generateAndStoreKeyPairIfNeeded()
+ generateSymmetricEcKeyPairIfNeeded()
+ generateSymmetricMasterKeyIfNeeded()
+ generateWrappingKeyIfNeeded()
+ }
+
+ private fun getFlushIterations(): Int {
+ return context.getSharedPreferences("niap_sec_prefs", Context.MODE_PRIVATE)
+ .getInt("keystore_flush_iterations", 0)
+ }
+
+ private fun flushKeystoreIpcBuffers() {
+ val iterations = getFlushIterations()
+ if (iterations <= 0) {
+ return // Skip flush processing if the setting is 0 or less
+ }
+
+ val startTime = System.currentTimeMillis()
+ try {
+ val dummyDek = ByteArray(DEK_SIZE_BITS / 8)
+ val masterKey = keyStore.getKey(symmetricMasterKeyAlias, null) ?: return
+ val flushCipher = Cipher.getInstance(DEK_WRAPPING_CIPHER)
+
+ for (i in 0 until iterations) {
+ flushCipher.init(Cipher.ENCRYPT_MODE, masterKey)
+ flushCipher.doFinal(dummyDek)
+ }
+ val elapsed = System.currentTimeMillis() - startTime
+ Log.d("RawHybridKeyProvider", "Keystore IPC flush completed: $iterations iterations took ${elapsed}ms")
+ SecurityAuditLogger.logLine("Keystore IPC flush ($iterations runs) took ${elapsed}ms")
+ } catch (e: Exception) {
+ val elapsed = System.currentTimeMillis() - startTime
+ Log.w("RawHybridKeyProvider", "Keystore IPC flush failed after ${elapsed}ms: ${e.message}")
+ }
+ }
+
+ private fun generateSymmetricMasterKeyIfNeeded() {
+ if (!keyStore.containsAlias(symmetricMasterKeyAlias)) {
+ val keyGenerator = javax.crypto.KeyGenerator.getInstance(KeyProperties.KEY_ALGORITHM_AES, ANDROID_KEYSTORE)
+ val specBuilder = KeyGenParameterSpec.Builder(
+ symmetricMasterKeyAlias,
+ KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT
+ )
+ .setBlockModes(KeyProperties.BLOCK_MODE_GCM)
+ .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
+ .setKeySize(256)
+
+ // MDFPP Requirement: Enforce user authentication for symmetric protection
+ specBuilder.setUnlockedDeviceRequired(unlockedDeviceRequired)
+
+ keyGenerator.init(specBuilder.build())
+ keyGenerator.generateKey()
+ }
+ }
+
+ private fun generateWrappingKeyIfNeeded() {
+ val wrappingKeyAlias = "${masterKeyAlias}_wrapping"
+ if (!keyStore.containsAlias(wrappingKeyAlias)) {
+ val kpg = KeyPairGenerator.getInstance(KeyProperties.KEY_ALGORITHM_RSA, ANDROID_KEYSTORE)
+ val spec = KeyGenParameterSpec.Builder(
+ wrappingKeyAlias,
+ KeyProperties.PURPOSE_WRAP_KEY
+ )
+ .setKeySize(2048)
+ .setDigests(KeyProperties.DIGEST_SHA256) // Specify SHA-256 only to align with CTS
+ .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_RSA_OAEP)
+ .setUnlockedDeviceRequired(unlockedDeviceRequired)
+ .build()
+ kpg.initialize(spec)
+ kpg.generateKeyPair()
+ }
+ }
+
+ private fun generateAndStoreKeyPairIfNeeded() {
+
+ if (keyStore.containsAlias(masterKeyAlias)) {
+ if (!prefs.contains(KEY_PUBLIC_KEY_PREF)) {
+ try {
+ val entry = keyStore.getEntry(masterKeyAlias, null) as? KeyStore.PrivateKeyEntry
+ entry?.certificate?.publicKey?.let { publicKey ->
+ savePublicKey(publicKey)
+ }
+ } catch (e: Exception) {
+ // Key might be broken!, only record the log in this time.
+ }
+ }
+ } else {
+ // New key generation
+ val kpg = KeyPairGenerator.getInstance(EC_KEY_ALGORITHM, ANDROID_KEYSTORE)
+ val spec = KeyGenParameterSpec.Builder(
+ masterKeyAlias,
+ KeyProperties.PURPOSE_AGREE_KEY
+ )
+ .setAlgorithmParameterSpec(ECGenParameterSpec("secp521r1"))
+ .setDigests(KeyProperties.DIGEST_SHA512)
+ // [FIA_UAU_EXT.1] Authentication for Cryptographic Operation
+ // * ENFORCEMENT: Configures the TSF (Android Keystore) to reject key agreement operations
+ // if the user has not authenticated (device locked).
+ .setUnlockedDeviceRequired(unlockedDeviceRequired)
+ .build()
+
+ kpg.initialize(spec)
+ val keyPair = kpg.generateKeyPair()
+
+ savePublicKey(keyPair.public)
+ }
+ }
+
+ /**
+ * WORKAROUND [FCS_CKM_EXT.4]: Generates a dedicated hardware-backed EC key pair for Symmetric mode
+ * to perform ECDH key agreement. This is a workaround for the Keystore2 IPC memory leak
+ * observed when passing raw DEKs directly to Keystore2 for symmetric wrapping.
+ * By using ECDH, the raw DEK never leaves the application process during wrapping.
+ */
+ private fun generateSymmetricEcKeyPairIfNeeded() {
+ val symmetricEcAlias = "${masterKeyAlias}_symmetric_ec"
+ if (keyStore.containsAlias(symmetricEcAlias)) {
+ val prefsKey = "${KEY_PUBLIC_KEY_PREF}_symmetric"
+ if (!prefs.contains(prefsKey)) {
+ try {
+ val entry = keyStore.getEntry(symmetricEcAlias, null) as? KeyStore.PrivateKeyEntry
+ entry?.certificate?.publicKey?.let { publicKey ->
+ saveSymmetricPublicKey(publicKey)
+ }
+ } catch (e: Exception) {
+ // Key might be broken
+ }
+ }
+ } else {
+ val kpg = KeyPairGenerator.getInstance(EC_KEY_ALGORITHM, ANDROID_KEYSTORE)
+ val spec = KeyGenParameterSpec.Builder(
+ symmetricEcAlias,
+ KeyProperties.PURPOSE_AGREE_KEY
+ )
+ .setAlgorithmParameterSpec(ECGenParameterSpec("secp521r1"))
+ .setDigests(KeyProperties.DIGEST_SHA512)
+ .setUnlockedDeviceRequired(true) // ALWAYS UDR
+ .build()
+
+ kpg.initialize(spec)
+ val keyPair = kpg.generateKeyPair()
+
+ saveSymmetricPublicKey(keyPair.public)
+ }
+ }
+
+ private fun saveSymmetricPublicKey(publicKey: PublicKey) {
+ val prefsKey = "${KEY_PUBLIC_KEY_PREF}_symmetric"
+ val encodedKey = Base64.encodeToString(publicKey.encoded, Base64.NO_WRAP)
+ prefs.edit().putString(prefsKey, encodedKey).apply()
+ }
+
+ private fun savePublicKey(publicKey: PublicKey) {
+ val encodedKey = Base64.encodeToString(publicKey.encoded, Base64.NO_WRAP)
+ prefs.edit().putString(KEY_PUBLIC_KEY_PREF, encodedKey).apply()
+ }
+
+ private fun loadRecipientPublicKey(): PublicKey {
+ val encodedKey = prefs.getString(KEY_PUBLIC_KEY_PREF, null)
+ ?: throw GeneralSecurityException("Master public key not found in SharedPreferences.")
+ val bytes = Base64.decode(encodedKey, Base64.NO_WRAP)
+ val spec = X509EncodedKeySpec(bytes)
+ return KeyFactory.getInstance(EC_KEY_ALGORITHM).generatePublic(spec)
+ }
+
+ private fun loadSymmetricPublicKey(): PublicKey {
+ val prefsKey = "${KEY_PUBLIC_KEY_PREF}_symmetric"
+ val encodedKey = prefs.getString(prefsKey, null)
+ ?: throw GeneralSecurityException("Symmetric UDR public key not found in SharedPreferences.")
+ val bytes = Base64.decode(encodedKey, Base64.NO_WRAP)
+ val spec = X509EncodedKeySpec(bytes)
+ return KeyFactory.getInstance(EC_KEY_ALGORITHM).generatePublic(spec)
+ }
+
+ private fun loadRecipientPrivateKey(): PrivateKey {
+ val entry = keyStore.getEntry(masterKeyAlias, null)
+ ?: throw GeneralSecurityException("Master key alias not found in Keystore: $masterKeyAlias")
+ if (entry !is KeyStore.PrivateKeyEntry) {
+ throw GeneralSecurityException("Keystore entry is not a private key: $masterKeyAlias")
+ }
+ return entry.privateKey
+ }
+
+ private fun loadSymmetricRecipientPrivateKey(): PrivateKey {
+ val symmetricEcAlias = "${masterKeyAlias}_symmetric_ec"
+ val entry = keyStore.getEntry(symmetricEcAlias, null)
+ ?: throw GeneralSecurityException("Symmetric UDR key alias not found in Keystore: $symmetricEcAlias")
+ if (entry !is KeyStore.PrivateKeyEntry) {
+ throw GeneralSecurityException("Keystore entry is not a private key: $symmetricEcAlias")
+ }
+ return entry.privateKey
+ }
+
+ private fun hkdfDerive(ikm: ByteArray, salt: ByteArray, info: ByteArray): ByteArray {
+ return SafeHkdf.computeHkdf(ikm, salt, info, 32)
+ }
+
+
+ /**
+ * Intentionally overwrites (poisons) the residual CBOR (66-byte remnants)
+ * left in the Keystore2 / Binder IPC shared buffer with dummy data.
+ */
+ private fun flushKeystoreBinderBuffer(keystorePrivateKey: PrivateKey) {
+ try {
+ // Prepare dummy agreement by explicitly specifying AndroidKeyStore
+ val dummyAgreement = KeyAgreement.getInstance("ECDH", "AndroidKeyStore")
+ dummyAgreement.init(keystorePrivateKey)
+ dummyAgreement.doPhase(dummyPubKey, true)
+ //Do poisoning
+ val dummySecret = dummyAgreement.generateSecret()
+ dummySecret?.fill(0)
+
+ Log.d("KMD", "Binder buffer successfully poisoned.")
+ } catch (e: Exception) {
+ // Flush failures are only logged and do not impact the main decryption process
+ Log.w("KMD", "Binder buffer flush failed (ignored)", e)
+ }
+ }
+
+ /**
+ * Polls the device lock state multiple times to ensure accuracy.
+ */
+ private fun isDeviceLockedReliably(): Boolean {
+ val km = context.getSystemService(Context.KEYGUARD_SERVICE) as android.app.KeyguardManager
+ for (i in 1..lockStatePollCount) {
+ if (km.isDeviceLocked) return true
+ if (i < lockStatePollCount) {
+ try { Thread.sleep(lockStatePollIntervalMs) } catch (e: Exception) {}
+ }
+ }
+ return false
+ }
+
+ // --- AEAD Implementation (In-Memory) ---
+ private val rawHybridAead: Aead = object : Aead {
+ override fun encrypt(plaintext: ByteArray, associatedData: ByteArray): ByteArray {
+ // [FDP_DAR_EXT.2.4] If device is unlocked, prefer symmetric encryption (0x02)
+ if (!isDeviceLockedReliably()) {
+ try {
+ return encryptSymmetric(plaintext, associatedData)
+ } catch (e: Exception) {
+ Log.w("RawHybridKeyProvider", "Symmetric encryption failed, falling back to asymmetric", e)
+ }
+ }
+ return encryptAsymmetric(plaintext, associatedData)
+ }
+
+ private fun _encryptSymmetric(plaintext: ByteArray, associatedData: ByteArray): ByteArray {
+ var dekBytes = ByteArray(DEK_SIZE_BITS / 8)
+ var masterKey: Key? = null
+ var dekSpec: CleanSecretKeySpec? = null
+ val dataCipher: Cipher = Cipher.getInstance(DATA_CIPHER)
+
+ try {
+ SecureRandom().nextBytes(dekBytes)
+
+ //Test Code
+ for (i in 0..31 step 2) {
+ dekBytes[i] = (0x48).toByte()
+ dekBytes[i+1] = (0x04).toByte()
+ }
+
+ dekSpec = CleanSecretKeySpec(dekBytes, DEK_ALGORITHM)
+
+ dataCipher.init(Cipher.ENCRYPT_MODE, dekSpec)
+ dataCipher.updateAAD(associatedData)
+ val encryptedContent = dataCipher.doFinal(plaintext)
+ val dataIv = dataCipher.iv
+
+ masterKey = keyStore.getKey(symmetricMasterKeyAlias, null)
+ ?: throw GeneralSecurityException("Symmetric master key not found")
+ val wrapCipher = Cipher.getInstance(DEK_WRAPPING_CIPHER)
+ wrapCipher.init(Cipher.ENCRYPT_MODE, masterKey)
+ val wrappedDek = wrapCipher.doFinal(dekBytes)
+ val wrapIv = wrapCipher.iv
+
+ return serializeEncryptedPackage(MAGIC_BYTE_SYMMETRIC, null, wrappedDek, wrapIv, encryptedContent, dataIv)
+ } finally {
+ SecurityAuditLogger.logLine( "===== Encrypt symmetric =====")
+ //masterKey should be null at this point
+ SecurityAuditLogger.logKeyMaterial("Symmetric UDR Key (used as KEK)", masterKey?.encoded)
+ SecurityAuditLogger.logKeyMaterial("Data Encryption Key (DEK)", dekBytes)
+
+
+ dekSpec?.let {
+ if (!it.isDestroyed) {
+ it.destroy()
+ }
+ }
+ dekBytes.fill(0)
+
+ try {
+ val dummyZeroKey = SecretKeySpec(ByteArray(32), "AES") // All-zero dummy key
+ dataCipher.init(Cipher.ENCRYPT_MODE, dummyZeroKey) // Force overwrite of internal state
+ } catch (e: Exception) {
+ // Ignore any exceptions (solely for memory clearing purposes)
+ }
+ //flushKeystoreIpcBuffers()
+
+ }
+ }
+
+ private fun encryptSymmetric(plaintext: ByteArray, associatedData: ByteArray): ByteArray {
+ val recipientPubKey = loadSymmetricPublicKey()
+ val dekBytes = ByteArray(DEK_SIZE_BITS / 8)
+ var sharedSecret: ByteArray? = null
+ var kekBytes: ByteArray? = null
+ var ephemeralKeyPair: KeyPair? = null
+
+ var dekSpec: CleanSecretKeySpec? = null
+ var kekSpec: CleanSecretKeySpec? = null
+
+ try {
+ SecureRandom().nextBytes(dekBytes)
+ dekSpec = CleanSecretKeySpec(dekBytes, DEK_ALGORITHM)
+ val dataCipher = Cipher.getInstance(DATA_CIPHER)
+ dataCipher.init(Cipher.ENCRYPT_MODE, dekSpec)
+ dataCipher.updateAAD(associatedData)
+ val encryptedContent = dataCipher.doFinal(plaintext)
+ val dataIv = dataCipher.iv
+ val ephemeralKpg = KeyPairGenerator.getInstance(EC_KEY_ALGORITHM).apply { initialize(ECGenParameterSpec("secp521r1")) }
+ val keyPair = ephemeralKpg.generateKeyPair()
+ ephemeralKeyPair = keyPair
+
+
+ val keyAgreement = KeyAgreement.getInstance(KEY_AGREEMENT_ALGORITHM)
+ keyAgreement.init(keyPair.private)
+
+ keyAgreement.doPhase(recipientPubKey, true)
+ sharedSecret = keyAgreement.generateSecret()
+
+ // Use masterKeyAlias + "_symmetric" for context to distinguish from asymmetric HKDF context
+ val contextString = "${masterKeyAlias}_symmetric_ec"
+ kekBytes =
+ hkdfDerive(
+ sharedSecret!!,
+ contextString.toByteArray(Charsets.UTF_8),
+ keyPair.public.encoded
+ )
+
+ kekSpec = CleanSecretKeySpec(kekBytes, DEK_ALGORITHM)
+
+ val wrapCipher = Cipher.getInstance(DEK_WRAPPING_CIPHER)
+ wrapCipher.init(Cipher.ENCRYPT_MODE, kekSpec)
+ val wrappedDek = wrapCipher.doFinal(dekBytes)
+ val wrapIv = wrapCipher.iv
+
+ return serializeEncryptedPackage(
+ MAGIC_BYTE_SYMMETRIC,
+ keyPair.public.encoded,
+ wrappedDek,
+ wrapIv,
+ encryptedContent,
+ dataIv
+ )
+
+ } finally {
+ SecurityAuditLogger.logLine("===== Encrypt symmetric (Solution 2 - ECDH) =====")
+ SecurityAuditLogger.logKeyMaterial("Ephemeral Key Pair Public Key", ephemeralKeyPair?.public?.encoded)
+ val ephPrivBytes = ephemeralKeyPair?.private?.encoded
+ SecurityAuditLogger.logKeyMaterial("Ephemeral Key Pair Private Key", ephPrivBytes)
+ ephPrivBytes?.fill(0)//Have to clear just for this logging
+ SecurityAuditLogger.logKeyMaterial("Recipient UDR Key Pair (Public Key)", recipientPubKey.encoded)
+ SecurityAuditLogger.logKeyMaterial("Shared Secret", sharedSecret)
+ SecurityAuditLogger.logKeyMaterial("Symmetric KEK", kekBytes)
+ SecurityAuditLogger.logKeyMaterial("Data Encryption Key (DEK)", dekBytes)
+
+ dekBytes.fill(0)
+ sharedSecret?.fill(0)
+ kekBytes?.fill(0)
+
+ dekSpec?.let { if (!it.isDestroyed) it.destroy() }
+ kekSpec?.let { if (!it.isDestroyed) it.destroy() }
+ }
+ }
+
+ private fun encryptAsymmetric(plaintext: ByteArray, associatedData: ByteArray): ByteArray {
+ val recipientPubKey = loadRecipientPublicKey()
+ val dekBytes = ByteArray(DEK_SIZE_BITS / 8)
+ var sharedSecret: ByteArray? = null
+ var kekBytes: ByteArray? = null
+ var ephemeralKeyPair: KeyPair? = null
+
+ var dekSpec: CleanSecretKeySpec? = null
+ var kekSpec: CleanSecretKeySpec? = null
+
+ try {
+ SecureRandom().nextBytes(dekBytes)
+ dekSpec = CleanSecretKeySpec(dekBytes, DEK_ALGORITHM)
+ val dataCipher = Cipher.getInstance(DATA_CIPHER)
+ dataCipher.init(Cipher.ENCRYPT_MODE, dekSpec)
+ dataCipher.updateAAD(associatedData)
+ val encryptedContent = dataCipher.doFinal(plaintext)
+ val dataIv = dataCipher.iv
+ val ephemeralKpg = KeyPairGenerator.getInstance(EC_KEY_ALGORITHM).apply { initialize(ECGenParameterSpec("secp521r1")) }
+ //TSF does not store the ephemeral private key and relies on JVM object scope for transient cleanup
+ val keyPair = ephemeralKpg.generateKeyPair()
+
+ ephemeralKeyPair = keyPair
+
+ val keyAgreement = KeyAgreement.getInstance(KEY_AGREEMENT_ALGORITHM)
+ keyAgreement.init(keyPair.private)
+
+ keyAgreement.doPhase(recipientPubKey, true)
+ sharedSecret = keyAgreement.generateSecret()
+ kekBytes =
+ hkdfDerive(
+ sharedSecret!!,
+ masterKeyAlias.toByteArray(Charsets.UTF_8),
+ keyPair.public.encoded
+ )
+
+ kekSpec = CleanSecretKeySpec(kekBytes!!, DEK_ALGORITHM)
+
+ val wrapCipher = Cipher.getInstance(DEK_WRAPPING_CIPHER)
+ wrapCipher.init(Cipher.ENCRYPT_MODE, kekSpec)
+ val wrappedDek = wrapCipher.doFinal(dekBytes)
+ val wrapIv = wrapCipher.iv
+
+ return serializeEncryptedPackage(
+ MAGIC_BYTE_ASYMMETRIC,
+ keyPair.public.encoded,
+ wrappedDek,
+ wrapIv,
+ encryptedContent,
+ dataIv
+ )
+
+ } finally {
+ SecurityAuditLogger.logLine( "===== Encrypt asymmetric =====")
+ SecurityAuditLogger.logKeyMaterial("Ephemeral Key Pair Public Key", ephemeralKeyPair?.public?.encoded)
+ val ephPrivBytes = ephemeralKeyPair?.private?.encoded
+ SecurityAuditLogger.logKeyMaterial("Ephemeral Key Pair Private Key", ephPrivBytes)
+ ephPrivBytes?.fill(0)
+ SecurityAuditLogger.logKeyMaterial("Recipient UDR Key Pair (Public Key)", recipientPubKey.encoded)
+
+ SecurityAuditLogger.logKeyMaterial("Shared Secret", sharedSecret)
+ SecurityAuditLogger.logKeyMaterial("Asymmetric KEK", kekBytes)
+ SecurityAuditLogger.logKeyMaterial("Data Encryption Key (DEK)", dekBytes)
+
+ // [FCS_CKM_EXT.4] Explicit zeroization: Prevent key remanence in memory
+ dekBytes.fill(0); sharedSecret?.fill(0); kekBytes?.fill(0)
+
+ dekSpec?.let {
+ if (!it.isDestroyed) {
+ it.destroy()
+ }
+ }
+ kekSpec?.let {
+ if (!it.isDestroyed) {
+ it.destroy()
+ }
+ }
+ }
+ }
+
+ override fun decrypt(ciphertext: ByteArray, associatedData: ByteArray): ByteArray {
+ val pkg = deserializeEncryptedPackage(ciphertext)
+ var dekBytes: ByteArray? = null
+ var sharedSecret: ByteArray? = null
+ var kekBytes: ByteArray? = null
+ var recipientPrivateKey:Key? = null
+
+ var dekSpec: CleanSecretKeySpec? = null
+ var kekSpec: CleanSecretKeySpec? = null
+
+ val dataCipher = Cipher.getInstance(DATA_CIPHER)
+ val unwrapCipher = Cipher.getInstance(DEK_WRAPPING_CIPHER)
+ try {
+ if (pkg.magicByte == MAGIC_BYTE_ASYMMETRIC) {
+ recipientPrivateKey = loadRecipientPrivateKey()
+ val ephemeralPubKeySpec = X509EncodedKeySpec(pkg.ephemeralPublicKeyBytes!!)
+ val ephemeralPublicKey = KeyFactory.getInstance(EC_KEY_ALGORITHM).generatePublic(ephemeralPubKeySpec)
+
+ val keyAgreement = KeyAgreement.getInstance(KEY_AGREEMENT_ALGORITHM)
+ keyAgreement.init(recipientPrivateKey!!)
+ keyAgreement.doPhase(ephemeralPublicKey, true)
+ sharedSecret = keyAgreement.generateSecret()
+ flushKeystoreBinderBuffer(recipientPrivateKey)
+
+ kekBytes = hkdfDerive(sharedSecret!!, masterKeyAlias.toByteArray(Charsets.UTF_8), pkg.ephemeralPublicKeyBytes!!)
+ kekSpec = CleanSecretKeySpec(kekBytes!!, DEK_ALGORITHM)
+
+ unwrapCipher.init(Cipher.DECRYPT_MODE, kekSpec, GCMParameterSpec(GCM_TAG_LENGTH_BITS, pkg.wrapIv))
+ dekBytes = unwrapCipher.doFinal(pkg.wrappedDek)
+
+ } else if (pkg.magicByte == MAGIC_BYTE_SYMMETRIC) {
+ recipientPrivateKey = loadSymmetricRecipientPrivateKey()
+ val ephemeralPubKeySpec = X509EncodedKeySpec(pkg.ephemeralPublicKeyBytes!!)
+ val ephemeralPublicKey = KeyFactory.getInstance(EC_KEY_ALGORITHM).generatePublic(ephemeralPubKeySpec)
+
+ val keyAgreement = KeyAgreement.getInstance(KEY_AGREEMENT_ALGORITHM)
+ keyAgreement.init(recipientPrivateKey!!)
+ keyAgreement.doPhase(ephemeralPublicKey, true)
+ sharedSecret = keyAgreement.generateSecret()
+ flushKeystoreBinderBuffer(recipientPrivateKey)
+
+ val contextString = "${masterKeyAlias}_symmetric_ec"
+ kekBytes = hkdfDerive(sharedSecret!!, contextString.toByteArray(Charsets.UTF_8), pkg.ephemeralPublicKeyBytes!!)
+ kekSpec = CleanSecretKeySpec(kekBytes!!, DEK_ALGORITHM)
+
+ unwrapCipher.init(Cipher.DECRYPT_MODE, kekSpec, GCMParameterSpec(GCM_TAG_LENGTH_BITS, pkg.wrapIv))
+ dekBytes = unwrapCipher.doFinal(pkg.wrappedDek)
+ } else {
+ throw IllegalArgumentException("Unsupported magic byte")
+ }
+
+ dekSpec = CleanSecretKeySpec(dekBytes, DEK_ALGORITHM)
+ dataCipher.init(Cipher.DECRYPT_MODE, dekSpec, GCMParameterSpec(GCM_TAG_LENGTH_BITS, pkg.dataIv))
+ dataCipher.updateAAD(associatedData)
+
+ return dataCipher.doFinal(pkg.encryptedContent)
+ } finally {
+ // [FCS_CKM_EXT.4] Explicit zeroization: Prevent key remanence in memory
+ if(pkg.magicByte == MAGIC_BYTE_ASYMMETRIC) {
+ //Basically this line would not be passed.
+ SecurityAuditLogger.logLine( "===== Decrypt asymmetric =====")
+ //Private Key should be null
+ SecurityAuditLogger.logKeyMaterial("Recipient UDR Key Pair (Private Key)",
+ recipientPrivateKey?.encoded);
+ SecurityAuditLogger.logKeyMaterial("Shared Secret", sharedSecret)
+ SecurityAuditLogger.logKeyMaterial("Asymmetric KEK", kekBytes)
+ SecurityAuditLogger.logKeyMaterial("Data Encryption Key (DEK)", dekBytes)
+ pkg.ephemeralPublicKeyBytes?.fill(0)
+ } else {
+ SecurityAuditLogger.logLine( "===== Decrypt symmetric =====")
+ val masterKey = keyStore.getKey(symmetricMasterKeyAlias, null)
+ SecurityAuditLogger.logKeyMaterial("Symmetric UDR Key (used as KEK)", masterKey?.encoded)
+ SecurityAuditLogger.logKeyMaterial("DEK", dekBytes)
+ SecurityAuditLogger.logKeyMaterial("KEK", kekBytes)
+ SecurityAuditLogger.logKeyMaterial("Shared Secret", sharedSecret)
+ }
+
+ dekBytes?.fill(0)
+ kekBytes?.fill(0)
+ sharedSecret?.fill(0)
+
+ dekSpec?.let {
+ if (!it.isDestroyed) {
+ it.destroy()
+ }
+ }
+ kekSpec?.let {
+ if (!it.isDestroyed) {
+ it.destroy()
+ }
+ }
+
+ try {
+ // Use 'trackbreadcrumbs' or all-zeros as preferred!
+ val dummyZeroKey = SecretKeySpec(ByteArray(32), "AES")
+
+ // Random IV generation to completely avoid 'IV reuse error' in GCM mode
+ val dummyIv = ByteArray(12)
+ java.security.SecureRandom().nextBytes(dummyIv)
+ val dummyParams = GCMParameterSpec(128, dummyIv)
+
+ // Wipe the internal cache (DEK) of dataCipher
+ dataCipher.init(Cipher.ENCRYPT_MODE, dummyZeroKey, dummyParams)
+
+ // Also wipe the internal cache (KEK) of unwrapCipher!
+ unwrapCipher?.init(Cipher.ENCRYPT_MODE, dummyZeroKey, dummyParams)
+
+ } catch (e: Exception) {
+ android.util.Log.w("NiapSecAudit", "Wipe hack failed (ignored): ${e.message}")
+ }
+ //flushKeystoreIpcBuffers()
+
+ }
+ }
+ }
+
+ // --- StreamingAead Implementation ---
+ private val rawHybridStreamingAead: StreamingAead = object : StreamingAead {
+ override fun newEncryptingChannel(
+ ciphertextDestination: WritableByteChannel?,
+ associatedData: ByteArray?
+ ): WritableByteChannel? {
+ TODO("Not yet implemented")
+ }
+
+ override fun newSeekableDecryptingChannel(
+ ciphertextSource: SeekableByteChannel?,
+ associatedData: ByteArray?
+ ): SeekableByteChannel? {
+ TODO("Not yet implemented")
+ }
+
+ override fun newDecryptingChannel(
+ ciphertextSource: ReadableByteChannel?,
+ associatedData: ByteArray?
+ ): ReadableByteChannel? {
+ TODO("Not yet implemented")
+ }
+
+ override fun newEncryptingStream(ciphertext: OutputStream, associatedData: ByteArray): OutputStream {
+ // [FDP_DAR_EXT.2.4] If device is unlocked, prefer symmetric encryption (0x02)
+ if (!isDeviceLockedReliably()) {
+ try {
+ return newEncryptingStreamSymmetric(ciphertext, associatedData)
+ } catch (e: Exception) {
+ Log.w("RawHybridKeyProvider", "Symmetric stream encryption failed, falling back to asymmetric", e)
+ }
+ }
+ return newEncryptingStreamAsymmetric(ciphertext, associatedData)
+ }
+
+ /**
+ * WARNING: This symmetric stream encryption is currently unsafe due to an Android Keystore2
+ * bug causing memory leakage of the plaintext DEK. This should be treated as a known risk
+ * until native hardware-backed streaming encryption is supported without exposing the software DEK.
+ */
+ private fun newEncryptingStreamSymmetric(ciphertext: OutputStream, associatedData: ByteArray): OutputStream {
+ val dekBytes = ByteArray(DEK_SIZE_BITS / 8)
+ var masterKey: Key? = null
+ var dekSpec: CleanSecretKeySpec? = null
+
+ try {
+ SecureRandom().nextBytes(dekBytes)
+ dekSpec = CleanSecretKeySpec(dekBytes, DEK_ALGORITHM)
+
+ masterKey = keyStore.getKey(symmetricMasterKeyAlias, null)
+ ?: throw GeneralSecurityException("Symmetric master key not found")
+ val wrapCipher = Cipher.getInstance(DEK_WRAPPING_CIPHER)
+ wrapCipher.init(Cipher.ENCRYPT_MODE, masterKey)
+ val wrappedDek = wrapCipher.doFinal(dekBytes)
+ val wrapIv = wrapCipher.iv
+
+ val dataCipher = Cipher.getInstance(DATA_CIPHER)
+ dataCipher.init(Cipher.ENCRYPT_MODE, dekSpec)
+ dataCipher.updateAAD(associatedData)
+ val dataIv = dataCipher.iv
+
+ val dos = DataOutputStream(ciphertext)
+ dos.writeByte(MAGIC_BYTE_SYMMETRIC.toInt())
+ dos.writeInt(wrappedDek.size)
+ dos.write(wrappedDek)
+ dos.writeInt(wrapIv.size)
+ dos.write(wrapIv)
+ dos.writeInt(dataIv.size)
+ dos.write(dataIv)
+ dos.flush()
+
+ // Do not zeroize IVs here, as they might be references to Cipher internal state depending on provider.
+ // Leave them for GC or explicit wipe on close if we can track it.
+
+ return CipherOutputStream(ciphertext, dataCipher)
+ } finally {
+ SecurityAuditLogger.logLine("===== Stream Encrypt symmetric =====")
+ SecurityAuditLogger.logKeyMaterial("Symmetric UDR Key (used as KEK)", masterKey?.encoded)
+ SecurityAuditLogger.logKeyMaterial("Data Encryption Key (DEK)", dekBytes)
+ dekBytes.fill(0)
+ // [FCS_CKM_EXT.4] & [FCS_STG_EXT.2] PREMATURE ZEROIZATION FIX: Do not destroy the key before stream is read.
+ // we should destroy it on close() of the stream.
+ // dekSpec?.let {
+ // if (!it.isDestroyed) {
+ // it.destroy()
+ // }
+ // }
+ }
+ }
+
+ private fun newEncryptingStreamAsymmetric(ciphertext: OutputStream, associatedData: ByteArray): OutputStream {
+ val recipientPubKey = loadRecipientPublicKey()
+ val dekBytes = ByteArray(DEK_SIZE_BITS / 8)
+ var sharedSecret: ByteArray? = null
+ var kekBytes: ByteArray? = null
+ var ephemeralKeyPair: KeyPair? = null
+
+ var dekSpec: CleanSecretKeySpec? = null
+ var kekSpec: CleanSecretKeySpec? = null
+
+ try {
+ SecureRandom().nextBytes(dekBytes)
+ dekSpec = CleanSecretKeySpec(dekBytes, DEK_ALGORITHM)
+
+ val ephemeralKpg = KeyPairGenerator.getInstance(EC_KEY_ALGORITHM).apply { initialize(ECGenParameterSpec("secp521r1")) }
+val keyPair = ephemeralKpg.generateKeyPair()
+
+ephemeralKeyPair = keyPair
+
+
+ val keyAgreement = KeyAgreement.getInstance(KEY_AGREEMENT_ALGORITHM)
+keyAgreement.init(keyPair.private)
+
+ keyAgreement.doPhase(recipientPubKey, true)
+ sharedSecret = keyAgreement.generateSecret()
+
+kekBytes =
+ hkdfDerive(
+ sharedSecret!!,
+ masterKeyAlias.toByteArray(Charsets.UTF_8),
+ keyPair.public.encoded
+ )
+
+ kekSpec = CleanSecretKeySpec(kekBytes, DEK_ALGORITHM)
+
+ val wrapCipher = Cipher.getInstance(DEK_WRAPPING_CIPHER)
+ wrapCipher.init(Cipher.ENCRYPT_MODE, kekSpec)
+ val wrappedDek = wrapCipher.doFinal(dekBytes)
+ val wrapIv = wrapCipher.iv
+
+ val dataCipher = Cipher.getInstance(DATA_CIPHER)
+ dataCipher.init(Cipher.ENCRYPT_MODE, dekSpec)
+ dataCipher.updateAAD(associatedData)
+ val dataIv = dataCipher.iv
+
+ // Write Header directly to the output stream
+ val dos = DataOutputStream(ciphertext)
+ dos.writeByte(MAGIC_BYTE_ASYMMETRIC.toInt())
+val ephKeyBytes = keyPair.public.encoded
+
+ dos.writeInt(ephKeyBytes.size)
+ dos.write(ephKeyBytes)
+ dos.writeInt(wrappedDek.size)
+ dos.write(wrappedDek)
+ dos.writeInt(wrapIv.size)
+ dos.write(wrapIv)
+ dos.writeInt(dataIv.size)
+ dos.write(dataIv)
+ dos.flush()
+
+
+ return CipherOutputStream(ciphertext, dataCipher)
+ } finally {
+ SecurityAuditLogger.logLine("===== Stream Encrypt asymmetric =====")
+ SecurityAuditLogger.logKeyMaterial("Ephemeral Key Pair Public Key", ephemeralKeyPair?.public?.encoded)
+ val ephPrivBytes = ephemeralKeyPair?.private?.encoded
+
+ SecurityAuditLogger.logKeyMaterial("Ephemeral Key Pair Private Key", ephPrivBytes)
+
+ ephPrivBytes?.fill(0)
+
+ SecurityAuditLogger.logKeyMaterial("Recipient UDR Key Pair (Public Key)", recipientPubKey.encoded)
+ SecurityAuditLogger.logKeyMaterial("Shared Secret", sharedSecret)
+ SecurityAuditLogger.logKeyMaterial("Asymmetric KEK", kekBytes)
+ SecurityAuditLogger.logKeyMaterial("Data Encryption Key (DEK)", dekBytes)
+ dekBytes.fill(0); sharedSecret?.fill(0); kekBytes?.fill(0)
+
+ dekSpec?.let { if (!it.isDestroyed) it.destroy() }
+
+ kekSpec?.let { if (!it.isDestroyed) it.destroy() }
+
+ }
+ }
+
+ /**
+ * WARNING: This stream decryption is currently unsafe due to an Android Keystore2
+ * bug causing memory leakage of the plaintext DEK.
+ */
+ override fun newDecryptingStream(ciphertext: InputStream, associatedData: ByteArray): InputStream {
+ val dis = DataInputStream(ciphertext)
+ val magicByte = dis.readByte()
+ var dekBytes: ByteArray? = null
+
+ var dekSpec: CleanSecretKeySpec? = null
+ var kekSpec: CleanSecretKeySpec? = null
+ try {
+ if (magicByte == MAGIC_BYTE_ASYMMETRIC) {
+ val recipientPrivateKey = loadRecipientPrivateKey()
+ val ephKeyLen = dis.readInt()
+ val ephKeyBytes = ByteArray(ephKeyLen).apply { dis.readFully(this) }
+ val ephemeralPublicKey = KeyFactory.getInstance(EC_KEY_ALGORITHM).generatePublic(X509EncodedKeySpec(ephKeyBytes))
+
+ val wrapDekLen = dis.readInt()
+ val wrappedDek = ByteArray(wrapDekLen).apply { dis.readFully(this) }
+
+ val wrapIvLen = dis.readInt()
+ val wrapIv = ByteArray(wrapIvLen).apply { dis.readFully(this) }
+
+ val dataIvLen = dis.readInt()
+ val dataIv = ByteArray(dataIvLen).apply { dis.readFully(this) }
+
+ var sharedSecret: ByteArray? = null
+ var kekBytes: ByteArray? = null
+
+
+ try {
+ val keyAgreement = KeyAgreement.getInstance(KEY_AGREEMENT_ALGORITHM)
+ keyAgreement.init(recipientPrivateKey!!)
+ keyAgreement.doPhase(ephemeralPublicKey, true)
+ sharedSecret = keyAgreement.generateSecret()
+
+ kekBytes = hkdfDerive(sharedSecret!!, masterKeyAlias.toByteArray(Charsets.UTF_8), ephKeyBytes)
+ kekSpec = CleanSecretKeySpec(kekBytes!!, DEK_ALGORITHM)
+
+ val unwrapCipher = Cipher.getInstance(DEK_WRAPPING_CIPHER)
+ unwrapCipher.init(Cipher.DECRYPT_MODE, kekSpec, GCMParameterSpec(GCM_TAG_LENGTH_BITS, wrapIv))
+ dekBytes = unwrapCipher.doFinal(wrappedDek)
+
+ val dataCipher = Cipher.getInstance(DATA_CIPHER)
+ dekSpec = CleanSecretKeySpec(dekBytes, DEK_ALGORITHM)
+ dataCipher.init(Cipher.DECRYPT_MODE, dekSpec, GCMParameterSpec(GCM_TAG_LENGTH_BITS, dataIv))
+ dataCipher.updateAAD(associatedData)
+
+ return CipherInputStream(ciphertext, dataCipher)
+ } finally {
+ SecurityAuditLogger.logLine("===== Stream Decrypt asymmetric =====")
+ SecurityAuditLogger.logKeyMaterial("Recipient UDR Key Pair (Private Key)", recipientPrivateKey.encoded)
+ SecurityAuditLogger.logKeyMaterial("Shared Secret", sharedSecret)
+ SecurityAuditLogger.logKeyMaterial("Asymmetric KEK", kekBytes)
+ SecurityAuditLogger.logKeyMaterial("Data Encryption Key (DEK)", dekBytes)
+ ephKeyBytes.fill(0);sharedSecret?.fill(0);
+ kekBytes?.fill(0);dekBytes?.fill(0)
+
+ // [FCS_CKM_EXT.4] & [FCS_STG_EXT.2] PREMATURE ZEROIZATION FIX: Do not destroy the key before stream is read.
+ // we should destroy it on close() of the stream.
+ // dekSpec?.let {
+ // if (!it.isDestroyed) {
+ // it.destroy()
+ // }
+ // }
+ kekSpec?.let {
+ if (!it.isDestroyed) {
+ it.destroy()
+ }
+ }
+ }
+ } else if (magicByte == MAGIC_BYTE_SYMMETRIC) {
+ try {
+ val wrapDekLen = dis.readInt()
+ val wrappedDek = ByteArray(wrapDekLen).apply { dis.readFully(this) }
+
+ val wrapIvLen = dis.readInt()
+ val wrapIv = ByteArray(wrapIvLen).apply { dis.readFully(this) }
+
+ val dataIvLen = dis.readInt()
+ val dataIv = ByteArray(dataIvLen).apply { dis.readFully(this) }
+
+ val masterKey = keyStore.getKey(symmetricMasterKeyAlias, null)
+ ?: throw GeneralSecurityException("Symmetric master key not found")
+ val unwrapCipher = Cipher.getInstance(DEK_WRAPPING_CIPHER)
+ unwrapCipher.init(
+ Cipher.DECRYPT_MODE,
+ masterKey,
+ GCMParameterSpec(GCM_TAG_LENGTH_BITS, wrapIv)
+ )
+ dekBytes = unwrapCipher.doFinal(wrappedDek)
+
+ val dataCipher = Cipher.getInstance(DATA_CIPHER)
+ dekSpec = CleanSecretKeySpec(dekBytes, DEK_ALGORITHM)
+ dataCipher.init(
+ Cipher.DECRYPT_MODE,
+ dekSpec,
+ GCMParameterSpec(GCM_TAG_LENGTH_BITS, dataIv)
+ )
+ dataCipher.updateAAD(associatedData)
+
+ return CipherInputStream(ciphertext, dataCipher)
+ } finally {
+ SecurityAuditLogger.logLine("===== Stream Decrypt symmetric =====")
+ SecurityAuditLogger.logKeyMaterial("Symmetric UDR Key (used as KEK)",
+ keyStore.getKey(symmetricMasterKeyAlias, null)?.encoded)
+ SecurityAuditLogger.logKeyMaterial("Data Encryption Key (DEK)", dekBytes)
+ dekBytes?.fill(0)
+
+ // [FCS_CKM_EXT.4] & [FCS_STG_EXT.2] PREMATURE ZEROIZATION FIX: Do not destroy the key before stream is read.
+ // we should destroy it on close() of the stream.
+ // dekSpec?.let {
+ // if (!it.isDestroyed) {
+ // it.destroy()
+ // }
+ // }
+ }
+ } else {
+ throw IllegalArgumentException("Unsupported magic byte: $magicByte")
+ }
+ } catch (e: Exception) {
+ throw e
+ }
+ }
+ }
+
+ override fun getAead(): Aead = rawHybridAead
+ override fun getStreamingAead(): StreamingAead = rawHybridStreamingAead
+ override fun getUnlockDeviceRequired(): Boolean = unlockedDeviceRequired
+ override fun rewrapKeyToSymmetricUdr(encryptedDek: ByteArray): ByteArray {
+
+ val pkg = deserializeEncryptedPackage(encryptedDek)
+ if (pkg.magicByte == MAGIC_BYTE_SYMMETRIC) return encryptedDek
+
+ var dekBytes: ByteArray? = null
+ var newWrappedDek: ByteArray? = null
+ var newWrapIv: ByteArray? = null
+ var symmetricSharedSecret: ByteArray? = null
+ var symmetricKekBytes: ByteArray? = null
+ var symmetricKekSpec: CleanSecretKeySpec? = null
+ var ephemeralPublicKeyBytes: ByteArray? = null
+
+ try {
+ // 1. Decrypt existing asymmetric wrapper to get DEK
+ val recipientPrivateKey = loadRecipientPrivateKey()
+ val ephemeralPubKeySpec = X509EncodedKeySpec(pkg.ephemeralPublicKeyBytes!!)
+ val ephemeralPublicKey = KeyFactory.getInstance(EC_KEY_ALGORITHM).generatePublic(ephemeralPubKeySpec)
+ var sharedSecret: ByteArray? = null
+ var kekBytes: ByteArray? = null
+ var kekSpec: CleanSecretKeySpec? = null
+ try {
+ val keyAgreement = KeyAgreement.getInstance(KEY_AGREEMENT_ALGORITHM)
+ keyAgreement.init(recipientPrivateKey!!)
+ keyAgreement.doPhase(ephemeralPublicKey, true)
+ sharedSecret = keyAgreement.generateSecret()
+ kekBytes = hkdfDerive(sharedSecret!!, masterKeyAlias.toByteArray(Charsets.UTF_8), pkg.ephemeralPublicKeyBytes!!)
+ kekSpec = CleanSecretKeySpec(kekBytes, DEK_ALGORITHM)
+ val unwrapCipher = Cipher.getInstance(DEK_WRAPPING_CIPHER)
+ unwrapCipher.init(Cipher.DECRYPT_MODE, kekSpec, GCMParameterSpec(GCM_TAG_LENGTH_BITS, pkg.wrapIv))
+ dekBytes = unwrapCipher.doFinal(pkg.wrappedDek)
+ } finally {
+ SecurityAuditLogger.logLine("===== Rewrap: Decrypt asymmetric phase =====")
+ SecurityAuditLogger.logKeyMaterial("Recipient UDR Key Pair (Private Key)", recipientPrivateKey.encoded)
+ SecurityAuditLogger.logKeyMaterial("Shared Secret", sharedSecret)
+ SecurityAuditLogger.logKeyMaterial("Asymmetric KEK", kekBytes)
+ sharedSecret?.fill(0);
+ kekBytes?.fill(0)
+
+ kekSpec?.let { if (!it.isDestroyed) it.destroy() }
+ }
+
+ // 2. Re-wrap DEK with symmetric master key (using ECDH as per new Solution 2)
+ val symmetricRecipientPubKey = loadSymmetricPublicKey()
+ val ephemeralKpg = KeyPairGenerator.getInstance(EC_KEY_ALGORITHM).apply { initialize(ECGenParameterSpec("secp521r1")) }
+ val keyPair = ephemeralKpg.generateKeyPair()
+
+ val keyAgreement = KeyAgreement.getInstance(KEY_AGREEMENT_ALGORITHM)
+ keyAgreement.init(keyPair.private)
+ keyAgreement.doPhase(symmetricRecipientPubKey, true)
+ symmetricSharedSecret = keyAgreement.generateSecret()
+
+ val contextString = "${masterKeyAlias}_symmetric_ec"
+ symmetricKekBytes = hkdfDerive(symmetricSharedSecret!!, contextString.toByteArray(Charsets.UTF_8), keyPair.public.encoded)
+ symmetricKekSpec = CleanSecretKeySpec(symmetricKekBytes!!, DEK_ALGORITHM)
+
+ val wrapCipher = Cipher.getInstance(DEK_WRAPPING_CIPHER)
+ wrapCipher.init(Cipher.ENCRYPT_MODE, symmetricKekSpec)
+ newWrappedDek = wrapCipher.doFinal(dekBytes)
+ newWrapIv = wrapCipher.iv
+ ephemeralPublicKeyBytes = keyPair.public.encoded
+
+ // 3. Return new package with symmetric magic byte and ephemeral public key
+ return serializeEncryptedPackage(
+ MAGIC_BYTE_SYMMETRIC,
+ ephemeralPublicKeyBytes,
+ newWrappedDek,
+ newWrapIv,
+ pkg.encryptedContent,
+ pkg.dataIv
+ )
+ } finally {
+ SecurityAuditLogger.logLine("===== Rewrap: Re-encrypt symmetric phase =====")
+ SecurityAuditLogger.logKeyMaterial("Symmetric Ephemeral Public Key", ephemeralPublicKeyBytes)
+ SecurityAuditLogger.logKeyMaterial("Symmetric Shared Secret", symmetricSharedSecret)
+ SecurityAuditLogger.logKeyMaterial("Symmetric KEK", symmetricKekBytes)
+ SecurityAuditLogger.logKeyMaterial("Data Encryption Key (DEK)", dekBytes)
+
+ dekBytes?.fill(0)
+ newWrappedDek?.fill(0)
+ newWrapIv?.fill(0)
+ symmetricSharedSecret?.fill(0)
+ symmetricKekBytes?.fill(0)
+
+ symmetricKekSpec?.let { if (!it.isDestroyed) it.destroy() }
+ }
+ }
+
+ override fun isSymmetricallyWrapped(encryptedDek: ByteArray): Boolean {
+ if (encryptedDek.isEmpty()) return false
+ return encryptedDek[0] == MAGIC_BYTE_SYMMETRIC
+ }
+
+ override fun destroy() {
+ // [FCS_CKM_EXT.4] & [FCS_STG_EXT.2] Secure deletion from persistent storage
+ try {
+ if (keyStore.containsAlias(masterKeyAlias)) {
+ keyStore.deleteEntry(masterKeyAlias)
+ }
+ if (keyStore.containsAlias(symmetricMasterKeyAlias)) {
+ keyStore.deleteEntry(symmetricMasterKeyAlias)
+ }
+ prefs.edit().clear().apply()
+ } catch (e: Exception) { }
+ }
+}
+
+private data class EncryptedPackage(
+ val magicByte: Byte,
+ val ephemeralPublicKeyBytes: ByteArray?,
+ val wrappedDek: ByteArray,
+ val wrapIv: ByteArray,
+ val encryptedContent: ByteArray,
+ val dataIv: ByteArray
+)
+
+private fun serializeEncryptedPackage(magicByte: Byte, ephemeralPublicKeyBytes: ByteArray?, wrappedDek: ByteArray, wrapIv: ByteArray, encryptedContent: ByteArray, dataIv: ByteArray): ByteArray {
+ val bos = ByteArrayOutputStream()
+ DataOutputStream(bos).use {
+ it.writeByte(magicByte.toInt())
+ // WORKAROUND [FCS_CKM_EXT.4] Keystore2 Leak Fix: Both Asymmetric AND Symmetric modes now use ECDH
+ // (Hybrid Envelope Encryption) to avoid raw DEK exposure in Binder IPC.
+ if (magicByte == RawHybridKeyProvider.MAGIC_BYTE_ASYMMETRIC || magicByte == RawHybridKeyProvider.MAGIC_BYTE_SYMMETRIC) {
+ val ephKey = ephemeralPublicKeyBytes ?: throw IllegalArgumentException("Ephemeral public key required for ECDH mode")
+ it.writeInt(ephKey.size)
+ it.write(ephKey)
+ }
+ it.writeInt(wrappedDek.size)
+ it.write(wrappedDek)
+ it.writeInt(wrapIv.size)
+ it.write(wrapIv)
+ it.writeInt(dataIv.size)
+ it.write(dataIv)
+ it.write(encryptedContent)
+ }
+ return bos.toByteArray()
+}
+
+private fun deserializeEncryptedPackage(ciphertext: ByteArray): EncryptedPackage {
+ val buffer = ByteBuffer.wrap(ciphertext)
+
+ val magicByte = buffer.get()
+ var ephKey: ByteArray? = null
+
+ // WORKAROUND [FCS_CKM_EXT.4] Keystore2 Leak Fix: Both Asymmetric AND Symmetric modes now use ECDH
+ // (Hybrid Envelope Encryption) to avoid raw DEK exposure in Binder IPC.
+ if (magicByte == RawHybridKeyProvider.MAGIC_BYTE_ASYMMETRIC || magicByte == RawHybridKeyProvider.MAGIC_BYTE_SYMMETRIC) {
+ val ephKeySize = buffer.int
+ ephKey = ByteArray(ephKeySize).apply { buffer.get(this) }
+ } else {
+ throw IllegalArgumentException("Invalid magic byte or unsupported format: $magicByte")
+ }
+
+ val wrapDekSize = buffer.int
+ val wrapDek = ByteArray(wrapDekSize).apply { buffer.get(this) }
+ val wrapIvSize = buffer.int
+ val wrapIv = ByteArray(wrapIvSize).apply { buffer.get(this) }
+ val dataIvSize = buffer.int
+ val dataIv = ByteArray(dataIvSize).apply { buffer.get(this) }
+ val content = ByteArray(buffer.remaining()).apply { buffer.get(this) }
+ return EncryptedPackage(magicByte, ephKey, wrapDek, wrapIv, content, dataIv)
+}
diff --git a/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/internal/keymanagement/RawKeyProvider.kt b/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/internal/keymanagement/RawKeyProvider.kt
new file mode 100644
index 0000000..a7ef83a
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/internal/keymanagement/RawKeyProvider.kt
@@ -0,0 +1,150 @@
+/*
+* Copyright (C) 2026 The Android Open Source Project
+*
+* Licensed under the Apache License, Version 2.0 (the "License");
+* you may not use this file except in compliance with the License.
+* You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing, software
+* distributed under the License is distributed on an "AS IS" BASIS,
+* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+* See the License for the specific language governing permissions and
+* limitations under the License.
+*/
+
+package com.android.niapsec.encryption.internal.keymanagement
+
+import android.content.Context
+import android.security.keystore.KeyProperties
+import android.security.keystore.KeyProtection
+import android.util.Log
+import com.google.crypto.tink.Aead
+import java.nio.ByteBuffer
+import java.security.GeneralSecurityException
+import java.security.KeyStore
+import java.util.UUID
+import javax.crypto.Cipher
+import javax.crypto.KeyGenerator
+import javax.crypto.SecretKey
+import javax.crypto.spec.IvParameterSpec
+
+/**
+ * A KeyProvider that wraps the raw JCA Cipher API into a Tink-compatible Aead.
+ * This allows using the standard Android Keystore without the Tink library for key management.
+ */
+class RawKeyProvider(
+ private val context: Context,
+ private val keyAliasPrefix: String,
+ private val unlockedDeviceRequired: Boolean
+) : KeyProvider {
+ private val KEY_ALIAS_PREFIX = "raw_provider_key_${keyAliasPrefix}_"
+ private val ANDROID_KEYSTORE = "AndroidKeyStore"
+ private val KEY_ALGORITHM = KeyProperties.KEY_ALGORITHM_AES
+ private val BLOCK_MODE = KeyProperties.BLOCK_MODE_CBC
+ private val PADDING = KeyProperties.ENCRYPTION_PADDING_PKCS7
+ private val TRANSFORMATION = "$KEY_ALGORITHM/$BLOCK_MODE/$PADDING"
+
+ private val keyStore: KeyStore = KeyStore.getInstance(ANDROID_KEYSTORE).apply { load(null) }
+
+ private val rawAead: Aead = object : Aead {
+ override fun encrypt(plaintext: ByteArray, associatedData: ByteArray): ByteArray {
+ val keyAlias = KEY_ALIAS_PREFIX + UUID.randomUUID().toString()
+ val cipher = Cipher.getInstance(TRANSFORMATION)
+ val secretKey: SecretKey = generateEphemeralSoftwareKey(keyAlias)
+ cipher.init(Cipher.ENCRYPT_MODE, secretKey)
+
+ val spec = cipher.parameters.getParameterSpec(IvParameterSpec::class.java)
+ val iv = spec.iv
+ val aliasBytes = keyAlias.toByteArray(Charsets.UTF_8)
+
+ val header = ByteBuffer.allocate(4 + aliasBytes.size + 4 + iv.size)
+ .putInt(aliasBytes.size)
+ .put(aliasBytes)
+ .putInt(iv.size)
+ .put(iv)
+ .array()
+
+ val ciphertext = cipher.doFinal(plaintext)
+ return header + ciphertext
+ }
+
+ override fun decrypt(ciphertext: ByteArray, associatedData: ByteArray): ByteArray {
+ val buffer = ByteBuffer.wrap(ciphertext)
+
+ val aliasLength = buffer.int
+ if (aliasLength <= 0 || aliasLength > buffer.remaining()) throw GeneralSecurityException("Invalid alias length")
+ val aliasBytes = ByteArray(aliasLength)
+ buffer.get(aliasBytes)
+ val keyAlias = String(aliasBytes, Charsets.UTF_8)
+
+ val ivLength = buffer.int
+ if (ivLength <= 0 || ivLength > buffer.remaining()) throw GeneralSecurityException("Invalid IV length")
+ val iv = ByteArray(ivLength)
+ buffer.get(iv)
+
+ val cipher = Cipher.getInstance(TRANSFORMATION)
+
+ val actualCiphertext = ByteArray(buffer.remaining())
+ buffer.get(actualCiphertext)
+
+ val secretKey = getSecretKey(keyAlias)
+ val spec = IvParameterSpec(iv)
+ cipher.init(Cipher.DECRYPT_MODE, secretKey, spec)
+
+ return cipher.doFinal(actualCiphertext)
+ }
+ }
+
+ private fun generateEphemeralSoftwareKey(keyAlias: String): SecretKey {
+ val keyGenerator = KeyGenerator.getInstance(KEY_ALGORITHM, "AndroidOpenSSL")
+ keyGenerator.init(256)
+ val secretKey = keyGenerator.generateKey()
+ val secretKeyEntry = KeyStore.SecretKeyEntry(secretKey)
+
+ keyStore.setEntry(
+ keyAlias, secretKeyEntry,
+ KeyProtection.Builder((KeyProperties.PURPOSE_DECRYPT or KeyProperties.PURPOSE_ENCRYPT))
+ .setEncryptionPaddings(PADDING)
+ .setBlockModes(BLOCK_MODE)
+ .setUnlockedDeviceRequired(unlockedDeviceRequired)
+ .build()
+ )
+ return secretKey
+ }
+
+ private fun getSecretKey(keyAlias: String): SecretKey {
+ return keyStore.getKey(keyAlias, null) as SecretKey
+ }
+
+ override fun getUnlockDeviceRequired(): Boolean {
+ return unlockedDeviceRequired
+ }
+
+ override fun getAead(): Aead {
+ return rawAead
+ }
+
+ override fun rewrapKeyToSymmetricUdr(encryptedDek: ByteArray): ByteArray {
+ TODO("Not yet implemented")
+ }
+
+ override fun isSymmetricallyWrapped(encryptedDek: ByteArray): Boolean {
+ TODO("Not yet implemented")
+ }
+
+ override fun destroy() {
+ try {
+ val aliases = keyStore.aliases()
+ while (aliases.hasMoreElements()) {
+ val alias = aliases.nextElement()
+ if (alias.startsWith(KEY_ALIAS_PREFIX)) {
+ keyStore.deleteEntry(alias)
+ }
+ }
+ } catch (e: Exception) {
+ Log.e("RawKeyProvider", "Failed to destroy keys", e)
+ }
+ }
+}
diff --git a/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/tools/Asn1Helper.kt b/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/tools/Asn1Helper.kt
new file mode 100644
index 0000000..6731b03
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/tools/Asn1Helper.kt
@@ -0,0 +1,98 @@
+/*
+ * Copyright (C) 2026 The Android Open Source Project
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package com.android.niapsec.encryption.tools
+
+import java.io.ByteArrayOutputStream
+
+/**
+ * Lightweight helper to construct DER-encoded ASN.1 structures.
+ * Supports only basic types required for `WrappedKeyEntry` (SEQUENCE, OCTET_STRING, INTEGER).
+ */
+object Asn1Helper {
+
+ private const val TAG_INTEGER = 0x02.toByte()
+ private const val TAG_OCTET_STRING = 0x04.toByte()
+ private const val TAG_SEQUENCE = 0x30.toByte()
+
+ fun explicitTag(tagNum: Int, content: ByteArray): ByteArray {
+ val tagByte = (0xA0 or (tagNum and 0x1F)).toByte()
+ return encode(tagByte, content)
+ }
+
+ fun set(vararg elements: ByteArray): ByteArray {
+ val bos = ByteArrayOutputStream()
+ for (element in elements) {
+ bos.write(element)
+ }
+ return encode(0x31.toByte(), bos.toByteArray())
+ }
+
+ fun sequence(vararg elements: ByteArray): ByteArray {
+ val bos = ByteArrayOutputStream()
+ for (element in elements) {
+ bos.write(element)
+ }
+ return encode(TAG_SEQUENCE, bos.toByteArray())
+ }
+
+ fun octetString(content: ByteArray): ByteArray {
+ return encode(TAG_OCTET_STRING, content)
+ }
+
+ fun integer(value: Int): ByteArray {
+ val bos = ByteArrayOutputStream()
+ bos.write((value shr 24) and 0xFF)
+ bos.write((value shr 16) and 0xFF)
+ bos.write((value shr 8) and 0xFF)
+ bos.write(value and 0xFF)
+ var bytes = bos.toByteArray()
+
+ // Trim leading zeros if it's signed (0 padding needs to be careful if it's negative, but for simple use cases it's fine)
+ var start = 0
+ while (start < bytes.size - 1 && bytes[start] == 0.toByte()) {
+ start++
+ }
+ if (start > 0) {
+ bytes = bytes.copyOfRange(start, bytes.size)
+ }
+ return encode(TAG_INTEGER, bytes)
+ }
+
+ private fun encode(tag: Byte, content: ByteArray): ByteArray {
+ val bos = ByteArrayOutputStream()
+ bos.write(tag.toInt())
+ writeLength(bos, content.size)
+ bos.write(content)
+ return bos.toByteArray()
+ }
+
+ private fun writeLength(bos: ByteArrayOutputStream, length: Int) {
+ if (length < 128) {
+ bos.write(length)
+ } else {
+ val lengthBos = ByteArrayOutputStream()
+ var temp = length
+ while (temp > 0) {
+ lengthBos.write(temp and 0xFF)
+ temp = temp ushr 8
+ }
+ val lengthBytes = lengthBos.toByteArray().reversedArray()
+ bos.write(0x80 or lengthBytes.size)
+ bos.write(lengthBytes)
+ }
+ }
+}
diff --git a/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/tools/CleanSecretKeySpec.kt b/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/tools/CleanSecretKeySpec.kt
new file mode 100644
index 0000000..6698dcc
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/tools/CleanSecretKeySpec.kt
@@ -0,0 +1,53 @@
+/*
+ * Copyright (C) 2026 The Android Open Source Project
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package com.android.niapsec.encryption.tools
+
+import java.security.spec.KeySpec
+import javax.crypto.SecretKey
+
+/**
+ * Custom SecretKeySpec class that implements the Destroyable interface.
+ * Default SecretKeySpec has destroy() interface derived from SecretKey, but not implemented.
+ */
+class CleanSecretKeySpec(
+ key: ByteArray,
+ private val algorithm: String
+) : KeySpec, SecretKey{
+
+ private val keyMaterial: ByteArray = key.clone()
+ private var isDestroyedFlag: Boolean = false
+
+ override fun getAlgorithm(): String = algorithm
+
+ override fun getFormat(): String = "RAW"
+
+ override fun getEncoded(): ByteArray? {
+ if (isDestroyedFlag) {
+ throw IllegalStateException("This key has already been destroyed.")
+ }
+ return keyMaterial
+ }
+
+ override fun destroy() {
+ if (!isDestroyedFlag) {
+ keyMaterial.fill(0)
+ isDestroyedFlag = true
+ }
+ }
+
+ override fun isDestroyed(): Boolean = isDestroyedFlag
+}
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/tools/SafeHkdf.kt b/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/tools/SafeHkdf.kt
new file mode 100644
index 0000000..f129b96
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/tools/SafeHkdf.kt
@@ -0,0 +1,112 @@
+/*
+* Copyright (C) 2026 The Android Open Source Project
+*
+* Licensed under the Apache License, Version 2.0 (the "License");
+* you may not use this file except in compliance with the License.
+* You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing, software
+* distributed under the License is distributed on an "AS IS" BASIS,
+* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+* See the License for the specific language governing permissions and
+* limitations under the License.
+*/
+
+package com.android.niapsec.encryption.tools
+import java.io.ByteArrayOutputStream
+import java.security.MessageDigest
+import kotlin.math.ceil
+
+object SafeHkdf {
+ private const val SHA256_BLOCK_SIZE = 64
+ private const val SHA256_HASH_SIZE = 32
+
+ /**
+ * Computes HMAC-SHA256 using MessageDigest directly, without relying on JNI Mac.
+ */
+ private fun hmacSha256(key: ByteArray, data: ByteArray): ByteArray {
+ val md = MessageDigest.getInstance("SHA-256")
+ val paddedKey = ByteArray(SHA256_BLOCK_SIZE)
+
+ // Key padding based on HMAC specification
+ if (key.size > SHA256_BLOCK_SIZE) {
+ val hashedKey = md.digest(key)
+ System.arraycopy(hashedKey, 0, paddedKey, 0, hashedKey.size)
+ hashedKey.fill(0) // Immediately clear the intermediate buffer
+ } else {
+ System.arraycopy(key, 0, paddedKey, 0, key.size)
+ }
+
+ val oPad = ByteArray(SHA256_BLOCK_SIZE)
+ val iPad = ByteArray(SHA256_BLOCK_SIZE)
+
+ for (i in 0 until SHA256_BLOCK_SIZE) {
+ oPad[i] = (paddedKey[i].toInt() xor 0x5c).toByte()
+ iPad[i] = (paddedKey[i].toInt() xor 0x36).toByte()
+ }
+
+ // Inner hash: H(iPad || data)
+ md.reset()
+ md.update(iPad)
+ md.update(data)
+ val innerHash = md.digest()
+
+ // Outer hash: H(oPad || innerHash)
+ md.reset()
+ md.update(oPad)
+ md.update(innerHash)
+ val mac = md.digest()
+
+ // [CRITICAL] Ensure all used buffers are zero-cleared
+ paddedKey.fill(0)
+ oPad.fill(0)
+ iPad.fill(0)
+ innerHash.fill(0)
+
+ return mac
+ }
+
+ /**
+ * A function completely compatible with Tink's Hkdf.computeHkdf
+ */
+ fun computeHkdf(ikm: ByteArray, salt: ByteArray?, info: ByteArray, length: Int): ByteArray {
+ val actualSalt = if (salt == null || salt.isEmpty()) ByteArray(SHA256_HASH_SIZE) else salt
+
+ // 1. HKDF-Extract
+ val prk = hmacSha256(actualSalt, ikm)
+
+ // 2. HKDF-Expand
+ val result = ByteArrayOutputStream()
+ var t = ByteArray(0)
+ val iterations = ceil(length.toDouble() / SHA256_HASH_SIZE).toInt()
+
+ require(iterations <= 255) { "Requested length is too large" }
+
+ for (i in 1..iterations) {
+ val input = ByteArray(t.size + info.size + 1)
+ System.arraycopy(t, 0, input, 0, t.size)
+ System.arraycopy(info, 0, input, t.size, info.size)
+ input[input.size - 1] = i.toByte()
+
+ if (t.isNotEmpty()) t.fill(0) // Clear previous T
+
+ t = hmacSha256(prk, input)
+ result.write(t)
+
+ input.fill(0) // Clear temporary loop buffer
+ }
+
+ val finalResult = result.toByteArray().copyOf(length)
+
+ // [CRITICAL] Zero out PRK and the final T
+ prk.fill(0)
+ t.fill(0)
+
+ // Note: The actual ikm (sharedSecret) is expected to be cleared
+ // in the finally block of the caller (RawHybridKeyProvider).
+
+ return finalResult
+ }
+}
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/tools/SecurityAuditLogger.kt b/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/tools/SecurityAuditLogger.kt
new file mode 100644
index 0000000..d6f8363
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/encryption-lib/src/main/java/com/android/niapsec/encryption/tools/SecurityAuditLogger.kt
@@ -0,0 +1,78 @@
+/*
+ * Copyright (C) 2026 The Android Open Source Project
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package com.android.niapsec.encryption.tools
+import com.android.niapsec.encryption.BuildConfig
+import android.util.Log
+
+/**
+ * [Security Component: Audit Logger]
+ *
+ * [isAuditLogEnabled] should be false when the app is released.
+ */
+object SecurityAuditLogger {
+ // toggle switch for audit
+ var isAuditLogEnabled = true
+
+ private const val TAG = "AUDIT_LOGGER KMD"
+
+ fun logMaterial(tag: String = TAG, name: String, bytes: ByteArray?) {
+ if (!isAuditLogEnabled || bytes == null) return
+ Log.d(tag, bytes.toHexDumpString())
+ }
+
+ fun logKeyMaterial(name: String, bytes: ByteArray?) {
+ return logKeyMaterial(tag = TAG, name = name, bytes = bytes);
+ }
+ fun logKeyMaterial(tag: String= TAG, name: String, bytes: ByteArray?) {
+ if (!isAuditLogEnabled || bytes== null) {
+ Log.d("${name} KMD", "returns null (error or hardware backend)")
+ return
+ }
+Log.d("${name} KMD", "[MASKED - Use bytes.toHExString() here to dump key]")
+
+ bytes.fill(0)
+ }
+
+ fun logLine(msg: String) {
+ logLine(tag = TAG+BuildConfig.BUILD_DATE, msg = msg)
+ }
+ fun logLine(tag:String,msg: String) {
+ Log.d(tag,msg)
+ }
+}
+
+fun ByteArray.toHexString(): String {
+ return joinToString("") { "%02x".format(it) }
+}
+fun ByteArray.toHexDumpString(): String = buildString {
+ for (rowAddr in this@toHexDumpString.indices step 16) {
+ val rowEnd = minOf(rowAddr + 16, this@toHexDumpString.size)
+ val rowBytes = this@toHexDumpString.sliceArray(rowAddr until rowEnd)
+
+ append("%08x ".format(rowAddr))
+
+ val hexPart = rowBytes.joinToString(" ") { "%02x".format(it) }
+ append(hexPart.padEnd(47)) // Fixed width for 16 bytes
+
+ append(" |")
+ rowBytes.forEach {
+ val char = it.toInt().toChar()
+ append(if (it in 32..126) char else '.')
+ }
+ append("|\n")
+ }
+}.trimEnd()
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/encryption-lib/src/test/java/com/android/niapsec/ExampleUnitTest.kt b/niap-cc/sdp-file-encrypt/encryption-lib/src/test/java/com/android/niapsec/ExampleUnitTest.kt
new file mode 100644
index 0000000..3ce3416
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/encryption-lib/src/test/java/com/android/niapsec/ExampleUnitTest.kt
@@ -0,0 +1,32 @@
+/*
+* Copyright (C) 2026 The Android Open Source Project
+*
+* Licensed under the Apache License, Version 2.0 (the "License");
+* you may not use this file except in compliance with the License.
+* You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing, software
+* distributed under the License is distributed on an "AS IS" BASIS,
+* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+* See the License for the specific language governing permissions and
+* limitations under the License.
+*/
+package com.android.niapsec
+
+import org.junit.Test
+
+import org.junit.Assert.*
+
+/**
+ * Example local unit test, which will execute on the development machine (host).
+ *
+ * See [testing documentation](http://d.android.com/tools/testing).
+ */
+class ExampleUnitTest {
+ @Test
+ fun addition_isCorrect() {
+ assertEquals(4, 2 + 2)
+ }
+}
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/gradle.properties b/niap-cc/sdp-file-encrypt/gradle.properties
new file mode 100644
index 0000000..4a4ab64
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/gradle.properties
@@ -0,0 +1,34 @@
+# Project-wide Gradle settings.
+# IDE (e.g. Android Studio) users:
+# Gradle settings configured through the IDE *will override*
+# any settings specified in this file.
+# For more details on how to configure your build environment visit
+# http://www.gradle.org/docs/current/userguide/build_environment.html
+# Specifies the JVM arguments used for the daemon process.
+# The setting is particularly useful for tweaking memory settings.
+org.gradle.jvmargs=-Xmx2048m -Dfile.encoding=UTF-8
+# When configured, Gradle will run in incubating parallel mode.
+# This option should only be used with decoupled projects. For more details, visit
+# https://developer.android.com/r/tools/gradle-multi-project-decoupled-projects
+# org.gradle.parallel=true
+# AndroidX package structure to make it clearer which packages are bundled with the
+# Android operating system, and which are packaged with your app's APK
+# https://developer.android.com/topic/libraries/support-library/androidx-rn
+android.useAndroidX=true
+# Kotlin code style for this project: "official" or "obsolete":
+kotlin.code.style=official
+# Enables namespacing of each library's R class so that its R class includes only the
+# resources declared in the library itself and none from the library's dependencies,
+# thereby reducing the size of the R class for that library
+android.nonTransitiveRClass=true
+android.suppressUnsupportedCompileSdk=36
+android.defaults.buildfeatures.resvalues=true
+android.sdk.defaultTargetSdkToCompileSdkIfUnset=false
+android.enableAppCompileTimeRClass=false
+android.usesSdkInManifest.disallowed=false
+android.uniquePackageNames=false
+android.dependency.useConstraints=true
+android.r8.strictFullModeForKeepRules=false
+android.r8.optimizedResourceShrinking=false
+android.builtInKotlin=false
+android.newDsl=false
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/gradle/gradle-daemon-jvm.properties b/niap-cc/sdp-file-encrypt/gradle/gradle-daemon-jvm.properties
new file mode 100644
index 0000000..87cbae7
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/gradle/gradle-daemon-jvm.properties
@@ -0,0 +1,13 @@
+#This file is generated by updateDaemonJvm
+toolchainUrl.FREE_BSD.AARCH64=https\://api.foojay.io/disco/v3.0/ids/56a19bc915b9ba2eb62ba7554c61b919/redirect
+toolchainUrl.FREE_BSD.X86_64=https\://api.foojay.io/disco/v3.0/ids/398ffe3949748bfb1d5636f023d228fd/redirect
+toolchainUrl.LINUX.AARCH64=https\://api.foojay.io/disco/v3.0/ids/56a19bc915b9ba2eb62ba7554c61b919/redirect
+toolchainUrl.LINUX.X86_64=https\://api.foojay.io/disco/v3.0/ids/ecd23fd7707c683afbcd6052998cb6a9/redirect
+toolchainUrl.MAC_OS.AARCH64=https\://api.foojay.io/disco/v3.0/ids/10fc3bf1ee0001078a473afe6e43cfdb/redirect
+toolchainUrl.MAC_OS.X86_64=https\://api.foojay.io/disco/v3.0/ids/658299a896470fbb3103ba3a430ee227/redirect
+toolchainUrl.UNIX.AARCH64=https\://api.foojay.io/disco/v3.0/ids/536afcd1dff540251f85e5d2c80458cf/redirect
+toolchainUrl.UNIX.X86_64=https\://api.foojay.io/disco/v3.0/ids/ecd23fd7707c683afbcd6052998cb6a9/redirect
+toolchainUrl.WINDOWS.AARCH64=https\://api.foojay.io/disco/v3.0/ids/248ffb1098f61659502d0c09aa348294/redirect
+toolchainUrl.WINDOWS.X86_64=https\://api.foojay.io/disco/v3.0/ids/dbd05c4936d573642f94cd149e1356c8/redirect
+toolchainVendor=JETBRAINS
+toolchainVersion=21
diff --git a/niap-cc/sdp-file-encrypt/gradle/libs.versions.toml b/niap-cc/sdp-file-encrypt/gradle/libs.versions.toml
new file mode 100644
index 0000000..b302600
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/gradle/libs.versions.toml
@@ -0,0 +1,36 @@
+[versions]
+agp = "9.1.0-rc01"
+kotlin = "2.2.10"
+ksp = "2.3.4"
+coreKtx = "1.17.0"
+junit = "4.13.2"
+junitVersion = "1.3.0"
+espressoCore = "3.7.0"
+lifecycleRuntimeKtx = "2.10.0"
+activityCompose = "1.12.2"
+composeBom = "2025.12.01"
+materialIcons = "1.6.8"
+
+[libraries]
+androidx-core-ktx = { group = "androidx.core", name = "core-ktx", version.ref = "coreKtx" }
+junit = { group = "junit", name = "junit", version.ref = "junit" }
+androidx-junit = { group = "androidx.test.ext", name = "junit", version.ref = "junitVersion" }
+androidx-espresso-core = { group = "androidx.test.espresso", name = "espresso-core", version.ref = "espressoCore" }
+androidx-lifecycle-runtime-ktx = { group = "androidx.lifecycle", name = "lifecycle-runtime-ktx", version.ref = "lifecycleRuntimeKtx" }
+androidx-activity-compose = { group = "androidx.activity", name = "activity-compose", version.ref = "activityCompose" }
+androidx-compose-bom = { group = "androidx.compose", name = "compose-bom", version.ref = "composeBom" }
+androidx-ui = { group = "androidx.compose.ui", name = "ui" }
+androidx-ui-graphics = { group = "androidx.compose.ui", name = "ui-graphics" }
+androidx-ui-tooling = { group = "androidx.compose.ui", name = "ui-tooling" }
+androidx-ui-tooling-preview = { group = "androidx.compose.ui", name = "ui-tooling-preview" }
+androidx-ui-test-manifest = { group = "androidx.compose.ui", name = "ui-test-manifest" }
+androidx-ui-test-junit4 = { group = "androidx.compose.ui", name = "ui-test-junit4" }
+androidx-material3 = { group = "androidx.compose.material3", name = "material3" }
+androidx-material-icons-extended = { group = "androidx.compose.material", name = "material-icons-extended", version.ref = "materialIcons" }
+
+[plugins]
+android-application = { id = "com.android.application", version.ref = "agp" }
+kotlin-android = { id = "org.jetbrains.kotlin.android", version.ref = "kotlin" }
+kotlin-compose = { id = "org.jetbrains.kotlin.plugin.compose", version.ref = "kotlin" }
+ksp = { id = "com.google.devtools.ksp", version.ref = "ksp" }
+
diff --git a/niap-cc/sdp-file-encrypt/gradle/wrapper/gradle-wrapper.jar b/niap-cc/sdp-file-encrypt/gradle/wrapper/gradle-wrapper.jar
new file mode 100644
index 0000000..e708b1c
Binary files /dev/null and b/niap-cc/sdp-file-encrypt/gradle/wrapper/gradle-wrapper.jar differ
diff --git a/niap-cc/sdp-file-encrypt/gradle/wrapper/gradle-wrapper.properties b/niap-cc/sdp-file-encrypt/gradle/wrapper/gradle-wrapper.properties
new file mode 100644
index 0000000..2a45d2e
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/gradle/wrapper/gradle-wrapper.properties
@@ -0,0 +1,6 @@
+#Tue Jan 06 16:50:05 JST 2026
+distributionBase=GRADLE_USER_HOME
+distributionPath=wrapper/dists
+distributionUrl=https\://services.gradle.org/distributions/gradle-9.3.1-bin.zip
+zipStoreBase=GRADLE_USER_HOME
+zipStorePath=wrapper/dists
diff --git a/niap-cc/sdp-file-encrypt/gradlew b/niap-cc/sdp-file-encrypt/gradlew
new file mode 100755
index 0000000..4f906e0
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/gradlew
@@ -0,0 +1,185 @@
+#!/usr/bin/env sh
+
+#
+# Copyright 2015 the original author or authors.
+#
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+# https://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+#
+
+##############################################################################
+##
+## Gradle start up script for UN*X
+##
+##############################################################################
+
+# Attempt to set APP_HOME
+# Resolve links: $0 may be a link
+PRG="$0"
+# Need this for relative symlinks.
+while [ -h "$PRG" ] ; do
+ ls=`ls -ld "$PRG"`
+ link=`expr "$ls" : '.*-> \(.*\)$'`
+ if expr "$link" : '/.*' > /dev/null; then
+ PRG="$link"
+ else
+ PRG=`dirname "$PRG"`"/$link"
+ fi
+done
+SAVED="`pwd`"
+cd "`dirname \"$PRG\"`/" >/dev/null
+APP_HOME="`pwd -P`"
+cd "$SAVED" >/dev/null
+
+APP_NAME="Gradle"
+APP_BASE_NAME=`basename "$0"`
+
+# Add default JVM options here. You can also use JAVA_OPTS and GRADLE_OPTS to pass JVM options to this script.
+DEFAULT_JVM_OPTS='"-Xmx64m" "-Xms64m"'
+
+# Use the maximum available, or set MAX_FD != -1 to use that value.
+MAX_FD="maximum"
+
+warn () {
+ echo "$*"
+}
+
+die () {
+ echo
+ echo "$*"
+ echo
+ exit 1
+}
+
+# OS specific support (must be 'true' or 'false').
+cygwin=false
+msys=false
+darwin=false
+nonstop=false
+case "`uname`" in
+ CYGWIN* )
+ cygwin=true
+ ;;
+ Darwin* )
+ darwin=true
+ ;;
+ MINGW* )
+ msys=true
+ ;;
+ NONSTOP* )
+ nonstop=true
+ ;;
+esac
+
+CLASSPATH=$APP_HOME/gradle/wrapper/gradle-wrapper.jar
+
+
+# Determine the Java command to use to start the JVM.
+if [ -n "$JAVA_HOME" ] ; then
+ if [ -x "$JAVA_HOME/jre/sh/java" ] ; then
+ # IBM's JDK on AIX uses strange locations for the executables
+ JAVACMD="$JAVA_HOME/jre/sh/java"
+ else
+ JAVACMD="$JAVA_HOME/bin/java"
+ fi
+ if [ ! -x "$JAVACMD" ] ; then
+ die "ERROR: JAVA_HOME is set to an invalid directory: $JAVA_HOME
+
+Please set the JAVA_HOME variable in your environment to match the
+location of your Java installation."
+ fi
+else
+ JAVACMD="java"
+ which java >/dev/null 2>&1 || die "ERROR: JAVA_HOME is not set and no 'java' command could be found in your PATH.
+
+Please set the JAVA_HOME variable in your environment to match the
+location of your Java installation."
+fi
+
+# Increase the maximum file descriptors if we can.
+if [ "$cygwin" = "false" -a "$darwin" = "false" -a "$nonstop" = "false" ] ; then
+ MAX_FD_LIMIT=`ulimit -H -n`
+ if [ $? -eq 0 ] ; then
+ if [ "$MAX_FD" = "maximum" -o "$MAX_FD" = "max" ] ; then
+ MAX_FD="$MAX_FD_LIMIT"
+ fi
+ ulimit -n $MAX_FD
+ if [ $? -ne 0 ] ; then
+ warn "Could not set maximum file descriptor limit: $MAX_FD"
+ fi
+ else
+ warn "Could not query maximum file descriptor limit: $MAX_FD_LIMIT"
+ fi
+fi
+
+# For Darwin, add options to specify how the application appears in the dock
+if $darwin; then
+ GRADLE_OPTS="$GRADLE_OPTS \"-Xdock:name=$APP_NAME\" \"-Xdock:icon=$APP_HOME/media/gradle.icns\""
+fi
+
+# For Cygwin or MSYS, switch paths to Windows format before running java
+if [ "$cygwin" = "true" -o "$msys" = "true" ] ; then
+ APP_HOME=`cygpath --path --mixed "$APP_HOME"`
+ CLASSPATH=`cygpath --path --mixed "$CLASSPATH"`
+
+ JAVACMD=`cygpath --unix "$JAVACMD"`
+
+ # We build the pattern for arguments to be converted via cygpath
+ ROOTDIRSRAW=`find -L / -maxdepth 1 -mindepth 1 -type d 2>/dev/null`
+ SEP=""
+ for dir in $ROOTDIRSRAW ; do
+ ROOTDIRS="$ROOTDIRS$SEP$dir"
+ SEP="|"
+ done
+ OURCYGPATTERN="(^($ROOTDIRS))"
+ # Add a user-defined pattern to the cygpath arguments
+ if [ "$GRADLE_CYGPATTERN" != "" ] ; then
+ OURCYGPATTERN="$OURCYGPATTERN|($GRADLE_CYGPATTERN)"
+ fi
+ # Now convert the arguments - kludge to limit ourselves to /bin/sh
+ i=0
+ for arg in "$@" ; do
+ CHECK=`echo "$arg"|egrep -c "$OURCYGPATTERN" -`
+ CHECK2=`echo "$arg"|egrep -c "^-"` ### Determine if an option
+
+ if [ $CHECK -ne 0 ] && [ $CHECK2 -eq 0 ] ; then ### Added a condition
+ eval `echo args$i`=`cygpath --path --ignore --mixed "$arg"`
+ else
+ eval `echo args$i`="\"$arg\""
+ fi
+ i=`expr $i + 1`
+ done
+ case $i in
+ 0) set -- ;;
+ 1) set -- "$args0" ;;
+ 2) set -- "$args0" "$args1" ;;
+ 3) set -- "$args0" "$args1" "$args2" ;;
+ 4) set -- "$args0" "$args1" "$args2" "$args3" ;;
+ 5) set -- "$args0" "$args1" "$args2" "$args3" "$args4" ;;
+ 6) set -- "$args0" "$args1" "$args2" "$args3" "$args4" "$args5" ;;
+ 7) set -- "$args0" "$args1" "$args2" "$args3" "$args4" "$args5" "$args6" ;;
+ 8) set -- "$args0" "$args1" "$args2" "$args3" "$args4" "$args5" "$args6" "$args7" ;;
+ 9) set -- "$args0" "$args1" "$args2" "$args3" "$args4" "$args5" "$args6" "$args7" "$args8" ;;
+ esac
+fi
+
+# Escape application args
+save () {
+ for i do printf %s\\n "$i" | sed "s/'/'\\\\''/g;1s/^/'/;\$s/\$/' \\\\/" ; done
+ echo " "
+}
+APP_ARGS=`save "$@"`
+
+# Collect all arguments for the java command, following the shell quoting and substitution rules
+eval set -- $DEFAULT_JVM_OPTS $JAVA_OPTS $GRADLE_OPTS "\"-Dorg.gradle.appname=$APP_BASE_NAME\"" -classpath "\"$CLASSPATH\"" org.gradle.wrapper.GradleWrapperMain "$APP_ARGS"
+
+exec "$JAVACMD" "$@"
diff --git a/niap-cc/sdp-file-encrypt/gradlew.bat b/niap-cc/sdp-file-encrypt/gradlew.bat
new file mode 100644
index 0000000..107acd3
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/gradlew.bat
@@ -0,0 +1,89 @@
+@rem
+@rem Copyright 2015 the original author or authors.
+@rem
+@rem Licensed under the Apache License, Version 2.0 (the "License");
+@rem you may not use this file except in compliance with the License.
+@rem You may obtain a copy of the License at
+@rem
+@rem https://www.apache.org/licenses/LICENSE-2.0
+@rem
+@rem Unless required by applicable law or agreed to in writing, software
+@rem distributed under the License is distributed on an "AS IS" BASIS,
+@rem WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+@rem See the License for the specific language governing permissions and
+@rem limitations under the License.
+@rem
+
+@if "%DEBUG%" == "" @echo off
+@rem ##########################################################################
+@rem
+@rem Gradle startup script for Windows
+@rem
+@rem ##########################################################################
+
+@rem Set local scope for the variables with windows NT shell
+if "%OS%"=="Windows_NT" setlocal
+
+set DIRNAME=%~dp0
+if "%DIRNAME%" == "" set DIRNAME=.
+set APP_BASE_NAME=%~n0
+set APP_HOME=%DIRNAME%
+
+@rem Resolve any "." and ".." in APP_HOME to make it shorter.
+for %%i in ("%APP_HOME%") do set APP_HOME=%%~fi
+
+@rem Add default JVM options here. You can also use JAVA_OPTS and GRADLE_OPTS to pass JVM options to this script.
+set DEFAULT_JVM_OPTS="-Xmx64m" "-Xms64m"
+
+@rem Find java.exe
+if defined JAVA_HOME goto findJavaFromJavaHome
+
+set JAVA_EXE=java.exe
+%JAVA_EXE% -version >NUL 2>&1
+if "%ERRORLEVEL%" == "0" goto execute
+
+echo.
+echo ERROR: JAVA_HOME is not set and no 'java' command could be found in your PATH.
+echo.
+echo Please set the JAVA_HOME variable in your environment to match the
+echo location of your Java installation.
+
+goto fail
+
+:findJavaFromJavaHome
+set JAVA_HOME=%JAVA_HOME:"=%
+set JAVA_EXE=%JAVA_HOME%/bin/java.exe
+
+if exist "%JAVA_EXE%" goto execute
+
+echo.
+echo ERROR: JAVA_HOME is set to an invalid directory: %JAVA_HOME%
+echo.
+echo Please set the JAVA_HOME variable in your environment to match the
+echo location of your Java installation.
+
+goto fail
+
+:execute
+@rem Setup the command line
+
+set CLASSPATH=%APP_HOME%\gradle\wrapper\gradle-wrapper.jar
+
+
+@rem Execute Gradle
+"%JAVA_EXE%" %DEFAULT_JVM_OPTS% %JAVA_OPTS% %GRADLE_OPTS% "-Dorg.gradle.appname=%APP_BASE_NAME%" -classpath "%CLASSPATH%" org.gradle.wrapper.GradleWrapperMain %*
+
+:end
+@rem End local scope for the variables with windows NT shell
+if "%ERRORLEVEL%"=="0" goto mainEnd
+
+:fail
+rem Set variable GRADLE_EXIT_CONSOLE if you need the _script_ return code instead of
+rem the _cmd.exe /c_ return code!
+if not "" == "%GRADLE_EXIT_CONSOLE%" exit 1
+exit /b 1
+
+:mainEnd
+if "%OS%"=="Windows_NT" endlocal
+
+:omega
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/build.gradle.kts b/niap-cc/sdp-file-encrypt/locked-device-demo/build.gradle.kts
new file mode 100644
index 0000000..6562957
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/locked-device-demo/build.gradle.kts
@@ -0,0 +1,62 @@
+plugins {
+ alias(libs.plugins.android.application)
+ alias(libs.plugins.kotlin.android)
+ alias(libs.plugins.kotlin.compose)
+}
+
+android {
+ namespace = "com.android.niapsec.demo"
+ compileSdk = 36
+
+ defaultConfig {
+ applicationId = "com.android.niapsec"
+ minSdk = 28
+ targetSdk = 36
+ versionCode = 1
+ versionName = "1.0"
+
+ testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
+ }
+
+ buildTypes {
+ release {
+ isMinifyEnabled = false
+ proguardFiles(
+ getDefaultProguardFile("proguard-android-optimize.txt"),
+ "proguard-rules.pro"
+ )
+ }
+ }
+ compileOptions {
+ sourceCompatibility = JavaVersion.VERSION_11
+ targetCompatibility = JavaVersion.VERSION_11
+ }
+ kotlinOptions {
+ jvmTarget = "11"
+ }
+ buildFeatures {
+ compose = true
+ }
+}
+
+dependencies {
+ implementation(project(":encryption-lib"))
+
+ implementation(libs.androidx.core.ktx)
+ implementation(libs.androidx.lifecycle.runtime.ktx)
+ implementation(libs.androidx.activity.compose)
+ implementation(platform(libs.androidx.compose.bom))
+ implementation(libs.androidx.ui)
+ implementation(libs.androidx.ui.graphics)
+ implementation(libs.androidx.ui.tooling.preview)
+ implementation(libs.androidx.material3)
+ implementation(libs.androidx.material.icons.extended)
+
+ testImplementation(libs.junit)
+ androidTestImplementation(libs.androidx.junit)
+ androidTestImplementation(libs.androidx.espresso.core)
+ androidTestImplementation(platform(libs.androidx.compose.bom))
+ androidTestImplementation(libs.androidx.ui.test.junit4)
+ debugImplementation(libs.androidx.ui.tooling)
+ debugImplementation(libs.androidx.ui.test.manifest)
+}
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/androidTest/java/com/android/niapsec/EncryptedSharedPreferencesTest.kt b/niap-cc/sdp-file-encrypt/locked-device-demo/src/androidTest/java/com/android/niapsec/EncryptedSharedPreferencesTest.kt
new file mode 100644
index 0000000..874b30f
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/locked-device-demo/src/androidTest/java/com/android/niapsec/EncryptedSharedPreferencesTest.kt
@@ -0,0 +1,72 @@
+/*
+* Copyright (C) 2026 The Android Open Source Project
+*
+* Licensed under the Apache License, Version 2.0 (the "License");
+* you may not use this file except in compliance with the License.
+* You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing, software
+* distributed under the License is distributed on an "AS IS" BASIS,
+* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+* See the License for the specific language governing permissions and
+* limitations under the License.
+*/
+
+package com.android.niapsec
+
+import androidx.test.ext.junit.runners.AndroidJUnit4
+import androidx.test.platform.app.InstrumentationRegistry
+import com.android.niapsec.demo.EncryptedSharedPreferences
+import com.android.niapsec.encryption.api.EncryptionManager
+import com.android.niapsec.encryption.api.KeyProviderType
+import org.junit.After
+import org.junit.Assert.assertEquals
+import org.junit.Assert.assertNull
+import org.junit.Before
+import org.junit.Test
+import org.junit.runner.RunWith
+import java.util.UUID
+
+@RunWith(AndroidJUnit4::class)
+class EncryptedSharedPreferencesTest {
+
+ private val context = InstrumentationRegistry.getInstrumentation().targetContext
+ private val managersToDestroy = mutableListOf()
+
+ @Before
+ @After
+ fun cleanup() {
+ managersToDestroy.forEach { it.destroy() }
+ managersToDestroy.clear()
+ }
+
+ private fun createManager(providerType: KeyProviderType): EncryptionManager {
+ val masterKeyUri = "android-keystore://test_prefs_key_${UUID.randomUUID()}"
+ val manager = EncryptionManager(context, masterKeyUri, providerType)
+ managersToDestroy.add(manager)
+ return manager
+ }
+
+ private fun runStandardTests(prefs: EncryptedSharedPreferences) {
+ // 1. Test basic put and get
+ val key1 = "myKey1"
+ val value1 = "my secret value"
+ prefs.putString(key1, value1)
+ assertEquals(value1, prefs.getString(key1, null))
+
+ // 2. Test getting a non-existent key
+ assertNull(prefs.getString("non_existent_key", null))
+ assertEquals("default", prefs.getString("non_existent_key", "default"))
+
+ // 3. Test overwriting a key
+ val newValue1 = "a new secret"
+ prefs.putString(key1, newValue1)
+ assertEquals(newValue1, prefs.getString(key1, null))
+
+ // 4. Test clearing the preferences
+ prefs.clear()
+ assertNull(prefs.getString(key1, null))
+ }
+}
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/AndroidManifest.xml b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/AndroidManifest.xml
new file mode 100644
index 0000000..55c20d9
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/AndroidManifest.xml
@@ -0,0 +1,60 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/ic_launcher-playstore.png b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/ic_launcher-playstore.png
new file mode 100644
index 0000000..bd4699b
Binary files /dev/null and b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/ic_launcher-playstore.png differ
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/java/com/android/niapsec/demo/DeviceAdminReceiver.kt b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/java/com/android/niapsec/demo/DeviceAdminReceiver.kt
new file mode 100644
index 0000000..abc647e
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/java/com/android/niapsec/demo/DeviceAdminReceiver.kt
@@ -0,0 +1,55 @@
+/*
+ * Copyright (C) 2026 The Android Open Source Project
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package com.android.niapsec.demo
+
+import android.app.admin.DevicePolicyManager
+import android.app.admin.DeviceAdminReceiver
+import android.content.BroadcastReceiver
+import android.content.ComponentName
+import android.content.Context
+import android.content.Intent
+import android.util.Log
+import android.widget.Toast
+
+class DeviceAdminReceiver : DeviceAdminReceiver() {
+
+ override fun onEnabled(context: Context, intent: Intent) {
+ super.onEnabled(context, intent)
+ Toast.makeText(context, "Device admin enabled", Toast.LENGTH_SHORT).show()
+ }
+
+ override fun onDisabled(context: Context, intent: Intent) {
+ super.onDisabled(context, intent)
+ Toast.makeText(context, "Device admin disabled", Toast.LENGTH_SHORT).show()
+ }
+}
+
+class RemoveAdminReceiver : BroadcastReceiver() {
+ companion object {
+ const val ACTION_REMOVE_ADMIN = "com.android.niapsec.demo.ACTION_REMOVE_ADMIN"
+ }
+
+ override fun onReceive(context: Context, intent: Intent?) {
+ if (intent?.action != ACTION_REMOVE_ADMIN) return
+ val dpm = context.getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager
+ val component = ComponentName(context, DeviceAdminReceiver::class.java)
+ if (dpm.isAdminActive(component)) {
+ dpm.removeActiveAdmin(component)
+ Log.d("RemoveAdmin", "Device admin removed")
+ }
+ }
+}
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/java/com/android/niapsec/demo/DirectBootTestReceiver.kt b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/java/com/android/niapsec/demo/DirectBootTestReceiver.kt
new file mode 100644
index 0000000..4878fa3
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/java/com/android/niapsec/demo/DirectBootTestReceiver.kt
@@ -0,0 +1,125 @@
+/*
+ * Copyright (C) 2026 The Android Open Source Project
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package com.android.niapsec.demo
+
+import android.content.BroadcastReceiver
+import android.content.Context
+import android.content.Intent
+import android.os.UserManager
+import android.util.Log
+import com.android.niapsec.encryption.api.EncryptionManager
+import com.android.niapsec.encryption.api.KeyProviderType
+
+/**
+ * Diagnostic Receiver for validating Direct Boot and Lock State behavior.
+ * This component mimics a background service attempting to access cryptographic keys
+ * during the "Before First Unlock" (BFU) or "After First Unlock" (AFU) states.
+ */
+class DirectBootTestReceiver : BroadcastReceiver() {
+
+ companion object {
+ const val ACTION_TEST_CRYPTO = "com.android.niapsec.ACTION_TEST_CRYPTO"
+ private const val TAG = "DirectBootTest"
+ }
+
+ override fun onReceive(context: Context, intent: Intent) {
+ if (intent.action == ACTION_TEST_CRYPTO) {
+ Log.i(TAG, "Received test broadcast. Starting Direct Boot verification...")
+
+ // 1. Check System Environment
+ val userManager = context.getSystemService(Context.USER_SERVICE) as UserManager
+ val isLocked = !userManager.isUserUnlocked
+ val isDeviceProtected = context.isDeviceProtectedStorage
+
+ Log.d(TAG, "--- Environment Check ---")
+ Log.d(TAG, "User State: ${if (isLocked) "LOCKED (BFU State)" else "UNLOCKED (AFU State)"}")
+ Log.d(TAG, "Storage Context: ${if (isDeviceProtected) "Device Protected (DE)" else "Credential Encrypted (CE)"}")
+
+ // 2. Test RawHybridKeyProvider (JCA Implementation)
+ runTest(context, KeyProviderType.RAW_HYBRID, "RawHybrid_JCA", isLocked)
+
+ // 3. Test HybridKeyProvider (Tink Implementation)
+ runTest(context, KeyProviderType.HYBRID, "Hybrid_Tink", isLocked)
+ }
+ }
+
+ /**
+ * Executes the encryption/decryption cycle using EncryptionManager.
+ * * @param context The application context (automatically handled by EncryptionManager)
+ * @param type The provider type to test (RAW_HYBRID or HYBRID)
+ * @param label A label for logging purposes
+ * @param isLocked Current lock state of the device
+ */
+ private fun runTest(context: Context, type: KeyProviderType, label: String, isLocked: Boolean) {
+ Log.d(TAG, "--- Starting Test Sequence: $label ---")
+ try {
+ // Initialize EncryptionManager with a unique test alias.
+ // IMPORTANT: We set 'unlockedDeviceRequired = true' to enforce strict authentication binding (FIA_UAU_EXT.1).
+ val manager = EncryptionManager(
+ context = context,
+ masterKeyUri = "android-keystore://diagnostic_test_${label.lowercase()}",
+ providerType = type,
+ unlockedDeviceRequired = true
+ )
+
+ val testPayload = "Confidential Data Verification for $label - ${System.currentTimeMillis()}"
+
+ // Step A: Encryption Verification (FDP_DAR_EXT.2)
+ // Requirement: Must SUCCEED even if the device is LOCKED.
+ // Mechanism: Uses the Public Key stored in Device Protected (DE) storage.
+ Log.d(TAG, "[$label] Attempting Encryption...")
+ val ciphertext = manager.encryptToString(testPayload)
+ Log.i(TAG, "[$label] SUCCESS: Encryption completed. Ciphertext length: ${ciphertext.length}")
+
+ // Step B: Decryption Verification (FIA_UAU_EXT.1)
+ // Requirement: Must FAIL if LOCKED. Must SUCCEED if UNLOCKED.
+ // Mechanism: Access to the Private Key in Android Keystore is gated by user authentication.
+ Log.d(TAG, "[$label] Attempting Decryption...")
+ try {
+ val plaintext = manager.decryptFromString(ciphertext)
+
+ if (isLocked) {
+ // SECURITY VIOLATION: We accessed the key without unlocking!
+ Log.e(TAG, "[$label] FAILURE: Decryption succeeded but user is LOCKED! This violates FIA_UAU_EXT.1.")
+ } else {
+ // Normal Operation
+ if (plaintext == testPayload) {
+ Log.i(TAG, "[$label] SUCCESS: Decryption succeeded and data matches.")
+ } else {
+ Log.e(TAG, "[$label] FAILURE: Decryption succeeded but data mismatch (Integrity Error).")
+ }
+ }
+ } catch (e: Exception) {
+ if (isLocked) {
+ // EXPECTED BEHAVIOR: Access denied during lock
+ Log.i(TAG, "[$label] SUCCESS: Decryption failed as expected during lock. Exception: ${e.javaClass.simpleName}")
+ } else {
+ // UNEXPECTED ERROR: Should have worked
+ Log.e(TAG, "[$label] FAILURE: Decryption failed but user is UNLOCKED. Error: ${e.message}")
+ e.printStackTrace()
+ }
+ }
+
+ // Clean up test keys
+ // manager.destroy() // Optional: Keep keys to test across reboots if needed
+ Log.d(TAG, "--- End Test Sequence: $label ---")
+
+ } catch (e: Exception) {
+ Log.e(TAG, "[$label] CRITICAL ERROR during initialization or encryption: ${e.message}", e)
+ }
+ }
+}
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/java/com/android/niapsec/demo/EncryptedSharedPreferences.kt b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/java/com/android/niapsec/demo/EncryptedSharedPreferences.kt
new file mode 100644
index 0000000..52aff9b
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/java/com/android/niapsec/demo/EncryptedSharedPreferences.kt
@@ -0,0 +1,68 @@
+/*
+* Copyright (C) 2026 The Android Open Source Project
+*
+* Licensed under the Apache License, Version 2.0 (the "License");
+* you may not use this file except in compliance with the License.
+* You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing, software
+* distributed under the License is distributed on an "AS IS" BASIS,
+* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+* See the License for the specific language governing permissions and
+* limitations under the License.
+*/
+package com.android.niapsec.demo
+
+import android.content.Context
+import android.content.SharedPreferences
+import com.android.niapsec.encryption.api.EncryptionManager
+
+/**
+ * A wrapper for SharedPreferences that transparently encrypts and decrypts values.
+ *
+ * @param context The application context.
+ * @param fileName The name of the SharedPreferences file.
+ * @param encryptionManager The EncryptionManager instance to use for cryptographic operations.
+ */
+class EncryptedSharedPreferences(context: Context, fileName: String, private val encryptionManager: EncryptionManager) {
+
+ private val sharedPreferences: SharedPreferences = context.getSharedPreferences(fileName, Context.MODE_PRIVATE)
+
+ /**
+ * Encrypts and saves a string value.
+ */
+ fun putString(key: String, value: String) {
+ try {
+ val encryptedValue = encryptionManager.encryptToString(value)
+ sharedPreferences.edit().putString(key, encryptedValue).apply()
+ } catch (e: Exception) {
+ throw SecurityException("Failed to encrypt and save the value for key: $key", e)
+ }
+ }
+
+ /**
+ * Retrieves and decrypts a string value.
+ * Returns the defaultValue if decryption fails.
+ */
+ fun getString(key: String, defaultValue: String?): String? {
+ val encryptedValue = sharedPreferences.getString(key, null)
+ return if (encryptedValue != null) {
+ try {
+ encryptionManager.decryptFromString(encryptedValue)
+ } catch (e: Exception) {
+ defaultValue
+ }
+ } else {
+ defaultValue
+ }
+ }
+
+ /**
+ * Clears all values from this SharedPreferences.
+ */
+ fun clear() {
+ sharedPreferences.edit().clear().apply()
+ }
+}
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/java/com/android/niapsec/demo/EncryptionTestRunner.kt b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/java/com/android/niapsec/demo/EncryptionTestRunner.kt
new file mode 100644
index 0000000..bee7bb9
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/java/com/android/niapsec/demo/EncryptionTestRunner.kt
@@ -0,0 +1,101 @@
+/*
+* Copyright (C) 2026 The Android Open Source Project
+*
+* Licensed under the Apache License, Version 2.0 (the "License");
+* you may not use this file except in compliance with the License.
+* You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing, software
+* distributed under the License is distributed on an "AS IS" BASIS,
+* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+* See the License for the specific language governing permissions and
+* limitations under the License.
+*/
+package com.android.niapsec.demo
+
+import android.content.Context
+import android.util.Log
+import com.android.niapsec.encryption.api.EncryptionManager
+import java.io.File
+
+data class TestResult(val testName: String, val passed: Boolean, val message: String, val file: File? = null)
+
+class EncryptionTestRunner(private val context: Context) {
+
+ companion object {
+ const val ENCRYPTED_FILE_NAME = "test_file.enc"
+ const val ORIGINAL_TEXT = "This is a secret message."
+ }
+
+ fun runFullTest(
+ encryptionManager: EncryptionManager,
+ testName: String,
+ reverseEncryptionResult: Boolean = false,
+ reverseDecryptionResult: Boolean = false
+ ): List {
+ Log.d(testName, "--- STARTING TEST (Reverse Encrypt: $reverseEncryptionResult, Reverse Decrypt: $reverseDecryptionResult) ---")
+ val file = File(context.filesDir, "$testName-$ENCRYPTED_FILE_NAME")
+
+ // [Phase 1.1] Ensure clean state by deleting any existing file from a previous run.
+ if (file.exists()) {
+ val deleted = file.delete()
+ Log.d(testName, "Deleted stale test file: $deleted")
+ }
+
+ val results = mutableListOf()
+
+ // Run Encryption Phase
+ val encryptionResult = testEncryption(encryptionManager, file, testName, reverseEncryptionResult)
+ results.add(encryptionResult)
+
+ // Run Decryption Phase
+ val decryptionResult = testDecryption(encryptionManager, file, testName, reverseDecryptionResult)
+ results.add(decryptionResult)
+
+ Log.d(testName, "--- TEST COMPLETE ---")
+ return results
+ }
+
+ private fun testEncryption(encryptionManager: EncryptionManager, file: File, testName: String, reverseResult: Boolean): TestResult {
+ return try {
+ Log.d(testName, "Attempting encryption...")
+
+ encryptionManager.encryptToFile(file).use { it.write(ORIGINAL_TEXT.toByteArray()) }
+ val passed = !reverseResult
+ val message = if (passed) "Encryption successful" else "Encryption expected to fail but succeeded"
+ TestResult(testName, passed, message, file)
+ } catch (e: Exception) {
+ val passed = reverseResult
+ val message = if (passed) "Encryption rejected as expected (${e.javaClass.simpleName})" else "Encryption failed unexpectedly: ${e.message}"
+ Log.e(testName, message, e)
+ TestResult(testName, passed, message, file)
+ }
+ }
+
+ private fun testDecryption(encryptionManager: EncryptionManager, file: File, testName: String, reverseResult: Boolean): TestResult {
+ return try {
+ Log.d(testName, "Attempting decryption...")
+ if (!file.exists()) {
+ return TestResult(testName, false, "Decryption failed: File not found", file)
+ }
+ val decryptedText = encryptionManager.decryptFromFile(file).use { it.reader().readText() }
+ if (ORIGINAL_TEXT == decryptedText) {
+ val passed = !reverseResult
+ val message = if (passed) "Decryption successful and content matches" else "Decryption expected to fail but succeeded"
+ TestResult(testName, passed, message, file)
+ } else {
+ val passed = reverseResult
+ val message = "Decryption succeeded but content MISMATCH"
+ Log.e(testName, message)
+ TestResult(testName, passed, message, file)
+ }
+ } catch (e: Exception) {
+ val passed = reverseResult
+ val message = if (passed) "Decryption rejected as expected (${e.javaClass.simpleName})" else "Decryption failed unexpectedly: ${e.message}"
+ Log.e(testName, message, e)
+ TestResult(testName, passed, message, file)
+ }
+ }
+}
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/java/com/android/niapsec/demo/MainActivity.kt b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/java/com/android/niapsec/demo/MainActivity.kt
new file mode 100644
index 0000000..276d32d
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/java/com/android/niapsec/demo/MainActivity.kt
@@ -0,0 +1,638 @@
+/*
+* Copyright (C) 2026 The Android Open Source Project
+*
+* Licensed under the Apache License, Version 2.0 (the "License");
+* you may not use this file except in compliance with the License.
+* You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing, software
+* distributed under the License is distributed on an "AS IS" BASIS,
+* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+* See the License for the specific language governing permissions and
+* limitations under the License.
+*/
+package com.android.niapsec.demo
+
+import android.app.admin.DevicePolicyManager
+import android.content.BroadcastReceiver
+import android.content.ComponentName
+import android.content.Context
+import android.content.Intent
+import android.content.IntentFilter
+import android.os.Bundle
+import android.os.Handler
+import android.os.Looper
+import android.util.Log
+import androidx.activity.ComponentActivity
+import androidx.activity.compose.setContent
+import androidx.activity.result.contract.ActivityResultContracts
+import androidx.compose.foundation.clickable
+import androidx.compose.foundation.layout.Arrangement
+import androidx.compose.foundation.layout.Column
+import androidx.compose.foundation.layout.Row
+import androidx.compose.foundation.layout.Spacer
+import androidx.compose.foundation.layout.fillMaxSize
+import androidx.compose.foundation.layout.fillMaxWidth
+import androidx.compose.foundation.layout.height
+import androidx.compose.foundation.layout.padding
+import androidx.compose.foundation.layout.width
+import androidx.compose.foundation.lazy.LazyColumn
+import androidx.compose.foundation.lazy.items
+import androidx.compose.material.icons.Icons
+import androidx.compose.material.icons.filled.CheckCircle
+import androidx.compose.material.icons.filled.Description
+import androidx.compose.material.icons.filled.Lock
+import androidx.compose.material.icons.filled.LockOpen
+import androidx.compose.material.icons.filled.MoreVert
+import androidx.compose.material.icons.filled.VpnKey
+import androidx.compose.material.icons.filled.Warning
+import androidx.compose.material3.AlertDialog
+import androidx.compose.material3.Button
+import androidx.compose.material3.Checkbox
+import androidx.compose.material3.DropdownMenu
+import androidx.compose.material3.DropdownMenuItem
+import androidx.compose.material3.ExperimentalMaterial3Api
+import androidx.compose.material3.HorizontalDivider
+import androidx.compose.material3.Icon
+import androidx.compose.material3.IconButton
+import androidx.compose.material3.MaterialTheme
+import androidx.compose.material3.Scaffold
+import androidx.compose.material3.SnackbarHost
+import androidx.compose.material3.SnackbarHostState
+import androidx.compose.material3.Text
+import androidx.compose.material3.TextButton
+import androidx.compose.material3.TopAppBar
+import androidx.compose.runtime.Composable
+import androidx.compose.runtime.getValue
+import androidx.compose.runtime.mutableStateOf
+import androidx.compose.runtime.remember
+import androidx.compose.runtime.rememberCoroutineScope
+import androidx.compose.runtime.setValue
+import androidx.compose.ui.Alignment
+import androidx.compose.ui.Modifier
+import androidx.compose.ui.graphics.Color
+import androidx.compose.ui.graphics.vector.ImageVector
+import androidx.compose.ui.res.stringResource
+import androidx.compose.ui.unit.dp
+import com.android.niapsec.demo.R
+import com.android.niapsec.demo.ui.theme.FileEncryptionLibTheme
+import com.android.niapsec.encryption.api.EncryptionManager
+import com.android.niapsec.encryption.api.KeyProviderType
+import com.android.niapsec.encryption.tools.SecurityAuditLogger
+import kotlinx.coroutines.launch
+import java.io.File
+
+
+class MainActivity : ComponentActivity() {
+
+ companion object {
+ private const val PREFS_NAME = "demo_settings"
+ private const val KEY_SWEEP_ENABLED = "sweep_enabled"
+ private const val KEY_LOG_ENABLED = "log_enabled"
+ }
+
+ private val prefs by lazy { getSharedPreferences(PREFS_NAME, MODE_PRIVATE) }
+ private val niapSecPrefs by lazy { getSharedPreferences("niap_sec_prefs", MODE_PRIVATE) }
+ private val sweepEnabled = mutableStateOf(true)
+ private val logEnabled = mutableStateOf(true)
+ private val flushIterationsCount = mutableStateOf(64)
+
+ private val hybridFileKeyUri = "android-keystore://hybrid_file_key"
+ private val rawFileKeyUri = "android-keystore://raw_file_key"
+ private val rawHybridFileKeyUri = "android-keystore://raw_hybrid_file_key"
+ private lateinit var testRunner: EncryptionTestRunner
+
+ private lateinit var devicePolicyManager: DevicePolicyManager
+ private lateinit var compName: ComponentName
+
+ private val unlockReceiver = object : BroadcastReceiver() {
+ override fun onReceive(context: Context?, intent: Intent?) {
+ if (intent?.action == Intent.ACTION_USER_PRESENT) {
+ Log.d("MainActivity", "Device unlocked. Triggering auto-sweep...")
+ sweepAndRewrap()
+ }
+ }
+ }
+
+ private var _hybridManager: EncryptionManager? = null
+ private val hybridManager: EncryptionManager
+ get() {
+ if (_hybridManager == null) {
+ _hybridManager = EncryptionManager(this, hybridFileKeyUri, providerType = KeyProviderType.HYBRID, unlockedDeviceRequired = true)
+ }
+ return _hybridManager!!
+ }
+
+ private var _rawManager: EncryptionManager? = null
+ private val rawManager: EncryptionManager
+ get() {
+ if (_rawManager == null) {
+ _rawManager = EncryptionManager(this, rawFileKeyUri, providerType = KeyProviderType.RAW, unlockedDeviceRequired = true)
+ }
+ return _rawManager!!
+ }
+
+ private var _rawHybridManager: EncryptionManager? = null
+ private val rawHybridManager: EncryptionManager
+ get() {
+ if (_rawHybridManager == null) {
+ _rawHybridManager = EncryptionManager(this, rawHybridFileKeyUri, providerType = KeyProviderType.RAW_HYBRID, unlockedDeviceRequired = true)
+ }
+ return _rawHybridManager!!
+ }
+
+ private val testResults = mutableStateOf>(emptyList())
+ private val fileStatusResults = mutableStateOf>(emptyList())
+
+ private val requestAdminLauncher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result ->
+ if (result.resultCode != RESULT_OK) {
+ Log.e("DeviceAdmin", "Failed to get device admin permission.")
+ }
+ }
+
+ override fun onCreate(savedInstanceState: Bundle?) {
+ super.onCreate(savedInstanceState)
+ testRunner = EncryptionTestRunner(this)
+ devicePolicyManager = getSystemService(DEVICE_POLICY_SERVICE) as DevicePolicyManager
+ compName = ComponentName(this, DeviceAdminReceiver::class.java)
+
+ sweepEnabled.value = prefs.getBoolean(KEY_SWEEP_ENABLED, true)
+ logEnabled.value = prefs.getBoolean(KEY_LOG_ENABLED, true)
+ flushIterationsCount.value = niapSecPrefs.getInt("keystore_flush_iterations", 64)
+ SecurityAuditLogger.isAuditLogEnabled = logEnabled.value
+
+ registerReceiver(unlockReceiver, IntentFilter(Intent.ACTION_USER_PRESENT))
+ sweepAndRewrap()
+
+ setContent {
+ FileEncryptionLibTheme {
+ TestScreen()
+ }
+ }
+ }
+
+ override fun onResume() {
+ super.onResume()
+ sweepAndRewrap()
+ }
+
+ override fun onDestroy() {
+ super.onDestroy()
+ unregisterReceiver(unlockReceiver)
+ }
+
+ @OptIn(ExperimentalMaterial3Api::class)
+ @Composable
+ private fun TestScreen() {
+ val snackbarHostState = remember { SnackbarHostState() }
+ val scope = rememberCoroutineScope()
+ val showDeleteConfirmation = remember { mutableStateOf(false) }
+ var expanded by remember { mutableStateOf(false) }
+ var sweepChecked by sweepEnabled
+ var loggingChecked by logEnabled
+ val showFlushIterationsDialog = remember { mutableStateOf(false) }
+ var flushIterationsInput by remember(flushIterationsCount.value) { mutableStateOf(flushIterationsCount.value.toString()) }
+
+ if (showDeleteConfirmation.value) {
+ AlertDialog(
+ onDismissRequest = { showDeleteConfirmation.value = false },
+ title = { Text("Delete All Keys & Data?") },
+ text = { Text("This will permanently destroy all cryptographic keys and encrypted files. This action cannot be undone.") },
+ confirmButton = {
+ TextButton(
+ onClick = {
+ showDeleteConfirmation.value = false
+ clearAll()
+ scope.launch {
+ snackbarHostState.showSnackbar("All keys and data destroyed")
+ }
+ }
+ ) {
+ Text("Delete", color = MaterialTheme.colorScheme.error)
+ }
+ },
+ dismissButton = {
+ TextButton(onClick = { showDeleteConfirmation.value = false }) {
+ Text("Cancel")
+ }
+ }
+ )
+ }
+
+ if (showFlushIterationsDialog.value) {
+ AlertDialog(
+ onDismissRequest = { showFlushIterationsDialog.value = false },
+ title = { Text("Set IPC Flush Iterations") },
+ text = {
+ Column {
+ Text("Configure how many times the Keystore IPC dummy flush request operation is repeated.")
+ Spacer(modifier = Modifier.height(8.dp))
+ androidx.compose.material3.OutlinedTextField(
+ value = flushIterationsInput,
+ onValueChange = { flushIterationsInput = it },
+ label = { Text("Iterations") },
+ keyboardOptions = androidx.compose.foundation.text.KeyboardOptions(keyboardType = androidx.compose.ui.text.input.KeyboardType.Number)
+ )
+ }
+ },
+ confirmButton = {
+ TextButton(onClick = {
+ val newCount = flushIterationsInput.toIntOrNull() ?: 64
+ flushIterationsCount.value = newCount
+ niapSecPrefs.edit().putInt("keystore_flush_iterations", newCount).apply()
+ showFlushIterationsDialog.value = false
+ }) {
+ Text("Save")
+ }
+ },
+ dismissButton = {
+ TextButton(onClick = { showFlushIterationsDialog.value = false }) {
+ Text("Cancel")
+ }
+ }
+ )
+ }
+
+ Scaffold(
+ snackbarHost = { SnackbarHost(hostState = snackbarHostState) },
+ topBar = {
+ TopAppBar(
+ title = {
+ Row(verticalAlignment = Alignment.CenterVertically) {
+ Icon(Icons.Default.VpnKey, contentDescription = "Encryption Key")
+ Spacer(modifier = Modifier.width(8.dp))
+ Text("File Encryption Demo")
+ }
+ },
+ actions = {
+ IconButton(onClick = { expanded = !expanded }) {
+ Icon(
+ imageVector = Icons.Default.MoreVert,
+ contentDescription = "More",
+ )
+ DropdownMenu(expanded = expanded, onDismissRequest = { expanded = false }) {
+ DropdownMenuItem(text = { Text(
+ stringResource(R.string.enable_sweep)
+ ) }, leadingIcon = {
+ Checkbox(checked = sweepChecked, onCheckedChange = { toggleSweep(!sweepChecked) })
+ }, onClick = {
+ toggleSweep(!sweepChecked)
+ })
+ DropdownMenuItem(text = { Text(
+ stringResource(R.string.enable_logging)
+ )}, leadingIcon = {
+ Checkbox(checked = loggingChecked, onCheckedChange = { toggleLog(!loggingChecked) })
+ },onClick = {
+ toggleLog(!loggingChecked)
+ })
+ DropdownMenuItem(text = { Text("Set Flush Iterations") }, onClick = {
+ showFlushIterationsDialog.value = true
+ expanded = false
+ })
+ }
+ }
+ }
+ )
+ }
+ ) { innerPadding ->
+ Column(
+ modifier = Modifier
+ .fillMaxSize()
+ .padding(innerPadding),
+ ) {
+ LazyColumn(
+ modifier = Modifier.fillMaxWidth(),
+ verticalArrangement = Arrangement.Top,
+ horizontalAlignment = Alignment.CenterHorizontally,
+ contentPadding = androidx.compose.foundation.layout.PaddingValues(16.dp)
+ ) {
+ item {
+ /* *** Temporarily removed for readability. *** LLM must not modify here ***
+ ProviderTestGroup(
+ title = "Tink HYBRID",
+ onTestClick = { runHybridFileTest() },
+ onLockAndTestClick = { lockAndTest(KeyProviderType.HYBRID) }
+ )
+ Spacer(modifier = Modifier.height(16.dp))
+
+ ProviderTestGroup(
+ title = "JCA RAW",
+ onTestClick = { runRawFileTest() },
+ onLockAndTestClick = { lockAndTest(KeyProviderType.RAW) }
+ )
+ Spacer(modifier = Modifier.height(16.dp))
+ */
+ ProviderTestGroup(
+ title = "JCA RAW HYBRID",
+ onTestClick = { runRawHybridFileTest() },
+ onLockAndTestClick = { lockAndTest(KeyProviderType.RAW_HYBRID) }
+ )
+
+ Spacer(modifier = Modifier.height(16.dp))
+ Row(horizontalArrangement = Arrangement.spacedBy(16.dp)) {
+ Button(onClick = { checkFileStatus() }) { Text("Check Status") }
+ Button(onClick = { encryptFileManual() }) { Text("Encrypt File") }
+ }
+
+ Spacer(modifier = Modifier.height(16.dp))
+ Button(
+ onClick = { showDeleteConfirmation.value = true },
+ colors = androidx.compose.material3.ButtonDefaults.buttonColors(
+ containerColor = MaterialTheme.colorScheme.error
+ )
+ ) {
+ Text("Clear All Keys & Data")
+ }
+
+ Spacer(modifier = Modifier.height(16.dp))
+ HorizontalDivider(modifier = Modifier.fillMaxWidth())
+ }
+
+ if (testResults.value.isNotEmpty()) {
+ item {
+ Text(
+ "Test Results",
+ style = MaterialTheme.typography.titleMedium,
+ modifier = Modifier.padding(vertical = 8.dp)
+ )
+ }
+ items(testResults.value) { result ->
+ TestResultRow(result, isFile = false)
+ }
+ item { HorizontalDivider(modifier = Modifier
+ .fillMaxWidth()
+ .padding(vertical = 8.dp)) }
+ }
+
+ if (fileStatusResults.value.isNotEmpty()) {
+ item {
+ Text(
+ "File Storage Status",
+ style = MaterialTheme.typography.titleMedium,
+ modifier = Modifier.padding(vertical = 8.dp)
+ )
+ }
+ items(fileStatusResults.value) { result ->
+ TestResultRow(result, isFile = true) {
+ result.file?.let { file ->
+ scope.launch {
+ try {
+ val header = readHeader(file)
+ val manager = when (header) {
+ "ERAW" -> rawManager
+ "EHBT" -> hybridManager
+ "EHBR" -> rawHybridManager
+ else -> rawHybridManager
+ }
+ val plaintext = manager.decryptFromFile(file).use { it.reader().readText() }
+ snackbarHostState.showSnackbar("Decrypted: $plaintext")
+ } catch (e: Exception) {
+ snackbarHostState.showSnackbar("Decryption failed: ${e.message}")
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+
+ private fun readHeader(file: File): String {
+ return try {
+ val input = file.inputStream()
+ val headerBytes = ByteArray(4)
+ val read = input.read(headerBytes)
+ input.close()
+ if (read == 4) String(headerBytes) else ""
+ } catch (e: Exception) { "" }
+ }
+
+ private fun sweepAndRewrap() {
+ if (!sweepEnabled.value) return
+ try {
+ rawHybridManager.sweepAndRewrapPendingFiles()
+ checkFileStatus()
+ } catch (e: Exception) {
+ Log.e("MainActivity", "Sweep failed", e)
+ }
+ }
+
+ private fun encryptFileManual() {
+ val file = File(filesDir, "Manual-Encrypt-test_file.enc")
+ try {
+ val text = "This is a manual encrypted message."
+ rawHybridManager.encryptToFile(file).use { it.write(text.toByteArray()) }
+ checkFileStatus()
+ } catch (e: Exception) {
+ Log.e("MainActivity", "Manual encryption failed", e)
+ }
+ }
+
+ private fun toggleSweep(enabled: Boolean) {
+ sweepEnabled.value = enabled
+ prefs.edit().putBoolean(KEY_SWEEP_ENABLED, enabled).apply()
+ }
+
+ private fun toggleLog(enabled: Boolean) {
+ logEnabled.value = enabled
+ SecurityAuditLogger.isAuditLogEnabled = enabled
+ prefs.edit().putBoolean(KEY_LOG_ENABLED, enabled).apply()
+ }
+
+ private fun readHeaderAndMagic(file: File): Pair {
+ return try {
+ file.inputStream().use { input ->
+ val buffer = ByteArray(5)
+ val read = input.read(buffer)
+ if (read >= 4) {
+ val header = String(buffer.sliceArray(0..3))
+ val magic = if (read == 5) buffer[4].toInt() else 0
+ Pair(header, magic)
+ } else Pair("", 0)
+ }
+ } catch (e: Exception) { Pair("", 0) }
+ }
+ private fun checkFileStatus() {
+ val results = mutableListOf()
+ val files = filesDir.listFiles()?.filter { it.name.endsWith(".enc") } ?: emptyList()
+
+ files.forEach { file ->
+ val (header, magic) = readHeaderAndMagic(file) // Completely removed readBytes()
+ val status = when (header) {
+ "EHBT" -> "Tink Hybrid"
+ "ERAW" -> "JCA Raw"
+ "EHBR" -> when (magic) {
+ 0x01 -> "JCA RawHybrid (Asymmetric 0x01)"
+ 0x02 -> "JCA RawHybrid (Symmetric 0x02)"
+ else -> "JCA RawHybrid (Unknown)"
+ }
+ else -> "Unknown Header: $header"
+ }
+ results.add(TestResult(file.name, true, status, file))
+ }
+ fileStatusResults.value = results
+ }
+
+ @Composable
+ private fun TestResultRow(result: TestResult, isFile: Boolean, onClick: () -> Unit = {}) {
+ Row(
+ modifier = Modifier
+ .padding(8.dp)
+ .fillMaxWidth()
+ .clickable(enabled = isFile) { onClick() },
+ verticalAlignment = Alignment.CenterVertically
+ ) {
+ val icon: ImageVector = if (isFile) {
+ when {
+ result.message.contains("0x01") -> Icons.Default.LockOpen
+ result.message.contains("0x02") -> Icons.Default.Lock
+ else -> Icons.Default.Description
+ }
+ } else {
+ if (result.passed) Icons.Default.CheckCircle else Icons.Default.Warning
+ }
+
+ val iconColor = if (isFile) {
+ if (result.message.contains("0x02")) Color(0xFF4CAF50) else MaterialTheme.colorScheme.primary
+ } else {
+ if (result.passed) Color.Green else Color.Red
+ }
+
+ Icon(
+ imageVector = icon,
+ contentDescription = null,
+ tint = iconColor
+ )
+ Spacer(modifier = Modifier.width(12.dp))
+ Column {
+ Text(
+ text = result.testName,
+ style = MaterialTheme.typography.bodyLarge,
+ color = if (result.passed || isFile) Color.Unspecified else Color.Red
+ )
+ Text(
+ text = result.message,
+ style = MaterialTheme.typography.bodySmall,
+ color = if (result.passed || isFile) Color.Unspecified else Color.Red
+ )
+ if (isFile) {
+ Text(
+ text = "Tap to verify decryption",
+ style = MaterialTheme.typography.labelSmall,
+ color = MaterialTheme.colorScheme.secondary
+ )
+ }
+ }
+ }
+ }
+
+ @Composable
+ private fun ProviderTestGroup(title: String, onTestClick: () -> Unit, onLockAndTestClick: () -> Unit) {
+ var isProcessing by remember { mutableStateOf(false) }
+
+ Column(horizontalAlignment = Alignment.CenterHorizontally) {
+ Text(text = title, style = MaterialTheme.typography.titleLarge)
+ Spacer(modifier = Modifier.height(8.dp))
+ Row(horizontalArrangement = Arrangement.spacedBy(16.dp)) {
+ Button(
+ onClick = {
+ if (!isProcessing) {
+ isProcessing = true
+ onTestClick()
+ Handler(Looper.getMainLooper()).postDelayed({ isProcessing = false }, 1000)
+ }
+ },
+ enabled = !isProcessing
+ ) { Text("Test File") }
+ Button(
+ onClick = {
+ if (!isProcessing) {
+ isProcessing = true
+ onLockAndTestClick()
+ Handler(Looper.getMainLooper()).postDelayed({ isProcessing = false }, 1000)
+ }
+ },
+ enabled = !isProcessing
+ ) { Text("Lock & Test") }
+ }
+ }
+ }
+
+ private fun runHybridFileTest() {
+ testResults.value = testRunner.runFullTest(hybridManager, "TinkHybridFileTest")
+ }
+
+ private fun runRawFileTest() {
+ testResults.value = testRunner.runFullTest(rawManager, "JcaRawFileTest")
+ }
+
+ private fun runRawHybridFileTest() {
+ testResults.value = testRunner.runFullTest(rawHybridManager, "JcaRawHybridFileTest")
+ }
+
+ private fun lockAndTest(providerType: KeyProviderType) {
+ if (!devicePolicyManager.isAdminActive(compName)) {
+ requestDeviceAdmin()
+ return
+ }
+
+ val manager = when (providerType) {
+ KeyProviderType.HYBRID -> hybridManager
+ KeyProviderType.RAW -> rawManager
+ KeyProviderType.RAW_HYBRID -> rawHybridManager
+ else -> throw IllegalArgumentException("Unsupported provider type: $providerType")
+ }
+
+ val keyguardManager = getSystemService(KEYGUARD_SERVICE) as android.app.KeyguardManager
+ Log.d("LockAndTest", "Locking screen to test $providerType provider...")
+ devicePolicyManager.lockNow()
+
+ val handler = Handler(Looper.getMainLooper())
+ val startTime = System.currentTimeMillis()
+ val timeoutMs = 5000L
+
+ val checkStateRunnable = object : Runnable {
+ override fun run() {
+ val isLocked = keyguardManager.isDeviceLocked
+ val elapsed = System.currentTimeMillis() - startTime
+
+ if (isLocked) {
+ Log.d("LockAndTest", "Device is LOCKED after ${elapsed}ms. Proceeding with test.")
+ val shouldFail = true
+ testResults.value = testRunner.runFullTest(manager, "${providerType}AfterLock", reverseDecryptionResult = shouldFail)
+ } else if (elapsed < timeoutMs) {
+ handler.postDelayed(this, 200)
+ } else {
+ Log.e("LockAndTest", "Timeout waiting for device to lock. Proceeding anyway.")
+ val shouldFail = true
+ testResults.value = testRunner.runFullTest(manager, "${providerType}AfterLock", reverseDecryptionResult = shouldFail)
+ }
+ }
+ }
+ handler.postDelayed(checkStateRunnable, 200)
+ }
+
+ private fun requestDeviceAdmin() {
+ val intent = Intent(DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN).apply {
+ putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, compName)
+ putExtra(DevicePolicyManager.EXTRA_ADD_EXPLANATION, "This app needs permission to lock the screen for testing.")
+ }
+ requestAdminLauncher.launch(intent)
+ }
+
+ private fun clearAll() {
+ hybridManager.destroy()
+ _hybridManager = null
+ rawManager.destroy()
+ _rawManager = null
+ rawHybridManager.destroy()
+ _rawHybridManager = null
+ testResults.value = emptyList()
+ fileStatusResults.value = emptyList()
+ Log.d("ClearData", "All keys and data have been destroyed.")
+ }
+}
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/java/com/android/niapsec/demo/ui/theme/Color.kt b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/java/com/android/niapsec/demo/ui/theme/Color.kt
new file mode 100644
index 0000000..a00f8fa
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/java/com/android/niapsec/demo/ui/theme/Color.kt
@@ -0,0 +1,26 @@
+/*
+* Copyright (C) 2026 The Android Open Source Project
+*
+* Licensed under the Apache License, Version 2.0 (the "License");
+* you may not use this file except in compliance with the License.
+* You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing, software
+* distributed under the License is distributed on an "AS IS" BASIS,
+* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+* See the License for the specific language governing permissions and
+* limitations under the License.
+*/
+package com.android.niapsec.demo.ui.theme
+
+import androidx.compose.ui.graphics.Color
+
+val Purple80 = Color(0xFFD0BCFF)
+val PurpleGrey80 = Color(0xFFCCC2DC)
+val Pink80 = Color(0xFFEFB8C8)
+
+val Purple40 = Color(0xFF6650a4)
+val PurpleGrey40 = Color(0xFF625b71)
+val Pink40 = Color(0xFF7D5260)
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/java/com/android/niapsec/demo/ui/theme/Theme.kt b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/java/com/android/niapsec/demo/ui/theme/Theme.kt
new file mode 100644
index 0000000..c4e2ebd
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/java/com/android/niapsec/demo/ui/theme/Theme.kt
@@ -0,0 +1,72 @@
+/*
+* Copyright (C) 2026 The Android Open Source Project
+*
+* Licensed under the Apache License, Version 2.0 (the "License");
+* you may not use this file except in compliance with the License.
+* You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing, software
+* distributed under the License is distributed on an "AS IS" BASIS,
+* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+* See the License for the specific language governing permissions and
+* limitations under the License.
+*/
+package com.android.niapsec.demo.ui.theme
+
+import android.os.Build
+import androidx.compose.foundation.isSystemInDarkTheme
+import androidx.compose.material3.MaterialTheme
+import androidx.compose.material3.darkColorScheme
+import androidx.compose.material3.dynamicDarkColorScheme
+import androidx.compose.material3.dynamicLightColorScheme
+import androidx.compose.material3.lightColorScheme
+import androidx.compose.runtime.Composable
+import androidx.compose.ui.platform.LocalContext
+
+private val DarkColorScheme = darkColorScheme(
+ primary = Purple80,
+ secondary = PurpleGrey80,
+ tertiary = Pink80
+)
+
+private val LightColorScheme = lightColorScheme(
+ primary = Purple40,
+ secondary = PurpleGrey40,
+ tertiary = Pink40
+
+ /* Other default colors to override
+ background = Color(0xFFFFFBFE),
+ surface = Color(0xFFFFFBFE),
+ onPrimary = Color.White,
+ onSecondary = Color.White,
+ onTertiary = Color.White,
+ onBackground = Color(0xFF1C1B1F),
+ onSurface = Color(0xFF1C1B1F),
+ */
+)
+
+@Composable
+fun FileEncryptionLibTheme(
+ darkTheme: Boolean = isSystemInDarkTheme(),
+ // Dynamic color is available on Android 12+
+ dynamicColor: Boolean = true,
+ content: @Composable () -> Unit
+) {
+ val colorScheme = when {
+ dynamicColor && Build.VERSION.SDK_INT >= Build.VERSION_CODES.S -> {
+ val context = LocalContext.current
+ if (darkTheme) dynamicDarkColorScheme(context) else dynamicLightColorScheme(context)
+ }
+
+ darkTheme -> DarkColorScheme
+ else -> LightColorScheme
+ }
+
+ MaterialTheme(
+ colorScheme = colorScheme,
+ typography = Typography,
+ content = content
+ )
+}
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/java/com/android/niapsec/demo/ui/theme/Type.kt b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/java/com/android/niapsec/demo/ui/theme/Type.kt
new file mode 100644
index 0000000..0096a78
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/java/com/android/niapsec/demo/ui/theme/Type.kt
@@ -0,0 +1,49 @@
+/*
+* Copyright (C) 2026 The Android Open Source Project
+*
+* Licensed under the Apache License, Version 2.0 (the "License");
+* you may not use this file except in compliance with the License.
+* You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing, software
+* distributed under the License is distributed on an "AS IS" BASIS,
+* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+* See the License for the specific language governing permissions and
+* limitations under the License.
+*/
+package com.android.niapsec.demo.ui.theme
+
+import androidx.compose.material3.Typography
+import androidx.compose.ui.text.TextStyle
+import androidx.compose.ui.text.font.FontFamily
+import androidx.compose.ui.text.font.FontWeight
+import androidx.compose.ui.unit.sp
+
+// Set of Material typography styles to start with
+val Typography = Typography(
+ bodyLarge = TextStyle(
+ fontFamily = FontFamily.Default,
+ fontWeight = FontWeight.Normal,
+ fontSize = 16.sp,
+ lineHeight = 24.sp,
+ letterSpacing = 0.5.sp
+ )
+ /* Other default text styles to override
+ titleLarge = TextStyle(
+ fontFamily = FontFamily.Default,
+ fontWeight = FontWeight.Normal,
+ fontSize = 22.sp,
+ lineHeight = 28.sp,
+ letterSpacing = 0.sp
+ ),
+ labelSmall = TextStyle(
+ fontFamily = FontFamily.Default,
+ fontWeight = FontWeight.Medium,
+ fontSize = 11.sp,
+ lineHeight = 16.sp,
+ letterSpacing = 0.5.sp
+ )
+ */
+)
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/drawable/ic_launcher_background.xml b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/drawable/ic_launcher_background.xml
new file mode 100644
index 0000000..ca3826a
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/drawable/ic_launcher_background.xml
@@ -0,0 +1,74 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/drawable/ic_launcher_foreground.xml b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/drawable/ic_launcher_foreground.xml
new file mode 100644
index 0000000..c3432a1
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/drawable/ic_launcher_foreground.xml
@@ -0,0 +1,18 @@
+
+
+
+
+
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/menu/mainmenu.xml b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/menu/mainmenu.xml
new file mode 100644
index 0000000..357613c
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/menu/mainmenu.xml
@@ -0,0 +1,14 @@
+
+
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-anydpi-v26/ic_launcher.xml b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-anydpi-v26/ic_launcher.xml
new file mode 100644
index 0000000..50ec886
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-anydpi-v26/ic_launcher.xml
@@ -0,0 +1,6 @@
+
+
+
+
+
+
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-anydpi-v26/ic_launcher_round.xml b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-anydpi-v26/ic_launcher_round.xml
new file mode 100644
index 0000000..50ec886
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-anydpi-v26/ic_launcher_round.xml
@@ -0,0 +1,6 @@
+
+
+
+
+
+
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-hdpi/ic_launcher.webp b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-hdpi/ic_launcher.webp
new file mode 100644
index 0000000..70f5d86
Binary files /dev/null and b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-hdpi/ic_launcher.webp differ
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-hdpi/ic_launcher_round.webp b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-hdpi/ic_launcher_round.webp
new file mode 100644
index 0000000..a1d0969
Binary files /dev/null and b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-hdpi/ic_launcher_round.webp differ
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-mdpi/ic_launcher.webp b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-mdpi/ic_launcher.webp
new file mode 100644
index 0000000..6671bb6
Binary files /dev/null and b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-mdpi/ic_launcher.webp differ
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-mdpi/ic_launcher_round.webp b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-mdpi/ic_launcher_round.webp
new file mode 100644
index 0000000..6d37f22
Binary files /dev/null and b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-mdpi/ic_launcher_round.webp differ
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-xhdpi/ic_launcher.webp b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-xhdpi/ic_launcher.webp
new file mode 100644
index 0000000..4694393
Binary files /dev/null and b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-xhdpi/ic_launcher.webp differ
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-xhdpi/ic_launcher_round.webp b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-xhdpi/ic_launcher_round.webp
new file mode 100644
index 0000000..cc6e2ac
Binary files /dev/null and b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-xhdpi/ic_launcher_round.webp differ
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-xxhdpi/ic_launcher.webp b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-xxhdpi/ic_launcher.webp
new file mode 100644
index 0000000..8ee6440
Binary files /dev/null and b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-xxhdpi/ic_launcher.webp differ
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-xxhdpi/ic_launcher_round.webp b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-xxhdpi/ic_launcher_round.webp
new file mode 100644
index 0000000..671df81
Binary files /dev/null and b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-xxhdpi/ic_launcher_round.webp differ
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-xxxhdpi/ic_launcher.webp b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-xxxhdpi/ic_launcher.webp
new file mode 100644
index 0000000..50e934e
Binary files /dev/null and b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-xxxhdpi/ic_launcher.webp differ
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-xxxhdpi/ic_launcher_round.webp b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-xxxhdpi/ic_launcher_round.webp
new file mode 100644
index 0000000..814679f
Binary files /dev/null and b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/mipmap-xxxhdpi/ic_launcher_round.webp differ
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/values/colors.xml b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/values/colors.xml
new file mode 100644
index 0000000..f8c6127
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/values/colors.xml
@@ -0,0 +1,10 @@
+
+
+ #FFBB86FC
+ #FF6200EE
+ #FF3700B3
+ #FF03DAC5
+ #FF018786
+ #FF000000
+ #FFFFFFFF
+
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/values/strings.xml b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/values/strings.xml
new file mode 100644
index 0000000..271d410
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/values/strings.xml
@@ -0,0 +1,5 @@
+
+ File Encryption Demo
+ Enable DAR_EXT.2.4 sweep
+ Enable logging
+
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/values/themes.xml b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/values/themes.xml
new file mode 100644
index 0000000..bc99766
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/values/themes.xml
@@ -0,0 +1,5 @@
+
+
+
+
+
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/xml/backup_rules.xml b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/xml/backup_rules.xml
new file mode 100644
index 0000000..fa0f996
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/xml/backup_rules.xml
@@ -0,0 +1,13 @@
+
+
+
+
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/xml/data_extraction_rules.xml b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/xml/data_extraction_rules.xml
new file mode 100644
index 0000000..9ee9997
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/xml/data_extraction_rules.xml
@@ -0,0 +1,19 @@
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/xml/device_admin_policies.xml b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/xml/device_admin_policies.xml
new file mode 100644
index 0000000..86ae545
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/locked-device-demo/src/main/res/xml/device_admin_policies.xml
@@ -0,0 +1,6 @@
+
+
+
+
+
+
diff --git a/niap-cc/sdp-file-encrypt/memory-test/.gitignore b/niap-cc/sdp-file-encrypt/memory-test/.gitignore
new file mode 100644
index 0000000..8096718
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/memory-test/.gitignore
@@ -0,0 +1,2 @@
+*.img
+*.dump
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/memory-test/command.md b/niap-cc/sdp-file-encrypt/memory-test/command.md
new file mode 100644
index 0000000..b20fffe
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/memory-test/command.md
@@ -0,0 +1,18 @@
+adb shell "dd if=/proc/kcore of=/data/local/tmp/main_ram_6gb.dump bs=4096 skip=8388611 count=1572864 conv=noerror,sync"
+adb pull /data/local/tmp/main_ram_6gb.dump .
+xxd -s $((0x1a2b3c40 - 64)) -l 256 main_ram_6gb.dump
+
+
+
+xxd -s $((0x150036099 - 64)) -l 256 main_ram_6gb.dump
+xxd -s $((0x150756700 - 64)) -l 256 main_ram_6gb.dump
+xxd -s $((0x150756910 - 64)) -l 256 main_ram_6gb.dump
+xxd -s $((0x166b9c09c - 64)) -l 256 main_ram_6gb.dump
+
+
+xxd -s $((0x150757e1f - 64)) -l 256 main_ram_6gb.dump
+
+xxd -s $((0x1507aa43f - 64)) -l 256 main_ram_6gb.dump
+
+xxd -s $((0x1507aa27f - 64)) -l 256 main_ram_6gb.dump
+xxd -s $((0x1507ad1c0- 64)) -l 256 main_ram_6gb.dump
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/memory-test/dump_ram.py b/niap-cc/sdp-file-encrypt/memory-test/dump_ram.py
new file mode 100644
index 0000000..c097036
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/memory-test/dump_ram.py
@@ -0,0 +1,76 @@
+import subprocess
+import struct
+import sys
+
+def extract_ram():
+ print("[*] Parsing /proc/kcore ELF header and retrieving segment list...\n")
+ # Extracting a bit more of the header (completes instantly)
+ cmd = ["adb", "exec-out", "dd if=/proc/kcore bs=4096 count=4 2>/dev/null"]
+ try:
+ header = subprocess.check_output(cmd)
+ except Exception as e:
+ print(f"[!] Failed to execute adb: {e}")
+ sys.exit(1)
+
+ if header[:4] != b'\x7fELF':
+ print("[!] Error: Not a valid ELF file.")
+ sys.exit(1)
+
+ e_phoff = struct.unpack_from(" Index [{c[0]}]: Size {c[3]:.2f} GB (Offset: 0x{c[1]:x})")
+
+ # Auto-select the one closest to 12GB (Shusky's RAM size)
+ best_match = min(candidates, key=lambda x: abs(x[3] - 12.0))
+ target_offset = best_match[1]
+ largest_size = best_match[2]
+
+ skip_blocks = target_offset // 4096
+ count_blocks = largest_size // 4096
+ out_file = "shusky_physical_ram.dump"
+
+ print(f"\n[*] Command to extract the most likely candidate (Index [{best_match[0]}]):")
+ ext_cmd = f"adb exec-out \"dd if=/proc/kcore bs=4096 skip={skip_blocks} count={count_blocks} 2>/dev/null\" > {out_file}"
+ print(f" {ext_cmd}")
+
+ # print("\nCopy and run the command above, or start extraction automatically?")
+ ans = input("[*] Press Enter to exit. ")
+ # if ans.lower() == 'y':
+ # print(f"[*] Extracting... (Transferring actual data only, will complete in a few minutes)")
+ # subprocess.run(ext_cmd, shell=True)
+ # print("[*] Extraction complete!")
+
+if __name__ == '__main__':
+ extract_ram()
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/memory-test/find_egg.py b/niap-cc/sdp-file-encrypt/memory-test/find_egg.py
new file mode 100644
index 0000000..ef7d943
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/memory-test/find_egg.py
@@ -0,0 +1,21 @@
+import mmap
+
+# Pattern to search for: 32 bytes of 0x48 0x04 repeated 16 times
+pattern = bytes.fromhex("016917548121da2088452ff55655aaa1849f8dde81d12918d8bc71a45db2c299b82a6da1fffbdb900c40e6876b1dc7a84d9f1af14ed5b5809b43b0375effed9ddbe5")
+filename = "main_ram_6gb.dump"
+
+
+print(f"[*] Searching for the specific DEK pattern in {filename}...")
+
+with open(filename, "rb") as f:
+ # Memory-map the 6GB file (extremely fast and memory-efficient)
+ mm = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
+
+ offset = 0
+ count = 0
+ while (offset := mm.find(pattern, offset)) != -1:
+ count += 1
+ print(f"[!] Found! Absolutfie offset: {offset} (Hex: 0x{offset:x})")
+ offset += 1
+
+print(f"[*] Search complete. Total {count} instances found.")
\ No newline at end of file
diff --git a/niap-cc/sdp-file-encrypt/memory-test/hook.js b/niap-cc/sdp-file-encrypt/memory-test/hook.js
new file mode 100644
index 0000000..81a1b25
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/memory-test/hook.js
@@ -0,0 +1,47 @@
+console.log("Frida script loaded. Waiting for Cipher.init()...");
+
+Java.perform(function() {
+ const Cipher = Java.use('javax.crypto.Cipher');
+
+ Cipher.init.overload('int', 'java.security.Key').implementation = function(opmode, key) {
+ console.log("\n[+] Cipher.init(opmode, key) hooked!");
+
+ let mode = (opmode === 1) ? "ENCRYPT_MODE" : "DECRYPT_MODE";
+ console.log(" - opmode: " + mode);
+
+ if (key) {
+ console.log(" - Key algorithm: " + key.getAlgorithm());
+
+ try {
+ const keyBytes = key.getEncoded();
+ if (keyBytes) {
+ console.log(" - โ
โ
โ
KEY MATERIAL FOUND โ
โ
โ
:");
+ console.log(simpleHexDump(keyBytes, { ansi: true }));
+ } else {
+ console.log(" - key.getEncoded() returned null. Key material is not accessible.");
+ }
+ } catch (e) {
+ console.log(" - Failed to get key material: " + e.toString());
+ console.log(" - This is expected for hardware-backed keys.");
+ }
+ } else {
+ console.log(" - Key is null.");
+ }
+
+ return this.init(opmode, key);
+ };
+ function simpleHexDump(javaByteArray) {
+ const bytes = Java.array('byte', javaByteArray);
+
+ let hexString = "";
+ for (let i = 0; i < bytes.length; i++) {
+ if (i > 0 && i % 16 === 0) {
+ hexString += "\n";
+ }
+ const hex = ('0' + (bytes[i] & 0xFF).toString(16)).slice(-2);
+ hexString += hex + " ";
+ }
+ return hexString;
+ }
+});
+
diff --git a/niap-cc/sdp-file-encrypt/memory-test/run-frida.sh b/niap-cc/sdp-file-encrypt/memory-test/run-frida.sh
new file mode 100755
index 0000000..f8fbf23
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/memory-test/run-frida.sh
@@ -0,0 +1,73 @@
+#!/bin/bash
+
+# --- Configuration ---
+# The package name of the app to test.
+PACKAGE_NAME="com.android.niapsec"
+
+# The name of the Frida hook script.
+HOOK_SCRIPT="security-hook.js"
+
+# The path to the frida-server on the device.
+FRIDA_SERVER_PATH="/data/local/tmp/frida-server"
+
+# --- Script Body ---
+
+# Colors for output
+RED='\033[0;31m'
+GREEN='\033[0;32m'
+YELLOW='\033[1;33m'
+NC='\033[0m' # No Color
+
+echo -e "${GREEN}Starting Frida test script for package: ${YELLOW}${PACKAGE_NAME}${NC}"
+
+# 1. Check if adb command exists
+if ! command -v adb &> /dev/null; then
+ echo -e "${RED}Error: 'adb' command not found. Please ensure Android SDK Platform-Tools are in your PATH.${NC}"
+ exit 1
+fi
+
+# 2. Check if the hook script exists
+if [ ! -f "$HOOK_SCRIPT" ]; then
+ echo -e "${RED}Error: Hook script '$HOOK_SCRIPT' not found in the current directory.${NC}"
+ exit 1
+fi
+
+source ~/frenv/bin/activate
+
+# 3. Check if frida-server is running
+echo -e "${YELLOW}Checking for running frida-server...${NC}"
+# Use pgrep to find the process ID
+FRIDA_PID=$(adb shell "pgrep -f $FRIDA_SERVER_PATH")
+
+if [ -z "$FRIDA_PID" ]; then
+ echo -e "${YELLOW}Frida server is not running. Attempting to start it...${NC}"
+ # Start frida-server in the background as root
+ adb shell "su -c '$FRIDA_SERVER_PATH &'"
+ # Wait a moment for the server to initialize
+ sleep 2
+
+ # Check again
+ FRIDA_PID=$(adb shell "pgrep -f $FRIDA_SERVER_PATH")
+ if [ -z "$FRIDA_PID" ]; then
+ echo -e "${RED}Error: Failed to start Frida server on the device. Please check if the device is rooted and if the server is at '$FRIDA_SERVER_PATH'.${NC}"
+ exit 1
+ else
+ echo -e "${GREEN}Frida server started successfully (PID: $FRIDA_PID).${NC}"
+ fi
+else
+ echo -e "${GREEN}Frida server is already running (PID: ${FRIDA_PID}).${NC}"
+fi
+
+# 4. Attach to the application using Frida
+echo -e "\n${GREEN}Attaching to application... (Press Ctrl+C to exit)${NC}"
+echo "--------------------------------------------------"
+
+# -U: Use a USB-connected device
+# -f: Spawn the specified package name
+# -l: Load the specified script
+# --no-pause: Resume the application immediately after attaching
+frida -U -f $PACKAGE_NAME -l $HOOK_SCRIPT
+
+echo "--------------------------------------------------"
+echo -e "${GREEN}Frida session finished.${NC}"
+
diff --git a/niap-cc/sdp-file-encrypt/memory-test/security-hook.js b/niap-cc/sdp-file-encrypt/memory-test/security-hook.js
new file mode 100644
index 0000000..5659cc3
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/memory-test/security-hook.js
@@ -0,0 +1,114 @@
+// Frida script to monitor cryptographic operations in com.android.niapsec.demo
+
+console.log("Frida script loaded. Starting hooks...");
+
+Java.perform(function() { // Helper function to safely convert Java byte[] to a hex string
+ function simpleHexDump(javaByteArray) {
+ if (!javaByteArray) {
+ return "null";
+ }
+ try {
+ const bytes = Java.array('byte', javaByteArray);
+ let hexString = "";
+ for (let i = 0; i < bytes.length; i++) {
+ if (i > 0 && i % 16 === 0) {
+ hexString += "\n";
+ }
+ const hex = ('0' + (bytes[i] & 0xFF).toString(16)).slice(-2);
+ hexString += hex + " ";
+ }
+ return hexString.trim();
+ } catch (e) {
+ return "Error dumping bytes: " + e.toString();
+ }
+ }
+
+ // --- 1. Hook Cipher.init() to inspect keys ---
+ const Cipher = Java.use('javax.crypto.Cipher');
+ Cipher.init.overload('int', 'java.security.Key').implementation = function(opmode, key) {
+ console.log("\n[+] Cipher.init(opmode, key) hooked!");
+ const mode = (opmode === 1) ? "ENCRYPT_MODE" : "DECRYPT_MODE";
+ console.log(" - opmode: " + mode);
+
+ if (key) {
+ console.log(" - Key class: " + key.$className);
+ console.log(" - Key algorithm: " + key.getAlgorithm());
+
+ try {
+ const keyBytes = key.getEncoded();
+ if (keyBytes) {
+ console.log(" - โ
โ
โ
KEY MATERIAL FOUND โ
โ
โ
:");
+ console.log(" " + simpleHexDump(keyBytes));
+ } else {
+ console.log(" - key.getEncoded() returned null. Key material not accessible.");
+ }
+ } catch (e) {
+ console.log(" - Failed to get key material: " + e.toString());
+ console.log(" - This is expected for hardware-backed keys.");
+ }
+ } else {
+ console.log(" - Key is null.");
+ }
+ return this.init(opmode, key);
+ };
+
+ // --- 2. Hook Cipher.doFinal() to inspect data ---
+ Cipher.doFinal.overload('[B').implementation = function(input) {
+ if (!input || input.length === 0) {
+ // console.log("\n[+] Cipher.doFinal(byte[]) hooked with empty input. Passing through...");
+ return this.doFinal(input);
+ }
+
+ console.log("\n[+] Cipher.doFinal(byte[]) hooked!");
+
+ const opmode = this.getIV() ? "ENCRYPT" : "DECRYPT"; // A simple guess
+ console.log(" - Guessed operation: " + opmode);
+ const inputArray = Java.array('byte', input);
+ if(input.$className == undefined){
+ console.log(" - Input is not a Java array.");
+ return this.doFinal(input);
+ }
+ //console.log(" - Input length: " + input.$className);
+ console.log(" - Input data (first 32 bytes):\n " + simpleHexDump(inputArray.slice(0, 32)));
+
+ const result = this.doFinal(input);
+ const resultArray = Java.array('byte', result);
+ console.log(" - Output data (first 32 bytes):\n " + simpleHexDump(resultArray.slice(0, 32)));
+ return result;
+ };
+
+ // --- 3. Hook SharedPreferences to monitor writes ---
+ const EditorImpl = Java.use('android.app.SharedPreferencesImpl$EditorImpl');
+ EditorImpl.putString.implementation = function(key, value) {
+ console.log("\n[+] SharedPreferences.putString() hooked!");
+ console.log(" - Key: " + key);
+ console.log(" - Value (first 100 chars): " + (value ? value.substring(0, 100) : "null"));
+
+ if (key === "hybrid_public_keyset") {
+ console.log(" - โ
โ
โ
Public keyset is being written to SharedPreferences! โ
โ
โ
");
+ }
+ return this.putString(key, value);
+ };
+
+
+ // --- 4. Hook KeyStore operations ---
+ const KeyStore = Java.use('java.security.KeyStore');
+ KeyStore.getKey.implementation = function(alias, password) {
+ console.log("\n[+] KeyStore.getKey() hooked!");
+ console.log(" - Alias: " + alias);
+ return this.getKey(alias, password);
+ };
+
+ KeyStore.deleteEntry.implementation = function(alias) {
+ console.log("\n[+] KeyStore.deleteEntry() hooked!");
+ console.log(" - Deleting key with alias: " + alias);
+
+ if (alias.startsWith("raw_provider_key_")) {
+ console.log(" - โ
โ
โ
RawProvider key is being deleted. โ
โ
โ
");
+ }
+ this.deleteEntry(alias);
+ };
+
+ console.log("\n[+] All hooks are in place. Waiting for app activity...");
+});
+
diff --git a/niap-cc/sdp-file-encrypt/settings.gradle.kts b/niap-cc/sdp-file-encrypt/settings.gradle.kts
new file mode 100644
index 0000000..e95d529
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/settings.gradle.kts
@@ -0,0 +1,21 @@
+pluginManagement {
+ repositories {
+ google()
+ mavenCentral()
+ gradlePluginPortal()
+ }
+}
+plugins {
+ id("org.gradle.toolchains.foojay-resolver-convention") version "1.0.0"
+}
+dependencyResolutionManagement {
+ repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
+ repositories {
+ google()
+ mavenCentral()
+ }
+}
+
+rootProject.name = "FileEncryptionLib"
+include(":encryption-lib")
+include(":locked-device-demo")
diff --git a/niap-cc/sdp-file-encrypt/uninstall.sh b/niap-cc/sdp-file-encrypt/uninstall.sh
new file mode 100755
index 0000000..d75e136
--- /dev/null
+++ b/niap-cc/sdp-file-encrypt/uninstall.sh
@@ -0,0 +1,8 @@
+#!/bin/sh
+SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
+SDK_DIR=$(grep '^sdk.dir=' "$SCRIPT_DIR/local.properties" | cut -d'=' -f2)
+ADB="$SDK_DIR/platform-tools/adb"
+
+"$ADB" shell am broadcast -a com.android.niapsec.demo.ACTION_REMOVE_ADMIN -n com.android.niapsec/.demo.RemoveAdminReceiver
+sleep 1
+"$ADB" uninstall com.android.niapsec