├── output └── images │ ├── eq1.jpg │ ├── SAFAR.jpeg │ ├── SAFAR.jpg │ ├── cclogo.png │ ├── SAFAR_pwd.jpg │ ├── collapsed.png │ ├── expanded.png │ ├── figure1.jpg │ ├── figure2.jpg │ ├── figure3.jpg │ ├── figure4.jpg │ ├── niaplogo.png │ ├── ruleOf3.jpg │ ├── SAFAR_basic.jpg │ ├── SAFAR_test.jpg │ ├── SAFAR_finger.jpg │ ├── equationI1-A.jpg │ ├── equationI2-1.jpg │ ├── equationI2-2.jpg │ ├── equationI2-3.jpg │ ├── equationI2-5.jpg │ ├── equationI2-A.jpg │ ├── equationI3-1.jpg │ ├── equationI3-2.jpg │ ├── equationI3-3.jpg │ ├── equationI3-4.jpg │ ├── equationI3-a.jpg │ ├── equationI4-a.jpg │ ├── equationI4-b.jpg │ ├── equationI4-c.jpg │ ├── equationI4-d.jpg │ ├── equationI4-e.jpg │ ├── equationI4-f.jpg │ ├── equationI4-g.jpg │ ├── equationI4-h.jpg │ ├── equationI4-i.jpg │ └── niaplogodraft.png ├── .gitmodules ├── Makefile ├── input ├── tds │ └── README.md └── esr.xml ├── .gitignore ├── .github └── workflows │ ├── validate.yml │ ├── quick_build_pdf.yml │ └── quick_build.yml ├── LICENSE ├── Dictionary.txt ├── local └── Dictionary.txt └── README.adoc /output/images/eq1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/eq1.jpg -------------------------------------------------------------------------------- /output/images/SAFAR.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/SAFAR.jpeg -------------------------------------------------------------------------------- /output/images/SAFAR.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/SAFAR.jpg -------------------------------------------------------------------------------- /output/images/cclogo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/cclogo.png -------------------------------------------------------------------------------- /output/images/SAFAR_pwd.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/SAFAR_pwd.jpg -------------------------------------------------------------------------------- /output/images/collapsed.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/collapsed.png -------------------------------------------------------------------------------- /output/images/expanded.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/expanded.png -------------------------------------------------------------------------------- /output/images/figure1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/figure1.jpg -------------------------------------------------------------------------------- /output/images/figure2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/figure2.jpg -------------------------------------------------------------------------------- /output/images/figure3.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/figure3.jpg -------------------------------------------------------------------------------- /output/images/figure4.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/figure4.jpg -------------------------------------------------------------------------------- /output/images/niaplogo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/niaplogo.png -------------------------------------------------------------------------------- /output/images/ruleOf3.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/ruleOf3.jpg -------------------------------------------------------------------------------- /.gitmodules: -------------------------------------------------------------------------------- 1 | [submodule "transforms"] 2 | path = transforms 3 | url = https://github.com/commoncriteria/transforms.git 4 | -------------------------------------------------------------------------------- /output/images/SAFAR_basic.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/SAFAR_basic.jpg -------------------------------------------------------------------------------- /output/images/SAFAR_test.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/SAFAR_test.jpg -------------------------------------------------------------------------------- /output/images/SAFAR_finger.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/SAFAR_finger.jpg -------------------------------------------------------------------------------- /output/images/equationI1-A.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/equationI1-A.jpg -------------------------------------------------------------------------------- /output/images/equationI2-1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/equationI2-1.jpg -------------------------------------------------------------------------------- /output/images/equationI2-2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/equationI2-2.jpg -------------------------------------------------------------------------------- /output/images/equationI2-3.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/equationI2-3.jpg -------------------------------------------------------------------------------- /output/images/equationI2-5.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/equationI2-5.jpg -------------------------------------------------------------------------------- /output/images/equationI2-A.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/equationI2-A.jpg -------------------------------------------------------------------------------- /output/images/equationI3-1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/equationI3-1.jpg -------------------------------------------------------------------------------- /output/images/equationI3-2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/equationI3-2.jpg -------------------------------------------------------------------------------- /output/images/equationI3-3.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/equationI3-3.jpg -------------------------------------------------------------------------------- /output/images/equationI3-4.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/equationI3-4.jpg -------------------------------------------------------------------------------- /output/images/equationI3-a.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/equationI3-a.jpg -------------------------------------------------------------------------------- /output/images/equationI4-a.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/equationI4-a.jpg -------------------------------------------------------------------------------- /output/images/equationI4-b.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/equationI4-b.jpg -------------------------------------------------------------------------------- /output/images/equationI4-c.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/equationI4-c.jpg -------------------------------------------------------------------------------- /output/images/equationI4-d.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/equationI4-d.jpg -------------------------------------------------------------------------------- /output/images/equationI4-e.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/equationI4-e.jpg -------------------------------------------------------------------------------- /output/images/equationI4-f.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/equationI4-f.jpg -------------------------------------------------------------------------------- /output/images/equationI4-g.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/equationI4-g.jpg -------------------------------------------------------------------------------- /output/images/equationI4-h.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/equationI4-h.jpg -------------------------------------------------------------------------------- /output/images/equationI4-i.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/equationI4-i.jpg -------------------------------------------------------------------------------- /output/images/niaplogodraft.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/commoncriteria/mobile-device/HEAD/output/images/niaplogodraft.png -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | -include ~/commoncriteria/User.make 2 | -include User.make 3 | TRANS?=transforms 4 | #BASE=mobile-device 5 | 6 | DIFF_EXE = diff -W 180 -y <(pandoc -f HTML -t markdown "$1") <(pandoc -f HTML -t markdown "$2") >$3 7 | DIFF_EXT = txt 8 | 9 | DIFF_TAGS=v3.2 10 | include $(TRANS)/Helper.make 11 | 12 | -------------------------------------------------------------------------------- /input/tds/README.md: -------------------------------------------------------------------------------- 1 | # TDs README 2 | 3 | This is the TD directory. 4 | For a release branch, authors should create XML representations for all TDs issued for this version of the PP document. 5 | Eventually these TD files should be pulled into the development branch, usually the 'master' branch. 6 | Once they get pulled into the master branch, they should be manually incoporated into the main XML input document and then deleted from the master branch. 7 | 8 | 9 | 10 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # files not to track in git 2 | output/*.* 3 | output/css 4 | output/js 5 | *~ 6 | input/*.html 7 | input/schemas.xml 8 | input/os.rnc 9 | User.make 10 | /**/tmp 11 | goorm.manifest 12 | **/*.swp 13 | output/images/diff-first.gif 14 | output/images/diff-last.gif 15 | output/images/diff-next.gif 16 | output/images/diff-previous.gif 17 | output/images/diffconflict.gif 18 | output/images/diffmin.gif 19 | output/images/diffplus.gif 20 | output/images/diffunderline.gif 21 | .gitmodules.BAK 22 | -------------------------------------------------------------------------------- /.github/workflows/validate.yml: -------------------------------------------------------------------------------- 1 | # This is a the Common Criteria build workflow that is triggered on push 2 | 3 | name: Validate 4 | 5 | # Controls when the action will run. Workflow runs when manually triggered using the UI 6 | # or API. 7 | on: [push, workflow_dispatch] 8 | 9 | # A workflow run is made up of one or more jobs that can run sequentially or in parallel 10 | jobs: 11 | build-project: 12 | 13 | # The type of runner that the job will run on 14 | runs-on: ubuntu-latest 15 | # Steps represent a sequence of tasks that will be executed as part of the job 16 | steps: 17 | - name: Checkout project and transforms 18 | uses: actions/checkout@v2 19 | with: 20 | submodules: true 21 | 22 | - name: Install Jing 23 | run: wget -O - https://github.com/relaxng/jing-trang/releases/download/V20181222/jing-20181222.zip | jar -x 24 | 25 | - name: Schema Validation 26 | run: JING_JAR=jing*/bin/jing.jar make validate 27 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | This is free and unencumbered software released into the public domain. 2 | 3 | Anyone is free to copy, modify, publish, use, compile, sell, or 4 | distribute this software, either in source code form or as a compiled 5 | binary, for any purpose, commercial or non-commercial, and by any 6 | means. 7 | 8 | In jurisdictions that recognize copyright laws, the author or authors 9 | of this software dedicate any and all copyright interest in the 10 | software to the public domain. We make this dedication for the benefit 11 | of the public at large and to the detriment of our heirs and 12 | successors. We intend this dedication to be an overt act of 13 | relinquishment in perpetuity of all present and future rights to this 14 | software under copyright law. 15 | 16 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 17 | EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 18 | MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. 19 | IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR 20 | OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, 21 | ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR 22 | OTHER DEALINGS IN THE SOFTWARE. 23 | 24 | For more information, please refer to 25 | 26 | -------------------------------------------------------------------------------- /Dictionary.txt: -------------------------------------------------------------------------------- 1 | A1 2 | A2 3 | B1 4 | B2 5 | C1 6 | C2 7 | D1 8 | D2 9 | E1 10 | E2 11 | F1 12 | F2 13 | G1 14 | G2 15 | H1 16 | H2 17 | H3 18 | I1 19 | I2 20 | I3 21 | 131A 22 | 1C 23 | 1D 24 | 1E 25 | 1X 26 | 2C 27 | 2D 28 | 2E 29 | 2p 30 | 38A 31 | 38B 32 | 38C 33 | 38D 34 | 38E 35 | 38F 36 | 3C 37 | 3D 38 | 3E 39 | 4C 40 | 56A 41 | 56B 42 | 56C 43 | 57A 44 | 5C 45 | 6C 46 | 7C 47 | 8a 48 | AAD 49 | J1 50 | J2 51 | K2 52 | L1 53 | L2 54 | 1a 55 | 1b 56 | 57 | Wi 58 | Fi 59 | 60 | accelerometers 61 | Adleman 62 | VVoIP 63 | XCCDF 64 | v1 65 | USSD 66 | allowlist 67 | allowlisted 68 | BAF 69 | BAFs 70 | uplink 71 | untruncated 72 | unenroll 73 | unenrolled 74 | Unenrolled 75 | unenrollment 76 | Unenrollment 77 | Sel 78 | SEL 79 | skeletonized 80 | Agresti 81 | Coull 82 | Jeffreys 83 | PSS 84 | liveness 85 | Liveness 86 | keystore 87 | passcode 88 | microSD 89 | MDF 90 | KATS 91 | 90A 92 | SPD 93 | Tweakable 94 | MacKey 95 | MacTag 96 | iteratively 97 | natively 98 | exfiltrate 99 | REQ 100 | imposters 101 | Impl 102 | hotspot 103 | Hotspot 104 | hotspots 105 | endian 106 | fstack 107 | encipherment 108 | binarized 109 | Detections 110 | codecs 111 | dialer 112 | biometrics 113 | jitter 114 | Biometrics 115 | 116 | EDR 117 | 118 | # Cryptographic 119 | RSASSA 120 | CMAC 121 | PBKDF2 122 | DRBGs 123 | Curve25519 124 | secp256r1 125 | secp384r1 126 | secp521r1 127 | caSigning 128 | NewWithOld 129 | K1 130 | 131 | # Organizations 132 | CSEC 133 | AISEP 134 | DISA 135 | CyberSecurity 136 | NCSC 137 | CSD 138 | 139 | # Components not defined here 140 | ECD 141 | MTD 142 | CCL 143 | DTLSC 144 | FLAWAPP 145 | BMG 146 | MBV 147 | PBA 148 | SMR 149 | 150 | # Undefined Acronyms 151 | JTAG 152 | OSCP 153 | GSM 154 | ICMP 155 | dBm 156 | IMCP 157 | OBEX 158 | CVEs 159 | DSPs 160 | EKU 161 | MACed 162 | 163 | # Acronyms that are used once and defined inline 164 | UMTS 165 | JIT 166 | SAs 167 | IUT 168 | ECB 169 | OFB 170 | EWA 171 | CFB 172 | XEX 173 | 174 | #Latex Equations 175 | α 176 | frac 177 | cp 178 | conf 179 | ni 180 | 181 | # Reference-related 182 | Elham 183 | Elsevier 184 | Tabassi 185 | Kniess 186 | Przybocki 187 | Doddington 188 | DasGupta 189 | Cai 190 | et 191 | al 192 | Scheuermann 193 | Henniger 194 | DasGupta 195 | SHAVS 196 | RFC3526 197 | SP800 198 | Codebook 199 | -------------------------------------------------------------------------------- /local/Dictionary.txt: -------------------------------------------------------------------------------- 1 | 1a 2 | 1b 3 | 1C 4 | 1D 5 | 1E 6 | infeasible 7 | imposters 8 | accelerometers 9 | Adleman 10 | ADDR 11 | ADDR1 12 | AEX 13 | AFL 14 | AGD 15 | Agresti 16 | 17 | VoIP 18 | webserver 19 | whitelisted 20 | whitelisting 21 | 300MHz 22 | 110dBm 23 | 2C 24 | 2D 25 | 2E 26 | 2a 27 | 2b 28 | 2p 29 | 38A 30 | 38B 31 | 38C 32 | 38D 33 | 38E 34 | 38F 35 | 3C 36 | 3D 37 | 3E 38 | 4C 39 | 56A 40 | 56B 41 | 56MHz 42 | 57A 43 | 5C 44 | 6000MHz 45 | 6C 46 | 7C 47 | 90A 48 | 11ac 49 | 131A 50 | 1X 51 | FAU 52 | FCS 53 | FDP 54 | FIA 55 | FMT 56 | FPT 57 | FTA 58 | FTP 59 | ASE 60 | ADV 61 | AGD 62 | ALC 63 | ATE 64 | AVA 65 | GEN 66 | STG 67 | CKM 68 | COP 69 | HTTPS 70 | EXT 71 | IV 72 | RBG 73 | SRV 74 | STG 75 | TLSC 76 | ACF 77 | DAR 78 | IFC 79 | UPC 80 | AFL 81 | BLT 82 | PMG 83 | TRT 84 | UAU 85 | X509 86 | MOF 87 | SMF 88 | AEX 89 | JTA 90 | KST 91 | NOT 92 | STM 93 | TST 94 | TUD 95 | SSL 96 | ITC 97 | CCL 98 | ECD 99 | INT 100 | OBJ 101 | REQ 102 | SPD 103 | TSS 104 | FSP 105 | OPE 106 | PRE 107 | CMC 108 | CMS 109 | TSU 110 | IND 111 | VAN 112 | DTLS 113 | PBA 114 | BMG 115 | SAR 116 | SEL 117 | BCK 118 | TAB 119 | BAF 120 | BBD 121 | BD 122 | BPs 123 | BYOD 124 | CAs 125 | CCMB 126 | CEM 127 | CESG 128 | CMAC 129 | CNSS 130 | COMMS 131 | CONFIG 132 | AUTH 133 | CPUs 134 | CSEC 135 | CSP 136 | CVEs 137 | ClientHello 138 | Codebook 139 | Curve25519 140 | Coull 141 | DEK 142 | DEP 143 | DHE 144 | DISA 145 | DKM 146 | DLC 147 | DRBGs 148 | DSPs 149 | DSS 150 | EAP 151 | EAPOL 152 | ECB 153 | ECDHE 154 | EDR 155 | EWA 156 | biotable1 157 | biotable2 158 | biotable3 159 | biotable4 160 | secp256r1 161 | secp384r1 162 | secp521r1 163 | fmt 164 | smf 165 | dBm 166 | Biometrics 167 | CFB 168 | Detections 169 | Discoverable 170 | Wi-Fi 171 | Wi 172 | Fi 173 | ICMP 174 | JTAG 175 | KAT 176 | KATs 177 | KDF 178 | KHz 179 | KTS 180 | LTE 181 | Liveness 182 | MACTag 183 | MACdata 184 | MACed 185 | MDF 186 | MDM 187 | NTP 188 | MacKey 189 | MacTag 190 | MiTM 191 | NFIQ 192 | Unenroll 193 | Unenrolled 194 | Unenrollment 195 | biometrics 196 | bulleted 197 | codecs 198 | exfiltrate 199 | hotspot 200 | hotspots 201 | interoperability 202 | inverter 203 | inverters 204 | manaudit 205 | objaudit 206 | natively 207 | passcode 208 | programmatically 209 | skeletonized 210 | requestor 211 | timeframe 212 | pwd 213 | sartable 214 | uplink 215 | unenroll 216 | unenrolled 217 | unenrollment 218 | iteratively 219 | ith 220 | ivtable 221 | liveness 222 | jitter 223 | dialer 224 | amongst 225 | UMTS 226 | SSID 227 | STs 228 | ServerHello 229 | SAFAR 230 | SAFARs 231 | SARs 232 | SAs 233 | SCSV 234 | SHAVS 235 | SMS 236 | SP800 237 | SPI 238 | REK 239 | OAEP 240 | OBEX 241 | OCSP 242 | OFB 243 | OSP 244 | OSPs 245 | OTA 246 | PAE 247 | PBKDF 248 | PBKDFs 249 | PINs 250 | PIV 251 | PKV 252 | PMK 253 | PRF 254 | PSS 255 | PTK 256 | FEK 257 | FFC 258 | FLAWAPP 259 | FQDN 260 | FRR 261 | GCD 262 | GSM 263 | IAD 264 | IBPC 265 | AEAD 266 | AES 267 | ANSI 268 | AP 269 | API 270 | ASLR 271 | BAF 272 | BP 273 | BR/EDR 274 | CA 275 | CBC 276 | CCM 277 | CCMP 278 | CMC 279 | CPU 280 | CRL 281 | CSP 282 | DAR 283 | DEK 284 | DEP 285 | DH 286 | DNS 287 | DSA 288 | DTLS 289 | EAP 290 | EAPOL 291 | ECDH 292 | ECDSA 293 | EEPROM 294 | EST 295 | FIPS 296 | FM 297 | FQDN 298 | GCM 299 | GPS 300 | GPU 301 | HDMI 302 | HMAC 303 | HTTPS 304 | IEEE 305 | IP 306 | IPC 307 | IPsec 308 | KEK 309 | LE 310 | LTE 311 | MD 312 | MDM 313 | MMI 314 | MMS 315 | NFC 316 | NIST 317 | NX 318 | OCSP 319 | OID 320 | OS 321 | OTA 322 | PAE 323 | PBKDF 324 | PMK 325 | PP 326 | PTK 327 | RA 328 | RBG 329 | REK 330 | ROM 331 | RSA 332 | SHA 333 | SMS 334 | SPI 335 | SSH 336 | SSID 337 | ST 338 | TLS 339 | TOE 340 | TSF 341 | TSS 342 | URI 343 | USB 344 | USSD 345 | VPN 346 | Wi-Fi 347 | XCCDF 348 | XTS 349 | JIT 350 | IUT 351 | IEC 352 | ITSEF 353 | LMP 354 | MACtag 355 | MMU 356 | NoInputNoOutput 357 | RSASSA 358 | SoC 359 | SoCs 360 | TSFI 361 | TSFIs 362 | XEX 363 | uc 364 | uc1 365 | uc2 366 | uc3 367 | entgenpurp 368 | enthisec 369 | pergenpurp 370 | perlim 371 | un 372 | v4 373 | microSD 374 | lockscreen 375 | keystore 376 | fstack 377 | CITS 378 | Cai 379 | DasGupta 380 | Doddington 381 | Elham 382 | Scheuermann 383 | Tabassi 384 | Przybocki 385 | Kniess 386 | Elsevier 387 | Henniger 388 | Jeffreys 389 | KeyData 390 | KeysLocked 391 | NetEnv 392 | SRVName 393 | L2CAP 394 | NewWithOld 395 | RFCOMM 396 | cPP 397 | AAD 398 | AISEP 399 | Un 400 | cmcRA 401 | α 402 | cA 403 | conf 404 | cp 405 | Acknowledgements 406 | frac 407 | et 408 | al 409 | Tweakable 410 | datalevels 411 | invokable 412 | binarized 413 | testmacs 414 | encipherment 415 | kp 416 | -------------------------------------------------------------------------------- /README.adoc: -------------------------------------------------------------------------------- 1 | = Protection Profile for Mobile Device Fundamentals 2 | 3 | [cols="1,1,1,1,1,1,1,1"] 4 | |=== 5 | 8+|mobile-device 6 | 7 | | https://github.com/commoncriteria/mobile-device/tree/master[master] 8 | a| https://commoncriteria.github.io/mobile-device/master/mobile-device-release.html[📄] 9 | a|[link=https://github.com/commoncriteria/mobile-device/blob/gh-pages/master/ValidationReport.txt] 10 | image::https://raw.githubusercontent.com/commoncriteria/mobile-device/gh-pages/master/validation.svg[Validation] 11 | a|[link=https://github.com/commoncriteria/mobile-device/blob/gh-pages/master/SanityChecksOutput.md] 12 | image::https://raw.githubusercontent.com/commoncriteria/mobile-device/gh-pages/master/warnings.svg[SanityChecks] 13 | a|[link=https://github.com/commoncriteria/mobile-device/blob/gh-pages/master/SpellCheckReport.txt] 14 | image::https://raw.githubusercontent.com/commoncriteria/mobile-device/gh-pages/master/spell-badge.svg[SpellCheck] 15 | a|[link=https://github.com/commoncriteria/mobile-device/blob/gh-pages/master/TDValidationReport.txt] 16 | image::https://raw.githubusercontent.com/commoncriteria/mobile-device/gh-pages/master/tds.svg[TDs] 17 | a|image::https://raw.githubusercontent.com/commoncriteria/mobile-device/gh-pages/master/transforms.svg[transforms,150] 18 | a| 19 | https://commoncriteria.github.io/mobile-device/master/mobile-device-release-linkable.html[mobile-device-release-linkable.html] + 20 | https://commoncriteria.github.io/mobile-device/master/mobile-device-release.html[mobile-device-release.html] + 21 | https://commoncriteria.github.io/mobile-device/master/mobile-device.html[mobile-device.html] + 22 | https://commoncriteria.github.io/mobile-device/master/mobile-device-paged.pdf[mobile-device-paged.pdf] + 23 | | https://github.com/commoncriteria/mobile-device/tree/release-3.3[release-3.3] 24 | a| https://commoncriteria.github.io/mobile-device/release-3.3/mobile-device-release.html[📄] 25 | a|[link=https://github.com/commoncriteria/mobile-device/blob/gh-pages/release-3.3/ValidationReport.txt] 26 | image::https://raw.githubusercontent.com/commoncriteria/mobile-device/gh-pages/release-3.3/validation.svg[Validation] 27 | a|[link=https://github.com/commoncriteria/mobile-device/blob/gh-pages/release-3.3/SanityChecksOutput.md] 28 | image::https://raw.githubusercontent.com/commoncriteria/mobile-device/gh-pages/release-3.3/warnings.svg[SanityChecks] 29 | a|[link=https://github.com/commoncriteria/mobile-device/blob/gh-pages/release-3.3/SpellCheckReport.txt] 30 | image::https://raw.githubusercontent.com/commoncriteria/mobile-device/gh-pages/release-3.3/spell-badge.svg[SpellCheck] 31 | a|[link=https://github.com/commoncriteria/mobile-device/blob/gh-pages/release-3.3/TDValidationReport.txt] 32 | image::https://raw.githubusercontent.com/commoncriteria/mobile-device/gh-pages/release-3.3/tds.svg[TDs] 33 | a|image::https://raw.githubusercontent.com/commoncriteria/mobile-device/gh-pages/release-3.3/transforms.svg[transforms,150] 34 | a| 35 | https://commoncriteria.github.io/mobile-device/release-3.3/mobile-device-release-linkable.html[mobile-device-release-linkable.html] + 36 | https://commoncriteria.github.io/mobile-device/release-3.3/mobile-device-release.html[mobile-device-release.html] + 37 | https://commoncriteria.github.io/mobile-device/release-3.3/mobile-device.html[mobile-device.html] + 38 | https://commoncriteria.github.io/mobile-device/release-3.3/mobile-device-paged.pdf[mobile-device-paged.pdf] + 39 | |=== 40 | 41 | 42 | https://github.com/commoncriteria/mobile-device/issues[image:https://img.shields.io/github/issues/commoncriteria/mobile-device.svg?maxAge=2592000[GitHub 43 | issues Open]] 44 | 45 | This repository hosts the draft version of the Protection Profile for 46 | Mobile Device Fundamentals based on the 47 | https://commoncriteria.github.io/pp/mobile-device/mobile-device-esr.html[Essential 48 | Security Requirements (ESR)] for this technology class of products. This 49 | repository is used to facilitate collaboration and development on the 50 | draft document. See the link:#Release-Version[release] section if you 51 | are looking for the officially released version for evaluations. A list 52 | of products that have passed evaluation against this Protection Profile 53 | can be found https://www.niap-ccevs.org/Profile/Info.cfm?id=417[here]. 54 | 55 | === Draft Version 56 | 57 | * https://commoncriteria.github.io/pp/mobile-device/mobile-device-release.html[Protection 58 | Profile for Mobile Device Fundamentals] (html) 59 | * https://commoncriteria.github.io/pp/mobile-device/mobile-device-release.pdf[Protection 60 | Profile for Mobile Device Fundamentals] (pdf) 61 | 62 | === Release Version 63 | 64 | * https://www.niap-ccevs.org/Profile/Info.cfm?PPID=455&id=455[Protection 65 | Profile for Mobile Device Fundamentals v3.2] 66 | 67 | === Contributing 68 | 69 | If you are interested in contributing directly to future versions the 70 | this Protection Profile, please consider joining the NIAP technical 71 | community. * 72 | https://www.niap-ccevs.org/NIAP_Evolution/tech_communities.cfm[How to 73 | join the NIAP Technical Community (Mailing list and updates)] 74 | 75 | === Feedback 76 | 77 | Questions, comments, and fixes can be submitted to the 78 | https://github.com/commoncriteria/mobile-device/issues[repository issue 79 | tracker] 80 | 81 | === Quickstart 82 | 83 | To clone this project along with its _transforms_ submodule run: 84 | 85 | .... 86 | git clone --recursive git@github.com:commoncriteria/mobile-device.git 87 | .... 88 | 89 | or 90 | 91 | .... 92 | git clone --recursive https://github.com/commoncriteria/mobile-device.git 93 | .... 94 | 95 | To pull updates from the upstream _transforms_ submodule and commit them 96 | run: 97 | 98 | .... 99 | git submodule update --remote transforms &&\ 100 | git add transforms &&\ 101 | git commit 102 | .... 103 | 104 | ==== Development Info 105 | 106 | https://github.com/commoncriteria/transforms/wiki/Working-with-Transforms-as-a-Submodule[Help 107 | working with Transforms Submodule] 108 | 109 | === Repository Content 110 | 111 | * input - Contains the `meat' of the project. It’s the input content (in 112 | XML form) that gets transformed to readable html. 113 | * output - The output directory where the html is placed after 114 | transformation. 115 | * output/images - The directory where images are stored 116 | * transforms - Points to the transform subproject which is really a 117 | repository for resources shared amongst many Common Criteria projects. 118 | 119 | === Links 120 | 121 | * https://www.niap-ccevs.org/[National Information Assurance Partnership 122 | (NIAP)] 123 | * https://www.commoncriteriaportal.org/[Common Criteria Portal] 124 | -------------------------------------------------------------------------------- /.github/workflows/quick_build_pdf.yml: -------------------------------------------------------------------------------- 1 | name: QuickBuild v4.6pdf 20251010 2 | # Run only on demand to do quick build with both pdf and html output 3 | 4 | on: 5 | workflow_dispatch: 6 | inputs: 7 | environment: 8 | type: string 9 | default: DEV 10 | required: true 11 | 12 | jobs: 13 | test: 14 | runs-on: ubuntu-latest 15 | name: Quick Build 16 | steps: 17 | - name: Checkout project and transforms 18 | uses: actions/checkout@v3 19 | with: 20 | submodules: true 21 | 22 | - name: Install Build Packages 23 | # run: "sudo apt-get update && sudo apt-get install -y xsltproc hunspell pandoc" 24 | run: "sudo apt-get update && sudo apt-get install -y hunspell python3-lxml xsltproc" 25 | 26 | - name: Install Jing 27 | run: wget -O - https://github.com/relaxng/jing-trang/releases/download/V20181222/jing-20181222.zip | jar -x 28 | 29 | - name: Set branch name 30 | run: echo "action_branch=$(echo ${GITHUB_REF#refs/heads/})" >> $GITHUB_ENV 31 | 32 | - name: Set base URL 33 | run: echo "action_projname=${PWD##*/}" >> $GITHUB_ENV 34 | 35 | - name: Quick Build 36 | run: WARN_PATH="output/SanityChecksOutput.md" make 37 | 38 | 39 | - name: Branch Test 40 | run: | 41 | branchname=$(echo ${GITHUB_REF#refs/heads/}) 42 | if [[ $branchname =~ [0-9] ]]; then 43 | echo "action_is_release=YES" >> $GITHUB_ENV 44 | else 45 | echo "action_is_release=NO" >> $GITHUB_ENV 46 | fi 47 | 48 | # PDFify 49 | - name: PDFify 50 | run: | 51 | sudo apt install -y chromium 52 | cd output 53 | for aa in *.html; do 54 | chromium --no-sandbox --headless --disable-gpu --no-pdf-header-footer --timeout=10000 \ 55 | --print-to-pdf=${aa}.pdf \ 56 | file://${PWD}/${aa} 57 | done 58 | 59 | - id: validate 60 | run: | 61 | RNG_OUT="output/ValidationReport.txt" make validate || true 62 | 63 | - name: Set valerrors 64 | run: echo "action_valerrors=$(wc -l output/ValidationReport.txt | { read first rest ; echo $first ; } )" >> $GITHUB_ENV 65 | 66 | - id: spellcheck 67 | run: | 68 | SPELL_OUT="output/SpellCheckReport.txt" make spellcheck 69 | 70 | - name: Set spellerrors 71 | run: echo "action_spellerrors=$(wc -l output/SpellCheckReport.txt | { read first rest ; echo $first ; } )" >> $GITHUB_ENV 72 | 73 | - name: Get Transforms Date 74 | # run: echo "action_tdate=2002222" >> $GITHUB_ENV 75 | run: echo "action_tdate=$(cd transforms && git log -1 --format=%cs; cd ->/dev/null)" >> $GITHUB_ENV 76 | 77 | # - name: Get DaisyDiff 78 | # run: | 79 | # wget -O- https://github.com/AndroidKitKat/ExecuteDaisy/archive/master.zip | jar -x 80 | # [ -d "output/images" ] || mkdir "output/images"; 81 | # cp -u -r ExecuteDaisy-master/js ExecuteDaisy-master/css output; 82 | # cp -u ExecuteDaisy-master/images/* output/images; 83 | 84 | 85 | - name: Make tmp dir 86 | run: mkdir tmp 87 | 88 | # - name: diff 89 | # run: TMP=tmp make diff || true; 90 | # Little diff depends on having a git history. 91 | # The current checkout has depth=1 and has no history 92 | #- name: little diff 93 | # run: make little-diff || true 94 | 95 | - name: Outstanding TDs 96 | id: tds 97 | run: | 98 | if [ "${{steps.extract_branch.outputs.branch}}" == "master" ] && 99 | ls input/tds/*.xml ; then 100 | echo "Master branch should not have TDs" >> output/TDValidationReport.txt 101 | fi 102 | # make effective 103 | # PP_XML=output/effective.xml RNG_OUT=output/TDValidationReport.txt make validate || true 104 | # IF STATEMENT HERE 105 | # PP_XML=output/effective.xml PP_RELEASE_HTML=output/AppliedTDs.html make release 106 | # java -jar ExecuteDaisy-master/*.jar output/*-release.html output/AppliedTDs.html --file=output/AppliedTDs-Diff.html 107 | 108 | - name: Set TD badge attributes 109 | run: | 110 | NUM=$(ls input/tds/*.xml | wc -l) 111 | if [ $NUM == 0 ]; then 112 | echo "action_tdcolor=gray" >> $GITHUB_ENV 113 | echo "action_tdwarns=N/A" >> $GITHUB_ENV 114 | echo "GOING THROUGH HERE $NUM" 115 | else 116 | echo "action_tdcolor=$(if [ -s output/TDValidationReport.txt ]; then echo orange; else echo green; fi)" >> $GITHUB_ENV 117 | echo "action_tdwarns=$NUM:$(wc -l output/TDValidationReport.txt | { read first rest ; echo $first;})" >> $GITHUB_ENV 118 | echo "THERE ARE TDs $NUM" 119 | 120 | fi 121 | # Not sure what the point of this is 122 | - name: Validate Effective 123 | run: | 124 | echo "action_effvalcolor=$(if [ -s output/TDValidationReport.txt ]; then echo orange; else echo green; fi)" >> $GITHUB_ENV 125 | echo "action_effvalwarns=$(wc -l output/TDValidationReport.txt | { read first rest ; echo $first;} )" >> $GITHUB_ENV 126 | 127 | 128 | - name: Prepare environment 129 | run: | 130 | # Generates a GitHub Workflow output named `lines` with a coverage value 131 | echo "action_spellcolor=$(if [ 0 = ${{ env.action_spellerrors }} ]; then echo green; else echo red; fi)" >> $GITHUB_ENV 132 | echo "action_valcolor=$(if [ 0 = ${{ env.action_valerrors }} ]; then echo green; else echo red; fi)" >> $GITHUB_ENV 133 | echo "action_sanitystatus=$(if [ -s output/SanityChecksOutput.md ]; then echo some; else echo none; fi)" >> $GITHUB_ENV 134 | echo "action_sanitycolor=$(if [ -s output/SanityChecksOutput.md ]; then echo red; else echo green; fi )" >> $GITHUB_ENV 135 | 136 | 137 | 138 | - name: Generate the spelling badge SVG image 139 | uses: emibcn/badge-action@v2.0.2 140 | with: 141 | label: 'Misspellings' 142 | status: ${{ env.action_spellerrors }} 143 | color: ${{ env.action_spellcolor }} 144 | path: output/spell-badge.svg 145 | 146 | 147 | 148 | - name: Generate the validation badge SVG image 149 | uses: emibcn/badge-action@v2.0.2 150 | with: 151 | label: 'Validation' 152 | status: ${{ env.action_valerrors }} 153 | color: ${{ env.action_valcolor }} 154 | path: output/validation.svg 155 | 156 | 157 | - name: Generate the warnings badge 158 | uses: emibcn/badge-action@v2.0.2 159 | with: 160 | label: 'Warnings' 161 | status: ${{ env.action_sanitystatus }} 162 | color: ${{ env.action_sanitycolor }} 163 | path: output/warnings.svg 164 | 165 | 166 | - name: Generate the transforms badge 167 | uses: emibcn/badge-action@v2.0.2 168 | with: 169 | label: 'Transforms' 170 | status: ${{ env.action_tdate }} 171 | color: gray 172 | path: output/transforms.svg 173 | 174 | - name: TD Badge 175 | uses: emibcn/badge-action@v2.0.2 176 | with: 177 | label: 'TDs' 178 | status: ${{ env.action_tdwarns }} 179 | color: ${{ env.action_tdcolor }} 180 | path: output/tds.svg 181 | 182 | - name: Make Dashboard Snippet 183 | run: | 184 | rurl="https://raw.githubusercontent.com/commoncriteria/${{env.action_projname}}/gh-pages/${{env.action_branch}}" 185 | surl="https://commoncriteria.github.io/${{env.action_projname}}/${{env.action_branch}}" 186 | gurl="https://github.com/commoncriteria/${{env.action_projname}}/blob/gh-pages/${{env.action_branch}}" 187 | ( 188 | echo '[cols="1,1,1,1,1,1,1,1"]' 189 | echo '|===' 190 | echo "8+|${{ env.action_projname }} " 191 | echo "| https://github.com/commoncriteria/${{env.action_projname}}/tree/${{env.action_branch}}[${{ env.action_branch }}] " 192 | echo "a| $surl/${{env.action_projname}}-release.html[📄]" 193 | echo "a|[link=$gurl/ValidationReport.txt]" 194 | echo "image::$rurl/validation.svg[Validation]" 195 | echo "a|[link=$gurl/SanityChecksOutput.md]" 196 | echo "image::$rurl/warnings.svg[SanityChecks]" 197 | echo "a|[link=$gurl/SpellCheckReport.txt]" 198 | echo "image::$rurl/spell-badge.svg[SpellCheck]" 199 | echo "a|[link=$gurl/TDValidationReport.txt]" 200 | echo "image::$rurl/tds.svg[TDs]" 201 | echo "a|image::$rurl/transforms.svg[transforms,150]" 202 | echo "a| [link=$gurl/HTMLs.adoc]" 203 | echo "image::$rurl/html_count.svg[HTML Count]" 204 | echo "[link=$gurl/PDFs.adoc]" 205 | echo "image::$rurl/pdf_count.svg[PDF Count]" 206 | echo '|===' 207 | ) > output/Minidash.adoc 208 | 209 | 210 | - name: HTML List 211 | run: | 212 | surl="https://commoncriteria.github.io/${{env.action_projname}}/${{env.action_branch}}" 213 | ( for aa in output/*.html ; do 214 | echo "* $surl/${aa#*/}[${aa#*/}]" 215 | done ) > output/HTMLs.adoc 216 | HTML_COUNT=$(wc -l < output/HTMLs.adoc) 217 | echo "action_html_count=$HTML_COUNT" >> $GITHUB_ENV 218 | 219 | - name: PDF List 220 | run: | 221 | surl="https://commoncriteria.github.io/${{env.action_projname}}/${{env.action_branch}}" 222 | cd output 223 | (for aa in $(find . -name '*.pdf') ; do 224 | echo "* $surl/${aa#*/}[${aa#*/}]" 225 | done ) > PDFs.adoc 226 | PDF_COUNT=$(wc -l < PDFs.adoc) 227 | echo "action_pdf_count=$PDF_COUNT" >> $GITHUB_ENV 228 | 229 | 230 | - name: HTML Badge 231 | uses: emibcn/badge-action@v2.0.2 232 | with: 233 | label: 'HTMLs' 234 | status: ${{ env.action_html_count }} 235 | color: gray 236 | path: output/html_count.svg 237 | 238 | - name: PDF Badge 239 | uses: emibcn/badge-action@v2.0.2 240 | with: 241 | label: 'PDFs' 242 | status: ${{ env.action_pdf_count }} 243 | color: gray 244 | path: output/pdf_count.svg 245 | 246 | 247 | - name: Prepare checkout 248 | run: | 249 | mkdir gh-pages 250 | 251 | - uses: actions/checkout@v3 252 | with: 253 | ref: gh-pages 254 | path: gh-pages 255 | 256 | 257 | - name: Move output to branch 258 | run: | 259 | rm -rf gh-pages/${{ env.action_branch }} 260 | mv output gh-pages/${{ env.action_branch }} 261 | 262 | - name: Make listing 263 | run: | 264 | cd gh-pages 265 | (echo "Listing"; 266 | date; 267 | echo "
    "; 268 | for aa in $(find . -name '*.*'); do 269 | echo "
  1. $aa
    2. "; 270 | done; 271 | echo "
") > index.html 272 | 273 | - name: Deploy 🚀 274 | uses: JamesIves/github-pages-deploy-action@v4 275 | with: 276 | branch: gh-pages # The branch the action should deploy to. 277 | folder: gh-pages # The folder the action should deploy. 278 | -------------------------------------------------------------------------------- /.github/workflows/quick_build.yml: -------------------------------------------------------------------------------- 1 | name: QuickBuild v4.6 20251010 2 | 3 | on: 4 | push: 5 | branches: 6 | - '*' 7 | - '!gh-pages' 8 | workflow_dispatch: 9 | inputs: 10 | environment: 11 | type: string 12 | default: DEV 13 | required: true 14 | 15 | jobs: 16 | test: 17 | runs-on: ubuntu-latest 18 | name: Quick Build 19 | steps: 20 | - name: Checkout project and transforms 21 | uses: actions/checkout@v3 22 | with: 23 | submodules: true 24 | 25 | - name: Install Build Packages 26 | # run: "sudo apt-get update && sudo apt-get install -y xsltproc hunspell pandoc" 27 | run: "sudo apt-get update && sudo apt-get install -y hunspell python3-lxml xsltproc" 28 | 29 | - name: Install Jing 30 | run: wget -O - https://github.com/relaxng/jing-trang/releases/download/V20181222/jing-20181222.zip | jar -x 31 | 32 | - name: Set branch name 33 | run: echo "action_branch=$(echo ${GITHUB_REF#refs/heads/})" >> $GITHUB_ENV 34 | 35 | - name: Set base URL 36 | run: echo "action_projname=${PWD##*/}" >> $GITHUB_ENV 37 | 38 | - name: Quick Build 39 | run: WARN_PATH="output/SanityChecksOutput.md" make 40 | 41 | 42 | - name: Branch Test 43 | run: | 44 | branchname=$(echo ${GITHUB_REF#refs/heads/}) 45 | if [[ $branchname =~ [0-9] ]]; then 46 | echo "action_is_release=YES" >> $GITHUB_ENV 47 | else 48 | echo "action_is_release=NO" >> $GITHUB_ENV 49 | fi 50 | 51 | # PDFify 52 | - name: PDFify 53 | if: ${{ env.action_is_release == 'YES' }} 54 | run: | 55 | sudo apt install -y chromium 56 | cd output 57 | for aa in *.html; do 58 | chromium --no-sandbox --headless --disable-gpu --no-pdf-header-footer --timeout=10000 \ 59 | --print-to-pdf=${aa}.pdf \ 60 | file://${PWD}/${aa} 61 | done 62 | 63 | - id: validate 64 | run: | 65 | RNG_OUT="output/ValidationReport.txt" make validate || true 66 | 67 | - name: Set valerrors 68 | run: echo "action_valerrors=$(wc -l output/ValidationReport.txt | { read first rest ; echo $first ; } )" >> $GITHUB_ENV 69 | 70 | - id: spellcheck 71 | run: | 72 | SPELL_OUT="output/SpellCheckReport.txt" make spellcheck 73 | 74 | - name: Set spellerrors 75 | run: echo "action_spellerrors=$(wc -l output/SpellCheckReport.txt | { read first rest ; echo $first ; } )" >> $GITHUB_ENV 76 | 77 | - name: Get Transforms Date 78 | # run: echo "action_tdate=2002222" >> $GITHUB_ENV 79 | run: echo "action_tdate=$(cd transforms && git log -1 --format=%cs; cd ->/dev/null)" >> $GITHUB_ENV 80 | 81 | - name: Get DaisyDiff 82 | run: | 83 | wget -O- https://github.com/AndroidKitKat/ExecuteDaisy/archive/master.zip | jar -x 84 | [ -d "output/images" ] || mkdir "output/images"; 85 | cp -u -r ExecuteDaisy-master/js ExecuteDaisy-master/css output; 86 | cp -u ExecuteDaisy-master/images/* output/images; 87 | 88 | 89 | - name: Make tmp dir 90 | run: mkdir tmp 91 | 92 | - name: diff 93 | run: TMP=tmp make diff || true; 94 | # Little diff depends on having a git history. 95 | # The current checkout has depth=1 and has no history 96 | #- name: little diff 97 | # run: make little-diff || true 98 | 99 | - name: Outstanding TDs 100 | id: tds 101 | run: | 102 | if [ "${{steps.extract_branch.outputs.branch}}" == "master" ] && 103 | ls input/tds/*.xml ; then 104 | echo "Master branch should not have TDs" >> output/TDValidationReport.txt 105 | fi 106 | # make effective 107 | # PP_XML=output/effective.xml RNG_OUT=output/TDValidationReport.txt make validate || true 108 | # IF STATEMENT HERE 109 | # PP_XML=output/effective.xml PP_RELEASE_HTML=output/AppliedTDs.html make release 110 | # java -jar ExecuteDaisy-master/*.jar output/*-release.html output/AppliedTDs.html --file=output/AppliedTDs-Diff.html 111 | 112 | - name: Set TD badge attributes 113 | run: | 114 | NUM=$(ls input/tds/*.xml | wc -l) 115 | if [ $NUM == 0 ]; then 116 | echo "action_tdcolor=gray" >> $GITHUB_ENV 117 | echo "action_tdwarns=N/A" >> $GITHUB_ENV 118 | echo "GOING THROUGH HERE $NUM" 119 | else 120 | echo "action_tdcolor=$(if [ -s output/TDValidationReport.txt ]; then echo orange; else echo green; fi)" >> $GITHUB_ENV 121 | echo "action_tdwarns=$NUM:$(wc -l output/TDValidationReport.txt | { read first rest ; echo $first;})" >> $GITHUB_ENV 122 | echo "THERE ARE TDs $NUM" 123 | 124 | fi 125 | # Not sure what the point of this is 126 | - name: Validate Effective 127 | run: | 128 | echo "action_effvalcolor=$(if [ -s output/TDValidationReport.txt ]; then echo orange; else echo green; fi)" >> $GITHUB_ENV 129 | echo "action_effvalwarns=$(wc -l output/TDValidationReport.txt | { read first rest ; echo $first;} )" >> $GITHUB_ENV 130 | 131 | 132 | - name: Prepare environment 133 | run: | 134 | # Generates a GitHub Workflow output named `lines` with a coverage value 135 | echo "action_spellcolor=$(if [ 0 = ${{ env.action_spellerrors }} ]; then echo green; else echo red; fi)" >> $GITHUB_ENV 136 | echo "action_valcolor=$(if [ 0 = ${{ env.action_valerrors }} ]; then echo green; else echo red; fi)" >> $GITHUB_ENV 137 | echo "action_sanitystatus=$(if [ -s output/SanityChecksOutput.md ]; then echo some; else echo none; fi)" >> $GITHUB_ENV 138 | echo "action_sanitycolor=$(if [ -s output/SanityChecksOutput.md ]; then echo red; else echo green; fi )" >> $GITHUB_ENV 139 | 140 | 141 | 142 | - name: Generate the spelling badge SVG image 143 | uses: emibcn/badge-action@v2.0.2 144 | with: 145 | label: 'Misspellings' 146 | status: ${{ env.action_spellerrors }} 147 | color: ${{ env.action_spellcolor }} 148 | path: output/spell-badge.svg 149 | 150 | 151 | 152 | - name: Generate the validation badge SVG image 153 | uses: emibcn/badge-action@v2.0.2 154 | with: 155 | label: 'Validation' 156 | status: ${{ env.action_valerrors }} 157 | color: ${{ env.action_valcolor }} 158 | path: output/validation.svg 159 | 160 | 161 | - name: Generate the warnings badge 162 | uses: emibcn/badge-action@v2.0.2 163 | with: 164 | label: 'Warnings' 165 | status: ${{ env.action_sanitystatus }} 166 | color: ${{ env.action_sanitycolor }} 167 | path: output/warnings.svg 168 | 169 | 170 | - name: Generate the transforms badge 171 | uses: emibcn/badge-action@v2.0.2 172 | with: 173 | label: 'Transforms' 174 | status: ${{ env.action_tdate }} 175 | color: gray 176 | path: output/transforms.svg 177 | 178 | - name: TD Badge 179 | uses: emibcn/badge-action@v2.0.2 180 | with: 181 | label: 'TDs' 182 | status: ${{ env.action_tdwarns }} 183 | color: ${{ env.action_tdcolor }} 184 | path: output/tds.svg 185 | 186 | - name: Make Dashboard Snippet 187 | run: | 188 | rurl="https://raw.githubusercontent.com/commoncriteria/${{env.action_projname}}/gh-pages/${{env.action_branch}}" 189 | surl="https://commoncriteria.github.io/${{env.action_projname}}/${{env.action_branch}}" 190 | gurl="https://github.com/commoncriteria/${{env.action_projname}}/blob/gh-pages/${{env.action_branch}}" 191 | ( 192 | echo '[cols="1,1,1,1,1,1,1,1"]' 193 | echo '|===' 194 | echo "8+|${{ env.action_projname }} " 195 | echo "| https://github.com/commoncriteria/${{env.action_projname}}/tree/${{env.action_branch}}[${{ env.action_branch }}] " 196 | echo "a| $surl/${{env.action_projname}}-release.html[📄]" 197 | echo "a|[link=$gurl/ValidationReport.txt]" 198 | echo "image::$rurl/validation.svg[Validation]" 199 | echo "a|[link=$gurl/SanityChecksOutput.md]" 200 | echo "image::$rurl/warnings.svg[SanityChecks]" 201 | echo "a|[link=$gurl/SpellCheckReport.txt]" 202 | echo "image::$rurl/spell-badge.svg[SpellCheck]" 203 | echo "a|[link=$gurl/TDValidationReport.txt]" 204 | echo "image::$rurl/tds.svg[TDs]" 205 | echo "a|image::$rurl/transforms.svg[transforms,150]" 206 | echo "a| [link=$gurl/HTMLs.adoc]" 207 | echo "image::$rurl/html_count.svg[HTML Count]" 208 | echo "[link=$gurl/PDFs.adoc]" 209 | echo "image::$rurl/pdf_count.svg[PDF Count]" 210 | echo '|===' 211 | ) > output/Minidash.adoc 212 | 213 | 214 | - name: HTML List 215 | run: | 216 | surl="https://commoncriteria.github.io/${{env.action_projname}}/${{env.action_branch}}" 217 | ( for aa in output/*.html ; do 218 | echo "* $surl/${aa#*/}[${aa#*/}]" 219 | done ) > output/HTMLs.adoc 220 | HTML_COUNT=$(wc -l < output/HTMLs.adoc) 221 | echo "action_html_count=$HTML_COUNT" >> $GITHUB_ENV 222 | 223 | - name: PDF List 224 | run: | 225 | surl="https://commoncriteria.github.io/${{env.action_projname}}/${{env.action_branch}}" 226 | cd output 227 | (for aa in $(find . -name '*.pdf') ; do 228 | echo "* $surl/${aa#*/}[${aa#*/}]" 229 | done ) > PDFs.adoc 230 | PDF_COUNT=$(wc -l < PDFs.adoc) 231 | echo "action_pdf_count=$PDF_COUNT" >> $GITHUB_ENV 232 | 233 | 234 | - name: HTML Badge 235 | uses: emibcn/badge-action@v2.0.2 236 | with: 237 | label: 'HTMLs' 238 | status: ${{ env.action_html_count }} 239 | color: gray 240 | path: output/html_count.svg 241 | 242 | - name: PDF Badge 243 | uses: emibcn/badge-action@v2.0.2 244 | with: 245 | label: 'PDFs' 246 | status: ${{ env.action_pdf_count }} 247 | color: gray 248 | path: output/pdf_count.svg 249 | 250 | 251 | - name: Prepare checkout 252 | run: | 253 | mkdir gh-pages 254 | 255 | - uses: actions/checkout@v3 256 | with: 257 | ref: gh-pages 258 | path: gh-pages 259 | 260 | 261 | - name: Move output to branch 262 | run: | 263 | rm -rf gh-pages/${{ env.action_branch }} 264 | mv output gh-pages/${{ env.action_branch }} 265 | 266 | - name: Make listing 267 | run: | 268 | cd gh-pages 269 | (echo "Listing"; 270 | date; 271 | echo "
    "; 272 | for aa in $(find . -name '*.*'); do 273 | echo "
  1. $aa
    2. "; 274 | done; 275 | echo "
") > index.html 276 | 277 | - name: Deploy 🚀 278 | uses: JamesIves/github-pages-deploy-action@v4 279 | with: 280 | branch: gh-pages # The branch the action should deploy to. 281 | folder: gh-pages # The folder the action should deploy. 282 | -------------------------------------------------------------------------------- /input/esr.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | Protection Profile for Mobile Devices: Mobile Security Foundation 8 | Information Assurance Directorate 9 | 001 10 | 0.02 11 | Draft 12 | 13 | 14 | 15 | 16 | 17 |
18 | This assurance standard specifies information security requirements for Mobile Devices for 19 | use in an enterprise. A Mobile Device in the context of this assurance standard is a device 20 | which is composed of a hardware platform and its system software. The device typically 21 | provides wireless connectivity and uses application software for functions like secure 22 | messaging, email, web, VPN connection, and VoIP (Voice over IP), for access to the 23 | protected enterprise network, enterprise data and applications, and for communicating to 24 | other mobile devices. 25 |
26 | Examples of a “mobile device” that should claim compliance to this assurance standard 27 | include smartphones, tablet computers, and other mobile devices with similar capabilities. 28 |
29 | The Mobile Device provides essential services, such as cryptographic services, data-at-rest 30 | protection, and key storage services to support the secure operation of applications on the 31 | device. Additional security features such as security policy enforcement, application 32 | mandatory access control, anti-exploitation features, user authentication, and software integrity 33 | protection are implemented in order to address threats. 34 |
35 | This assurance standard describes these essential security services provided by the Mobile 36 | Device and serving as a foundation for a secure mobile architecture. It is expected that a 37 | typical deployment would also include either third-party or bundled components that 38 | provide: 39 |
    40 |
  • Data in transit protection (e.g. VPN Client, VoIP Client, Web Browser)
    • 41 |
  • Security policy management (e.g. MDM System)
    • 42 |
43 |
44 | If these components are bundled as part of the Mobile Device by the manufacturer, they 45 | may be separately validated against the related assurance standards. Additional 46 | applications that may come pre-installed on the Mobile Device that are not validated are 47 | considered to be potentially flawed, but not malicious. Examples include VoIP client, email 48 | client, and web browser. 49 |
50 | Related assurance standards 51 | This assurance standard is one of a set of complementary 52 | Mobility assurance standards that can be layered together to 53 | provide a full deployment. The set of assurance standards will 54 | consist of: 55 |
    56 |
  1. Mobile Device: Mobile Security Foundations
    2. 57 |
  2. Mobile Device Management
    3. 58 |
  3. VPN Client & Gateway
    4. 59 |
  4. VoIP Client & SIP Server
    5. 60 |
  5. Email Client
    6. 61 |
  6. Web Browser
    7. 62 |
63 |
64 | 65 |
66 | A selection of use cases is elaborated below. 67 |
68 | [USE CASE 1] Enterprise-furnished device for general-purpose enterprise use and limited 69 | personal use 70 | An enterprise-furnished device for general-purpose business use entails a significant degree 71 | of enterprise control over configuration and, possibly, software inventory. The enterprise 72 | elects to provide users with mobile devices and additional applications (such as VPN or 73 | email clients) in order to maintain control of their sensitive data and security of their 74 | networks, while trying to balance the constraints of usability and security and 75 | considerations of personal ownership and control. Users may use Internet connectivity to 76 | browse the web or access corporate mail or run enterprise applications, but this 77 | connectivity may be under significant control of the enterprise. 78 |
79 | [USE CASE 2]Enterprise-furnished device for specialized, high-security use 80 | An enterprise-furnished device with intentionally-limited network connectivity, tightly- 81 | controlled configuration, and limited software inventory is appropriate for specialized, high- 82 | security use cases. For example, the device may not be permitted connectivity to any 83 | external peripherals. It may only be able to communicate via its WiFi or cellular radios with 84 | the enterprise-run network, which may not even permit connectivity to the Internet. Use of 85 | the device may entail compliance with policies that would not be considered realistic in any 86 | general-purpose use case, yet may mitigate risks to highly sensitive information. As in the 87 | previous case, the enterprise will look for additional applications providing enterprise 88 | connectivity and services to have a similar level of assurance as the platform. 89 |
90 | [USE CASE 3] Personally-furnished device for personal and enterprise use 91 | A personally-furnished device which is used for both personal activities and enterprise data 92 | is commonly called Bring Your Own Device (BYOD). Unlike in the enterprise-furnished cases, 93 | in this use case the enterprise is limited in what security policies it can enforce on the device 94 | because the user purchased the device for personal use and is unlikely to accept 95 | policies that limit the functionality of the device. However, because the enterprise allows 96 | the user full (or nearly full) access to the enterprise network, the enterprise will require 97 | certain security policies, for example a password or screenlock policy, and may require 98 | assured enterprise software, for example a VPN client, before allowing access. 99 |
100 | [USE CASE 4] Personally-furnished device for personal and limited enterprise use 101 | A personally-furnished device may also be given access to limited enterprise services such as 102 | enterprise email. Because the user does not have full access to the enterprise or enterprise 103 | data, the enterprise may not need to enforce any security policies on the device. However, 104 | the enterprise may want secure email and web browsing with assurance that the services 105 | being provided to those clients by the mobile device are not compromised. 106 |
107 | 108 |
109 | High-level resources to be protected are identified in the Background/Purpose. 110 |
111 | 112 |
113 | Mobile devices are subject to the threats of traditional computer systems along with those 114 | entailed by their mobile nature. The requirements in this assurance standard were 115 | developed to address the threats of network eavesdropping, network attacks, physical 116 | access, and non-malicious (but potentially flawed) apps. 117 |
118 |
    119 |
  • Network eavesdropping involves an attack positioned on a wireless 120 | communications channel or elsewhere on the network infrastructure. Attackers may 121 | monitor and gain access to data exchanged between the Mobile Device and other 122 | endpoints.
    • 123 |
    124 |
  • Network attacks encompass situations in which an attacker is positioned on a 125 | wireless communications channel or elsewhere on the network 126 | infrastructure. Attackers may initiate communications with the Mobile Device or 127 | alter communications between the Mobile Device and other endpoints in order to 128 | compromise the Mobile Device. These attacks include malicious software updates 129 | of any apps or system software on the device. These attacks include spoofing of 130 | endpoint devices, such as MDM or VPN servers. These attacks also include malicious 131 | web pages or email attachments which are usually delivered over the network to 132 | devices.
    • 133 |
    134 |
  • Physical access threats involve loss or theft of the Mobile Device which may give rise 135 | to lose of confidentiality of user data including credentials. These may involve 136 | attacks which attempt to access the device through external hardware ports, 137 | through its user interface, and also through direct and possibly destructive access to 138 | its storage media. The goal of such attacks is to access data from a lost or stolen 139 | device which is not expected to return to its user. Defending against device re-use 140 | after physical compromise is out of scope for this assurance standard.
    • 141 |
    142 |
  • Malicious or flawed app threats exist because apps loaded onto the Mobile Device 143 | may include malicious or exploitable code. This code could be included intentionally 144 | by its developer or unknowingly by the developer, perhaps as a software 145 | library. Malicious apps may attempt to exfiltrate data to which they have 146 | access. They may also conduct attacks against the platform's system software which 147 | will provide them with additional privileges and the ability to conduct further 148 | malicious activities. Malicious apps may be able to control the device's sensors (GPS, 149 | camera, microphone) to gather intelligence about the user's surroundings even 150 | when those activities do not involve data resident or transmitted from the device. 151 | Flawed apps may give an attack access to perform network-based or physical 152 | attacks that otherwise would have been prevented.
    • 153 |
    154 |
  • Persistent access to a device by an attacker implies that the device has lost integrity 155 | and cannot regain it. The device has likely lost this integrity due to some other 156 | threat vector, yet the continued access by an attacker constitutes an ongoing threat 157 | in itself. In this case the device and its data may be controlled by an adversary at 158 | least as well as by its legitimate owner.
    • 159 |
160 |
161 |
162 | 163 |
164 | 165 | Random Bit Generation (RBG) 166 |
    167 |
  • 168 | RBG1: The MD shall perform all deterministic random bit generation services in accordance with [selection, 169 | choose one of: NIST Special Publication 80090 using [selection: Hash_DRBG (any), HMAC_DRBG (any), 170 | CTR_DRBG (AES), Dual_EC_DRBG (any)]; FIPS Pub 1402 Annex C: X9.31 Appendix 2.4 using AES]. 171 |
    • 172 |
    173 |
  • 174 | RBG2: The deterministic RBG (RBG1) shall be seeded with a minimum of [selection, choose one of: 128 175 | bits, 256 bits] of entropy at least equal to the greatest security strength(according to NIST SP80057) of the 176 | keys and authorization factors that it will generate. The deterministic RBG shall be seeded by an entropy 177 | source that accumulated entropy from an MD hardware-based noise source, and [selection: a 178 | software-based noise source, other independent MD-hardware-based noise source, no other noise source]. 179 |
    • 180 |
    181 |
  • 182 | RBG-3: The MD shall be capable of providing output of the RBG to applications running on the MD that 183 | request random bits. 184 |
    • 185 |
    186 |
  • 187 | RBG-4: (Objective) The MD shall allow applications to add data to the deterministic RBG (RBG-1) using the 4 188 | Personalization String. The MD shall NOT count data input from an application towards the entropy required 189 | by RBG-2. Thus, the MD shall not allow the only input to the RBG seed to be from an application. 190 |
    • 191 |
    192 |
  • 193 | RBG-5: (Objective) The MD shall save the state of the deterministic RBG (RBG-1) at power-off, and shall 194 | use this state in seeding the deterministic RBG at startup. The saved state shall not count towards the 195 | entropy required by RBG-2. 196 |
    • 197 |
    198 |
199 |
200 | 201 | Keys 202 |
    203 |
  • KEY1: The MD shall support a hardwareprotected REK with an AES key size of 128 or 256 bits. The key 204 | shall not be able to be imported to or exported from the hardware. System software on the MD shall be able 205 | only to request encryption/decryption by the key. A REK shall be generated by a RBG in accordance with 206 | RBG1 and RBG2. 207 |
    • 208 |
    209 |
  • 210 | KEY-2: All DEKs shall be randomly generated with an RBG that meets this PP. All DEKs shall have 211 | entropy corresponding to the security strength of AES key sizes of 128 or 256 bits. 212 |
    • 213 |
    214 |
  • 215 | KEY-3: All KEKs, outside of those defined by standard protocols, shall be 128-bit or 256-bit keys, 216 | corresponding to the security strength of the keys encrypted by the KEK 217 |
    • 218 |
    219 |
  • 220 | KEY-4: KEKs may either be generated, derived from a Password Authentication Factor, or combined from 221 | other KEKs: 222 |
      223 |
    • 224 | If generated, the KEK will be randomly generated with an RBG that meets this profile 225 |
      • 226 |
    • 227 | If derived from a password, the password/passphrase shall be conditioned with a PBKDF as 228 | described in NIST SP 800-132 with a salt generated using a RBG as specified in this PP, and an 229 | HMAC using SHA-1, SHA-224, SHA-256, SHA-384, or SHA-512. The output of the conditioning 230 | function shall be equal in size to the size of the KEK. The SHA algorithm should use FIPS 180-4 231 | "Secure Hash Standard." The output of the conditioning function shall be equal in size to the size of 232 | the data encryption keys. 233 |
      • 234 |
    • 235 | If combined from other KEKs, they shall be combined in a way that preserves the effective entropy 236 | of each factor. Options include using an XOR operation, concatenating the keys and use a KDF (as 237 | described in SP800-108), or encrypting one key with another. 238 |
      • 239 |
    240 |
    • 241 |
    242 |
  • 243 | KEY-5: The MD shall not store any plaintext key material in readable non-volatile memory. 244 |
    • 245 |
    246 |
  • 247 | The MD shall provide secure key storage for asymmetric keys, symmetric keys, and persistent 248 | secrets (e.g. passwords). 249 |
      250 |
    • Supported asymmetric algorithms shall include RSA, DSA, ECDSA
      • 251 |
    • Supported symmetric algorithms shall include AES
      • 252 |
    253 |
    • 254 |
    255 |
  • 256 | KEY-7: The MD shall be capable of importing keys/secrets into the secure key storage upon request of the 257 | user or applications running on the MD. 258 |
    • 259 |
    260 |
  • 261 | KEY-8: The MD shall have the capability to allow only the application that imported the key/secret the use 262 | of the key/secret without user approval. An application’s use of keys/secrets imported by the user shall 263 | require user approval. 264 |
    • 265 |
    266 |
  • 267 | KEY-9: The MD shall allow only the application that imported the key/secret to request that the key/secret 268 | be destroyed without user approval. The MD shall require the user to approve any application’s request for 269 | the destruction of another application’s key or of a user-imported key. Key destruction shall meet KEY-9. 270 |
    • 271 |
    272 |
  • 273 | KEY-10: All DEKs and all software-based key storage shall be encrypted by KEKs that are either: 274 |
      275 |
    1. 276 | Protected by a REK: 277 |
        278 |
      1. 279 | encrypted by a REK; or 280 |
        2. 281 |
      2. 282 | encrypted by a KEK chaining to a REK 283 |
        3. 284 |
      285 | OR 286 |
      2. 287 |
    2. 288 | Protected by a REK and the password: 289 |
        290 |
      1. 291 | encrypted by a REK and the password-derived KEK; or 292 |
        2. 293 |
      2. 294 | encrypted by a KEK chaining to a REK and the password-derived KEK. 295 |
        3. 296 |
      297 | A REK and the password-derived KEK may be combined to form a combined KEK (as described in 298 | KEY-4) in order to meet this requirement. 299 |
      3. 300 |
    301 | Sensitive data (DAR-5) shall be protected according to 2, The software-based key storage shall either all be 302 | protected according to 2 or shall allow users and applications to mark the key as sensitive (protected 303 | according to 2). 304 |
    • 305 |
    306 |
  • 307 | KEY-11: The integrity of any encrypted key, including software-based key storage, shall be protected from 308 | corruption by at least one of: 309 |
      310 |
    • 311 | a AEAD or Key Wrap cipher mode (Key Wrap, Key Wrap with Padding, GCM, or CCM) for 312 | encryption according to KEY-10; 313 |
      • 314 |
    • 315 | a hash (ALG-4) of the stored key that is encrypted by a key protected by KEY-10; 316 |
      • 317 |
    • 318 | a keyed hash (ALG-6) using a key protected by a key protected by KEY-10; 319 |
      • 320 |
    • 321 | a digital signature of the stored key using an asymmetric key protected according to KEY-10. 322 |
      • 323 |
    324 | The hash/digital signature shall be verified before use of the stored key. 325 |
    • 326 |
    327 |
  • 328 | KEY-12:  The MD shall clear cryptographic keys contained within the MD either by clearing the KEK 329 | encrypting the target key or in accordance with the following rules: 330 |
      331 |
    • 332 | For non-volatile memory other than EEPROM and flash, the destruction shall be executed by 333 | overwriting three or more times using a different alternating data pattern each time. 334 |
      • 335 |
    • 336 | For volatile memory and non-volatile EEPROM, the destruction shall be executed by a single direct 337 | overwrite consisting of a pseudo random pattern based on the RBG specified in this PP, followed a 338 | read-verify. 339 |
      • 340 |
    • 341 | For volatile memory and non-volatile flash memory, the destruction shall be executed by a single 342 | direct overwrite consisting of zeros followed by a read-verify or by a block erase followed by a 343 | read-verify. 344 |
      • 345 |
    346 |
    • 347 |
    348 |
  • 349 | KEY-13: Plaintext DEKs, and KEKs shall not be exportable by the user or administrator. 350 |
    • 351 |
    352 |
  • 353 | KEY-14: Whenever a KEK is used for encryption, it must have a unique IV for every key that it encrypts 354 | when applicable for the encryption mode (reference the NIST SP 800-38 series). 355 |
    • 356 |
    357 |
  • 358 | KEY-15: All salts shall be generated using a RBG as specified in this paper. 359 |
    • 360 |
    361 |
  • 362 | KEY-16: No plain text key material (intermediate keys, passwords, etc.) shall be transmitted from the 363 | process which makes use of it. 364 |
    • 365 |
    366 |
  • 367 | KEY-17: All code for the product shall clear all plaintext keying material (authentication data, secret/private 368 | symmetric keys, etc.) in volatile memory according to KEY-12 when entering the powered off state. 369 |
    • 370 |
    371 |
372 | 373 | Cryptographic Algorithm Services 374 |
    375 |
  • 376 | ALG-1: The MD shall generate asymmetric cryptographic keys used for key establishment in accordance 377 | with at least one of: 378 |
      379 |
    • 380 | NIST Special Publication 800-56A, “Recommendation for Pair-Wise Key Establishment Schemes Using  381 | Discrete Logarithm Cryptography” for finite field-based key establishment schemes; 382 |
      • 383 |
    • 384 | NIST Special Publication 800-56A, “Recommendation for Pair-Wise Key Establishment Schemes Using  385 | Discrete Logarithm Cryptography” for elliptic curve-based key establishment schemes and 386 | implementing “NIST curves” P-256, P-384 and [selection: P-521, no other curves] (as defined in 387 | FIPS PUB 186-3, “Digital Signature Standard”) 388 |
      • 389 |
    • 390 | [selection: NIST Special Publication 800-56B, “Recommendation for Pair-Wise Key Establishment 391 | Schemes Using Integer Factorization Cryptography” for RSA-based key establishment schemes, no 392 | other] 393 |
      • 394 |
    395 | are specified cryptographic key sizes equivalent to, or greater than, a symmetric key stength of 112 396 | bits. 397 |
    • 398 |
    399 |
  • 400 | ALG-2: The MD shall perform encryption/decryption of data for transport using AES operating in CBC (as 401 | defined in NIST SP 800-38A), GCM (as defined in NIST SP 800-38D), or CCM (as defined in NIST SP 402 | 800-38C) with 128-bit or 256-bit key sizes. 403 |
    • 404 |
    405 |
  • 406 | ALG-3: The MD shall perform encryption/decryption of keys for storage using Key Wrap (KW) (as defined in 407 | NIST SP 800-38F), or Key Wrap with Padding (KWP) (as defined in NIST SP 800-38F), or GCM (as defined 408 | in NIST SP 800-38D), or CCM (as defined in NIST SP 800-38C), or CBC (as defined in NIST SP 800-38A) 409 | mode with 128-bit or 256-bit key sizes. 410 |
    • 411 |
    412 |
  • 413 | ALG-4: The MD shall perform encryption/decryption of data for storage using AES operating in CBC (as 414 | defined in NIST SP 800-38A), or XTS (as defined in NIST SP 800-38E) with 128-bit or 256-bit key sizes. 415 |
    • 416 |
    417 |
  • 418 | ALG-5: The MD shall perform cryptographic hashing using SHA-1, SHA-256, SHA-384, SHA-512 algorithms 419 | (FIPS Pub 180-4). 420 |
    • 421 |
    422 |
  • 423 | ALG-6: The MD shall perform cryptographic signature services (generation and verification) using: RSA with a  424 | key size (modulus) of 2048 bits or greater (FIPS Pub 186-3) or ECDSA with a key size of 256 bits or 425 | greater using NIST curves P-256, P-384, P-521 (FIPS Pub 186-3). 426 |
    • 427 |
    428 |
  • 429 | ALG-7: The MD shall perform keyed-hash message authentication in accordance with a specified 430 | cryptographic algorithm HMAC-[selection: SHA-1, SHA-256, SHA-384, SHA-512], key sizes [assignment: 431 | key size (in bits) used in HMAC], and message digest sizes [selection: 160, 256, 384, 512] bits that meet 432 | the following: FIPS Pub 198-1, "The Keyed-Hash Message Authentication Code, and FIPS Pub 180-4, 433 | “Secure Hash Standard.” 434 |
    • 435 |
    436 |
  • 437 | ALG-8: The MD shall generate asymmetric cryptographic keys used for authentication in accordance with a 438 | [selection, choose at least one of: 439 |
      440 |
    • 441 | FIPS PUB 186-3, “Digital Signature Standard (DSS)”, Appendix B.3 for RSA schemes; 442 |
      • 443 |
    • 444 | FIPS PUB 186-3, “Digital Signature Standard (DSS)”, Appendix B.4 for ECDSA schemes and 445 | implementing “NIST curves” P-256, P-384 and [selection: P-521, no other curves]; 446 |
      • 447 |
    • 448 | ANSI X9.31-1998, Appendix A.2.4 Using AES for RSA schemes] 449 |
      • 450 |
    451 | and specified cryptographic key sizes equivalent to, or greater than, a symmetric key strength of 112 bits. 452 |
    • 453 |
    454 |
  • 455 | ALG-9: The MD shall run a suite of self-tests during initial start-up (on power-up) to demonstrate the correct 456 | operation of all cryptographic functionality. This can be performed via known-answer tests. 457 |
    • 458 |
    459 |
  • 460 | ALG-10: The MD shall provide a mechanism for applications to request the MD to perform cryptographic 461 | algorithm services. 462 |
    • 463 |
    464 |
465 | 466 | Certificates 467 |
    468 |
  • 469 | CER-1: The MD shall store a list of trusted root Certificate Authority (CA) certificates, called the Trust 470 | Anchor Database. 471 |
    • 472 |
    473 |
  • 474 | CER-2: The MD shall be capable of importing certificates into the Trust Anchor Database upon request of 475 | the user, applications, or the administrator. The MD shall require user approval before importing certificates 476 | from applications. 477 |
    • 478 |
    479 |
  • 480 | CER-3: The MD shall allow users, applications, and the administrator to remove and modify certificates from 481 | the Trust Anchor Database. The MD shall require user approval before removing or modifying a certificate 482 | upon an application’s request. 483 |
    • 484 |
    485 |
  • 486 | CER-4: The MD shall validate certificates using [selection: the Online Certificate Status Protocol (OCSP) as 487 | specified in RFC 2560, a Certificate Revocation List (CRL) as specified in RFC 5759] and in accordance with 488 | RFC 5280 certificate validation and certificate path validation. To be valid, the path must terminate with a 489 | certificate in the Trust Anchor Database. The MD shall validate a certificate path by ensuring the presence of 490 | the basicConstraints extension is present and the cA flag is set to TRUE for all CA certificates. 491 |
    • 492 |
    493 |
  • 494 | CER-5: The MD shall not treat a certificate as a CA certificate if the basicConstraints extension is not 495 | present or the CA flag is not set to TRUE. 496 |
    • 497 |
    498 |
  • 499 | CER-6: The MD shall allow applications to request certificate validation, shall perform the validation in 500 | accordance with CER-4, and shall respond to the application with a value indicating the result of that 501 | validation. 502 |
    • 503 |
    504 |
505 | 506 | Data-At-Rest Protection 507 |
    508 |
  • 509 | General DAR 510 |
      511 |
    • 512 | DAR-1: Before decryption of sensitive data, the product shall require user authentication in the form of a 513 | password. 514 |
      • 515 |
      516 |
    • 517 | DAR-2: Aside from configuring the product and providing the authorization credential, the user should not 518 | have any interaction with the DAR protection. Encryption shall cover all non-system data and shall not 519 | require the user to mark specific files as sensitive. 520 |
      • 521 |
      522 |
    523 |
    • 524 |
  • 525 | DAR for Screen Lock 526 |
      527 |
    • 528 | DAR-3: The product shall include a key scheme to encrypt data received while the product is locked. The 529 | key scheme shall involve an asymmetric public/private key pair, shall prevent the received (stored) data (at 530 | rest) from being decrypted in the locked state, and shall require authentication factors to be entered to 531 | unlock the device before the data can be decrypted. 532 |
      • 533 |
      534 |
    • 535 | DAR-4: Sensitive data received while the product is in a locked state shall be encrypted and protected by a 536 | key scheme satisfying the requirements specified in DAR-3 and ALG-1 of this profile. 537 |
      • 538 |
      539 |
    • 540 | DAR-5 The MD shall provide a mechanism for applications to mark data and keys as sensitive, and, 541 | therefore inaccessible in the locked state. 542 |
      • 543 |
      544 |
    • 545 | DAR-6:  Attempts to decrypt keys and files that have not been marked as sensitive shall fail in locked 546 | states and be able to succeed only during unlocked states. 547 |
      • 548 |
      549 |
    • 550 | DAR-7: When locked state is initiated, the product shall clear sensitive decryption keys and all sensitive 551 | plaintext keying material (authentication data, secret/private symmetric keys, etc.) in volatile memory 552 | according to KEY-12 for all data not designated/marked to be available at screen lock. (Note that this 553 | requirement corresponds to AUTH-5 and AUTH-6.) 554 |
      • 555 |
      556 |
    557 |
    • 558 |
  • 559 | Data Wipe 560 |
      561 |
    • 562 | DAR-8: The wipe command shall either 563 |
        564 |
      1. 565 | Cryptographically erase the encrypted DEKs and/or the KEKs in non-volatile memory by following 566 | the requirements in KEY-12; or 567 |
        2. 568 |
      2. 569 | Overwrite the entire memory and drive space using non-sensitive data such as a pseudorandom 570 | data pattern or a fixed data value.  The following requirements will be followed, based on the 571 | memory type. 572 |
          573 |
        • 574 | For non-volatile memory other than EEPROM and flash, the wipe shall be executed by 575 | overwriting three or more times using a different alternating data pattern each time. 576 |
          • 577 |
        • 578 | For volatile memory and non-volatile EEPROM, the wipe shall be executed by a single 579 | direct overwrite consisting of a pseudo random pattern based on the RBG specified in this 580 | PP, followed a read-verify. 581 |
          • 582 |
        • 583 | For volatile memory and non-volatile flash memory, the wipe shall be executed by a single 584 | direct overwrite consisting of zeros followed by a read-verify, or by a block erase followed by 585 | a read-verify. 586 |
          • 587 |
        588 |
        3. 589 |
      590 |
      • 591 |
    592 |
    • 593 |
594 |
595 | Management 596 |
    597 |
  • 598 | MGMT-1: The MD shall provide its user and the administrator the ability to query the current version of the 599 | MD operating system and all firmware that can be updated separately. [MOS PP FPT_TUD_EXT.1.1(1)] 600 |
    • 601 |
    602 |
  • 603 | MGMT-2: The MD shall provide its user and the administrator the ability to query the hardware model of the 604 | device. This hardware model identifier must be sufficient to indicate, in tandem with manufacturer 605 | documentation, the hardware which comprises the device. 606 |
    • 607 |
    608 |
  • 609 | MGMT-3: The MD shall provide its user and the administrator the ability to query the current version of all 610 | installed mobile applications. [MOS PP FPT_TUD_EXT.1.1(2)] 611 |
    • 612 |
    613 |
  • 614 | MGMT-4: (Objective) The MD shall cryptographically sign all responses to device identifier queries in 615 | MGMT-1, MGMT-2, and MGMT-3. The key used to perform this signature shall be protected by the secure 616 | key storage (KEY-6). 617 |
    • 618 |
    619 |
  • 620 | MGMT-5: The MD shall provide the user the following management functions  [MDPP FMT_SMF.1.1] 621 |
      622 |
    • 623 | management of session locking; [MDM PP 2.1.1 Screen Lock] 624 |
        625 |
      • screen-lock enabled/disabled
        • 626 |
      • screen lock timeout (AUTH-5)
        • 627 |
      • number of authentication failures (AUTH-1)
        • 628 |
      629 |
      • 630 |
    • 631 | management of the enable/disable state the VPN protection; [MDM PP 2.5.1 VPN Enable/Disable] 632 |
      • 633 |
    • 634 | (High-security) management of enable/disable state of data transfer capabilities over [assignment: 635 | list of externally accessible hardware ports (e.g. USB, SD card, HDMI)];[MDM PP 2.7.1 Peripherals 636 | Enable/Disable] 637 |
      • 638 |
    • 639 | (High-security) management of enable/disable state of [assignment: list of radios (e.g. Wi-Fi, GPS, 640 | cellular, NFC, Bluetooth)]; [MDM PP 2.7.1 Peripherals Enable/Disable] 641 |
      • 642 |
    • 643 | (High-security) management of enable/disable state of [assignment: list of audio or visual collection 644 | devices (e.g. camera, microphone)]; [MDM PP 2.7.1 Peripherals Enable/Disable] 645 |
      • 646 |
    • 647 | if developer modes are supported, management of enable/disable state of developer modes [MDM 648 | PP 2.2.1 Debug Mode] 649 |
      • 650 |
    • 651 | management of enable state of data-at-rest protection (section 1.5) if not natively enabled [MDM PP 652 | 2.6.1 DAR Protection Enable] 653 |
        654 |
      • 655 | if removable storage is supported, management functions should include enable of 656 | removable media’s data-at-rest protection 657 |
        • 658 |
      • 659 | if the MD offers the option to locally bypass authentication while in the locked state using 660 | features such as “Forgot password”, management functions shall include enable/disable of 661 | this feature. 662 |
        • 663 |
      664 |
      • 665 |
    • 666 | [selection: (High-security) management of the Access Point Name and proxy used for 667 | communications between the cellular network and other networks, [assignment: list of other 668 | management functions to be provided by the MD], no other management functions]. 669 |
      • 670 |
    671 |
    • 672 |
    673 |
  • 674 | MGMT-6: The MD shall provide the administrator the following management functions  [MDPP 675 | FMT_SMF.1.1] 676 |
      677 |
    • 678 | password policy management (AUTH-4); [MDM PP 2.1.3 Password Reset] 679 |
        680 |
      • minimum password length (AUTH-9)
        • 681 |
      • minimum password complexity (AUTH-9)
        • 682 |
      • maximum password lifetime
        • 683 |
      684 |
      • 685 |
    • 686 | management of session locking policy; [MDM PP 2.1.1 Screen Lock] 687 |
        688 |
      • screen-lock enabled/disabled
        • 689 |
      • screen lock timeout (AUTH-5)
        • 690 |
      • number of authentication failures (AUTH-1)
        • 691 |
      692 |
      • 693 |
    • 694 | management of the enable/disable state the VPN protection [MDM PP 2.5.1 VPN Enable/Disable] 695 |
      • 696 |
    • 697 | (High-security) management of enable/disable state of data transfer capabilities over [assignment: 698 | list of externally accessible hardware ports (e.g. USB, SD card, HDMI)];[MDM PP 2.7.1 Peripherals 699 | Enable/Disable] 700 |
      • 701 |
    • 702 | (High-security) management of enable/disable state of [assignment: list of radios (e.g. Wi-Fi, GPS, 703 | cellular, NFC, Bluetooth)]; [MDM PP 2.7.1 Peripherals Enable/Disable] 704 |
      • 705 |
    • 706 | (High-security) management of enable/disable state of [assignment: list of audio or visual collection 707 | devices (e.g. camera, microphone)]; [MDM PP 2.7.1 Peripherals Enable/Disable] 708 |
      • 709 |
    • 710 | if developer modes are supported, management of enable/disable state of developer modes [MDM 711 | PP 2.2.1 Debug Mode] 712 |
      • 713 |
    • 714 | management of enable state of data-at-rest protection (section 1.5) if not natively enabled [MDM PP 715 | 2.6.1 DAR Protection Enable] 716 |
        717 |
      • 718 | if removable storage is supported, management functions should include enable of 719 | removable media’s data-at-rest protection 720 |
        • 721 |
      • 722 | if the MD offers the option to locally bypass authentication while in the locked state using 723 | features such as “Forgot password”, management functions shall include enable/disable of 724 | this feature. Any offered remote authentication bypass (such as remote password reset) 725 | requires an authorized administrator (MGMT-8). 726 |
        • 727 |
      728 |
      • 729 |
    • 730 | management of application installation policies: either specifying authorized application 731 | repository(s) or specifying a set of allowed applications and versions (an application whitelist) 732 |
      • 733 |
    • 734 | [selection: (High-security) management of the Access Point Name and proxy used for 735 | communications between the cellular network and other networks, [assignment: list of other 736 | management functions to be provided by the MD], no other management functions]. 737 |
      • 738 |
    739 |
    • 740 |
    741 |
  • 742 | MGMT-7: The MD shall be capable of performing management of the WLAN trusted channel to specify 743 | wireless networks (SSID) that are acceptable for the MD to connect (WLAN-11) and the following 744 | management functions for each network: 745 |
      746 |
    • 747 | Specify the CA(s) from which the MD will accept WLAN authentication server certificate(s) or 748 | specify the FQDN(s) of acceptable WLAN authentication server certificate(s), (WLAN-8, WLAN-10) 749 |
      • 750 |
    • 751 | ability to specify security type (e.g. WPA2-PSK, WPA2 Enterprise) 752 |
      • 753 |
    • 754 | ability to specify authentication protocol (WLAN-5) (e.g. EAP-TLS) 755 |
      • 756 |
    • 757 | specify the client credentials to be used for authentication 758 |
      • 759 |
    • 760 | [assignment: any additional WLAN management functions]. 761 |
      • 762 |
    763 |
    • 764 |
    765 |
  • 766 | MGMT-8: While in the unenrolled state, the MD shall restrict the ability to perform the functions to manage 767 | the MD security functions and execute administrative commands to the user. While in the enrolled state, 768 | the MD shall restrict the ability to perform [selection: all management functions, [assignment:list of 769 | management functions]] to the administrator. If the administrator does not have a policy set for a 770 | management function, the user retains the right to perform the management function. [MDPP 771 | FMT_MOF.1.1(1)] 772 |
    • 773 |
    774 |
  • 775 | MGMT-9: The MD shall provide remediation actions to users and administrators including: 776 |
      777 |
    • 778 | alerting the user or administrator 779 |
      • 780 |
    • 781 | transitioning to the locked state 782 |
      • 783 |
    • 784 | full wipe of all data according to DAR-8 785 |
      • 786 |
    • 787 | [selection: wipe of sensitive data, removal of installed applications, [assignment: list of other 788 | remediation actions], no other remediation actions]. 789 |
      • 790 |
    791 |
    • 792 |
    793 |
  • 794 | MGMT-10: The MD shall perform remediation actions in MGMT-9 on command of the administrator or on 795 | administrator-configured triggers including at least authentication failures (AUTH-2) and unenrollment. 796 |
    • 797 |
    798 |
  • 799 | MGMT-11: The MD shall allow administrators to set policies regarding the management function in MGMT-6 800 | and MGMT-7, shall enforce those policies, and shall be capable of reporting that the policy is currently in 801 | effect. 802 |
    • 803 |
    804 |
  • 805 | (Objective) The MD shall provide read access to audit logs kept by the MD (in accordance with 806 | INT-12) to the administrator. 807 |
    • 808 |
    809 |
  • 810 | MGMT-13: (BYOD)(Objective) The MD, if it supports policies from multiple management sources, will resolve 811 | any differences by enforcing the most restrictive. If there is no clear policy hierarchy, the MD shall panic and 812 | make a car-alarm sound. Or notify the user and the administrators. 813 |
    • 814 |
    815 |
  • 816 | MGMT-14: (BYOD) The MD shall require user approval to enroll in management. This user approval notice 817 | shall include the policies to be applied by the agent. 818 |
    • 819 |
    820 |
  • 821 | MGMT-15: (BYOD)(Objective) The MD shall notify the user of any change made by the administrator to the 822 | enforced policies. 823 |
    • 824 |
    825 |
  • 826 | MGMT-16: (High-security)(Objective) The MD shall provide management functions to the user and 827 | administrator to restrict 828 |
      829 |
    • 830 | cellular voice functionality, including the ability to disable voice calls completely (except emergency 831 | dialing). 832 |
      • 833 |
    • 834 | device messaging capabilities (e.g. SMS, MMS, and voicemail) including the ability to disable 835 | device messaging completely. 836 |
      • 837 |
    • 838 | the cellular protocols used to connect to cellular network base stations 839 |
      • 840 |
    • 841 | voice command control of device functions 842 |
      • 843 |
    844 |
    • 845 |
    846 |
847 | Access Control & Separation 848 |
    849 |
  • 850 | Access Control 851 |
      852 |
    • 853 | ACC-1: The OS shall enforce a mandatory access control policy that prevents processes from modifying the 854 | OS, device drivers, system and security configuration files, and key material with the exception of those 855 | processes dedicated to performing updates of those elements. 856 |
      • 857 |
      858 |
    • 859 | ACC-2: (objective) The OS shall be configurable to enforce a mandatory access control policy that prevents 860 | application processes from accessing data stored by other applications unless such sharing is explicitly 861 | authorized by the user, or the applications originate from a common publisher. 862 |
      • 863 |
      864 |
    • 865 | ACC-3: (objective) The OS shall be configurable to enforce a mandatory access control policy that prevents 866 | applications from writing files to locations on local device storage that can be read by other applications.  An 867 | exception is to facilitate sharing, which must be explicitly authorized by the user or performed by 868 | applications which originate from a common publisher. 869 |
      • 870 |
      871 |
    • 872 | ACC-4: (objective) The OS shall be configurable to enforce a mandatory access control policy that prohibits 873 | all IPC mechanisms between apps except for that which is explicitly permitted. 874 |
      • 875 |
      876 |
    • 877 | ACC-5: The OS shall enforce a mandatory access control policy that restricts the system services to which 878 | an application may communicate via IPC mechanisms. 879 |
      • 880 |
      881 |
    • 882 | ACC-6: The OS shall enforce a mandatory access control policy that prohibits an application from having 883 | both write and execute permission to a file on the device. 884 |
      • 885 |
      886 |
    • 887 | ACC-7: The OS shall enforce a mandatory access control policy that requires application processes to 888 | obtain authorization in order to access sensitive data. 889 |
      • 890 |
    891 |
    892 |
    • 893 |
  • 894 | Anti-Exploitation Services 895 |
      896 |
    • 897 | AEX-1: The OS shall provide address space layout randomization (ASLR) to applications.  The OS shall 898 | randomly position all memory mappings of an application process at selection: [its load time, the load time 899 | of its parent process]. The base address of any userspace memory mapping will consist of at least 8 900 | random bits provided by the MD RBG services. 901 |
      • 902 |
      903 |
    • 904 | AEX-2: The mobile operating system and its memory management unit shall be capable of enforcing a 905 | policy which prevents any range of addresses (page, segment, region) of a process from being 906 | simultaneously writable and executable, except for memory used for just in time (JIT) compilation. 907 |
      • 908 |
      909 |
    • 910 | AEX-3: (Objective) The bootloader shall provide address space layout randomization (ASLR) for the OS 911 | kernel. The bootloader shall randomly position the kernel image at load time. The base address of the kernel 912 | memory mapping will consist of at least 4 bits which cannot be inferred by an adversary without an 913 | information leak. 914 |
      • 915 |
      916 |
    • 917 | AEX-4: (Objective) The mobile operating system and its memory management unit shall enforce a policy 918 | which prevents any range of addresses (page, segment, region) of the kernel from being simultaneously 919 | writable and executable.  The memory management unit shall enforce these memory protections and 920 | transition the system to a non-operational state if any violation is detected. 921 |
      • 922 |
      923 |
    924 |
    • 925 |
  • 926 | Baseband Separation 927 |
      928 |
    • 929 | BBD-1: (High-security)(Objective) Code executing on any baseband processor (BP) shall not be able to 930 | access application processor (AP) resources except when mediated by the AP.  931 | These resources include: 932 |
        933 |
      • 934 | Volatile and non-volatile memory 935 |
        • 936 |
      • 937 | Control of and data from integrated and non-integrated peripherals (e.g. USB controllers, touch 938 | screen controllers, LCD controller, codecs) 939 |
        • 940 |
      • 941 | Control of and data from integrated and non-integrated I/O sensors (e.g. camera, light, mic, GPS, 942 | accelerometers, geomagnetic field sensors) 943 |
        • 944 |
      945 |
      • 946 |
      947 |
    948 |
    • 949 |
950 | Trusted Channel 951 |
    952 |
  • 953 | Information Flow Control 954 |
      955 |
    • 956 | IFC-1: (High-security) The MD shall have the ability to route all IP traffic (other than IP traffic required to 957 | establish the VPN connection) through a VPN client. The MD shall either provide this routing configuration or 958 | shall allow the VPN client to specify this routing. 959 |
      • 960 |
      961 |
    • 962 | IFC-2: The MD shall enforce the [assignment: Enterprise Information Flow Control SFP] on [assignment: all 963 | communication to and from the mobile device enterprise perimeter]. [MDPP FDP_IFC.1.1] 964 |
      • 965 |
      966 |
    • 967 | IFC-3: The MD shall enforce the [assignment: Enterprise Information Flow Control SFP] based on the 968 | following types of subject and information security attributes: [assignment: list of subjects and information 969 | controlled under the indicated SFP, and for each, the security ]. [MDPP FDP_IFF.1.1(1)] 970 |
      • 971 |
      972 |
    • 973 | IFC-4: The MD shall permit an information flow between a controlled subject and controlled information via a 974 | controlled operation if the following rules hold: [assignment: for each operation, the security attribute-based 975 | relationship that must hold between subject and information security attributes]. [MDPP FDP_IFF.1.2(1)] 976 |
      • 977 |
      978 |
    • 979 | IFC-5: The MD shall enforce the [assignment: additional information flow control SFP rules]. [MDPP 980 | FDP_IFF.1.3(1)] 981 |
      • 982 |
      983 |
    • 984 | IFC-6: The MD shall explicitly authorise an information flow based on the following rules: [assignment: rules, 985 | based on security attributes, that explicitly authorise information flows]. [MDPP FDP_IFF.1.4(1)] 986 |
      • 987 |
      988 |
    • 989 | IFC-7: The MD shall explicitly deny an information flow based on the following rules: [assignment: rules, 990 | based on security attributes, that explicitly deny information flows]. [MDPP FDP_IFF.1.5(1)] 991 |
      • 992 |
      993 |
    • 994 | IFC-8: The MD shall enforce that any previous information content of a resource is made unavailable upon 995 | the [selection: allocation of the resource to, deallocation of the resource from] all objects. 996 |
      • 997 |
      998 |
    999 |
    • 1000 |
  • 1001 | WLAN Trusted Channel 1002 |
      1003 |
    • 1004 | WLAN-1: The MD shall be capable of communicating over a trusted channel using Wi-Fi. 1005 |
      • 1006 |
      1007 |
    • 1008 | WLAN-2: The MD shall derive symmetric cryptographic keys in accordance with a specified cryptographic 1009 | key derivation algorithm (PRF-384) with specified cryptographic key size (128 bits) using a Random Bit 1010 | Generator as specified in RBG-1 and with an administratively-configured cryptoperiod with a granularity no 1011 | greater than an hour that meet the following: 802.11-2012. [WLAN FCS_CKM.1] 1012 |
      • 1013 |
      1014 |
    • 1015 | WLAN-3: The MD shall distribute Group Temporal Key (GTK) in accordance with a specified cryptographic 1016 | key distribution method: AES Key Wrap in an EAPOL-Key frame that meets the following: [RFC 3394 for 1017 | AES Key Wrap, 802.11-2012 for the packet format and timing considerations] and does not expose the 1018 | cryptographic keys. [WLAN FCS_CKM.2] 1019 |
      • 1020 |
      1021 |
    • 1022 | WLAN-4: The MD shall perform encryption and decryption in accordance with the specified cryptographic 1023 | algorithm AES CCMP and cryptographic key size of 128 bits that meet the following: FIPS PUB 197, NIST 1024 | SP 800-38C and IEEE 802.11-2012. [WLAN FCS_COP.1(5)] 1025 |
      • 1026 |
      1027 |
    • 1028 | WLAN-5: The MD shall implement the EAP-TLS protocol as specified in RFC 5216 supporting the following 1029 | ciphersuites: [WLAN FCS_EAP-TLS_EXT.1.1] 1030 | Mandatory Ciphersuites in accordance with RFC 3268: 1031 |
        1032 |
      • TLS_RSA_WITH_AES_128_CBC_SHA
        • 1033 |
      • TLS_RSA_WITH_AES_256_CBC_SHA
        • 1034 |
      1035 | Optional Ciphersuites: 1036 |
        1037 |
      • TLS_DHE_RSA_WITH_AES_128_CBC_SHA
        • 1038 |
      • TLS_DHE_RSA_WITH_AES_256_CBC_SHA
        • 1039 |
      • TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246
        • 1040 |
      • TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246
        • 1041 |
      • TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 as defined in RFC 524
        • 1042 |
      • TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 524
        • 1043 |
      • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289
        • 1044 |
      • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289
        • 1045 |
      • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5430
        • 1046 |
      • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5430
        • 1047 |
      1048 |
      • 1049 |
      1050 |
    • 1051 | WLAN-6:  The MD shall generate random values used in the EAP-TLS exchange using the 1052 | RBG specified in RBG-1. [WLAN FCS_EAP-TLS_EXT.1.2] 1053 |
      • 1054 |
      1055 |
    • 1056 | WLAN-7: The MD shall verify that the server certificate presented for EAL-TLS includes the Server 1057 | Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extended KeyUsage field. [WLAN 1058 | FCS_EAP-TLS_EXT.1.4] 1059 |
      • 1060 |
      1061 |
    • 1062 | WLAN-8: The MD shall allow configuration of the acceptable authentication server certificates (MGMT-5). 1063 | The MD shall verify that the server certificate presented for EAP-TLS either chains to one of the specified 1064 | CAs or contains the specified FQDN of the acceptable authentication server certificate. [WLAN 1065 | FCS_EAP-TLS_EXT.1.5] 1066 |
      • 1067 |
      1068 |
    • 1069 | WLAN-9: The MD shall conform to IEEE Standard 802.1X for a Port Access Entity (PAE) in the “Supplicant” 1070 | role. [WLAN FIA_8021X_EXT.1.1] 1071 |
      • 1072 |
      1073 |
    • 1074 | WLAN-10: The MD shall use X.509v3 certificates as defined by RFC 5280 to support authentication for 1075 | EAP-TLS exchanges. The MD shall use certificate validation as specified in CER-4. The MD shall not 1076 | establish a trusted WLAN communication channel if the authentication server certificate is deemed invalid. 1077 | The key for the client’s X.509v3 certificate shall be stored in the secure key storage (KEY-6). [WLAN 1078 | FIA_X509_EXT.1.1] 1079 |
      • 1080 |
      1081 |
    • 1082 | WLAN-11: The MD shall only attempt connections to wireless networks specified as acceptable networks 1083 | based on [assignment: attribute(s) used to identify the list of acceptable networks] as configured by the 1084 | administrator MGMT-7. [WLAN FTA_WSE_EXT.1.1] 1085 |
      • 1086 |
      1087 |
    • 1088 | WLAN-12: The MD shall use 802.11-2012, 802.1X, and EAP-TLS to provide a trusted communication 1089 | channel between itself and a wireless access point that is logically distinct from other communication 1090 | channels and provides assured identification of its endpoints and protection of the channel data from 1091 | disclosure and detection of modification of the channel data. [WLAN FTP_ITC.1.1] 1092 |
      • 1093 |
      1094 |
    • 1095 | WLAN-13: The MD shall permit the MD to initiate communication via the WLAN trusted channel. [WLAN 1096 | FTP_ITC.1.2] 1097 |
      • 1098 |
      1099 |
    • 1100 | WLAN-14: The MD shall clear according to KEY-12 all plaintext secret and private cryptographic keys and 1101 | CSPs related to WLAN when no longer required. 1102 |
      • 1103 |
    1104 |
    • 1105 |
    1106 |
  • 1107 | Additional Trusted Channels 1108 |
      1109 |
    • 1110 | TC-1: The MD shall be capable of communicating over a trusted channel implementing the IPsec, TLS, 1111 | DTLS, or SSH protocol. 1112 |
      • 1113 |
      1114 |
    • 1115 | TC-2: The MD shall clear according to KEY-12 all plaintext secret and private cryptographic keys and CSPs 1116 | related to the trusted channel when no longer required. 1117 |
      • 1118 |
      1119 |
    • 1120 | IPsec 1121 |
        1122 |
      • 1123 | FCS_IPSEC_EXT.1.1 The MD shall implement the IPsec protocol ESP as defined by RFC 4303 using the 1124 | cryptographic algorithms AES-CBC-128, AES-CBC-256 (both specified by RFC 3602), [selection: no other 1125 | algorithms, AES-GCM-128, AES-GCM-256 as specified in RFC 4106], and using [selection, choose at least 1126 | one of: IKEv1 as defined in RFCs 2407, 2408, 2409, RFC 4109, and [selection: no other RFCs for hash 1127 | functions, RFC 4868 for hash functions]; IKEv2 as defined in RFCs 5996 (with mandatory support for NAT 1128 | traversal as specified in section 2.23), 4307, and [selection: no other RFCs for hash functions, RFC 4868 for 1129 | hash functions]]. 1130 |
        • 1131 |
        1132 |
      • 1133 | FCS_IPSEC_EXT.1.2 The MD shall ensure that either 1134 |
          1135 |
        • 1136 | IKEv2 SA lifetimes can be configured by an [selection: an Administrator, VPN Gateway] based on 1137 | number of packets/number of bytes or length of time, where the time values can be limited to: 24 1138 | hours for IKE SAs and 8 hours for IPsec SAs; or 1139 |
          • 1140 |
        • 1141 | IKEv1 SA lifetimes can be configured by an [selection: an Administrator, VPN Gateway] based on 1142 | number of packets/number of bytes or length of time, where the time values can be limited to: 24 1143 | hours for Phase 1 SAs and 8 hours for Phase 2 SAs. 1144 |
          • 1145 |
        1146 |
        • 1147 |
        1148 |
      • 1149 | FCS_IPSEC_EXT.1.5 The MD shall ensure that all IKE protocols implement DH Groups 14 (2048-bit 1150 | MODP), and [selection: 24 (2048-bit MODP with 256-bit POS), 19 (256-bit Random ECP), 20 (384-bit 1151 | Random ECP), [assignment: other DH groups that are implemented by the MD], no other DH groups]. 1152 |
        • 1153 |
        1154 |
      • 1155 | FCS_IPSEC_EXT.1.6 The MD shall ensure that all IKE protocols implement Peer Authentication using the 1156 | [selection: RSA, ECDSA] algorithm. 1157 |
        • 1158 |
        1159 |
      • 1160 | FCS_IPSEC_EXT.1.7 (optional) The MD shall support the use of pre-shared keys (as referenced in the 1161 | RFCs) for use in authenticating its IPsec connections. 1162 |
        • 1163 |
        1164 |
      • 1165 | FCS_IPSEC_EXT.1.8 (optional) The MD shall support the following: 1166 |
          1167 |
        1. 1168 | Pre-shared keys shall be able to be composed of any combination of upper and lower case 1169 | letters, numbers, and special characters: [selection: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, “)”, 1170 | *assignment: other characters; 1171 |
          2. 1172 |
          1173 |
        2. 1174 | Pre-shared keys of 22 characters and [selection: [assignment: other supported lengths], no other 1175 | lengths]. 1176 |
          3. 1177 |
        1178 |
        • 1179 |
        1180 |
      1181 |
      • 1182 |
    • 1183 | TLS 1184 | FCS_TLS_EXT.1 Explicit: TLS 1185 |
        1186 |
      • 1187 | FCS_TLS_EXT.1.1 The MD shall implement one or more of the following protocols [selection: TLS 1.0 (RFC 1188 | 2246), TLS 1.1 (RFC 4346), TLS 1.2 (RFC 5246)] supporting the following ciphersuites: 1189 | Mandatory Ciphersuites: 1190 |
          1191 |
        • TLS_RSA_WITH_AES_128_CBC_SHA
          • 1192 |
        • TLS_RSA_WITH_AES_256_CBC_SHA
          • 1193 |
        1194 | Optional Ciphersuites: 1195 |
          1196 |
        • TLS_DHE_RSA_WITH_AES_128_CBC_SHA
          • 1197 |
        • TLS_DHE_RSA_WITH_AES_256_CBC_SHA
          • 1198 |
        • TLS_RSA_WITH_AES_128_CBC_SHA256
          • 1199 |
        • TLS_RSA_WITH_AES_256_CBC_SHA256
          • 1200 |
        • TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256
          • 1201 |
        • TLS_DHE_RSA_WITH_AES_256_CBC_ SHA25
          • 1202 |
        • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
          • 1203 |
        • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
          • 1204 |
        • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
          • 1205 |
        • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
          • 1206 |
        1207 |
        • 1208 |
        1209 |
      • 1210 | TLS-2: The MD shall verify that the server certificate presented for EAL-TLS includes the Server 1211 | Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field. 1212 |
        • 1213 |
        1214 |
      • 1215 | TLS-3:  The MD shall generate random values used in the TLS exchange using the 1216 | RBG specified in RBG-1. 1217 |
        • 1218 |
        1219 |
      • 1220 | TLS-4: The MD shall be capable of using X.509v3 certificates as defined by RFC 5280 to support 1221 | authentication for TLS exchanges. The MD shall use certificate validation as specified in CER-4. The key for 1222 | the X.509v3 certificate shall be stored in the secure key storage (KEY-6). 1223 |
        • 1224 |
        1225 |
      1226 |
      • 1227 |
    • 1228 | DTLS 1229 | FCS_DTLS_EXT.1 Extended: Datagram Transport Level Security 1230 |
        1231 |
      • 1232 | FCS_DTLS_EXT.1.1 The MD shall implement the DTLS protocol in accordance with one or more of 1233 | [selection: DTLS 1.0 (RFC 4347), DTLS 1.2 (RFC 6347)]. 1234 |
        • 1235 |
        1236 |
      • 1237 | FCS_DTLS_EXT.1.2 The MD shall implement the requirements in FCS_TLS_EXT.1 for the DTLS 1238 | implementation, except where variations are allowed according to RFC 4347 or RFC 6347. 1239 |
        • 1240 |
        1241 |
      1242 |
      • 1243 |
    • 1244 | SSH 1245 | FCS_SSH_EXT.1 Explicit: SSH 1246 |
        1247 |
      • 1248 | FCS_SSH_EXT.1.1 The MD shall implement the SSH protocol that complies with RFCs 4251, 4252, 4253, 1249 | and 4254. 1250 |
        • 1251 |
        1252 |
      • 1253 | FCS_SSH_EXT.1.2 The MD shall ensure that the SSH protocol implementation supports the following 1254 | authentication methods as described in RFC 4252: public key-based, password-based. 1255 |
        • 1256 |
        1257 |
      • 1258 | FCS_SSH_EXT.1.3 The MD shall ensure that, as described in RFC 4253, packets greater than 1259 | [assignment: number of bytes] bytes in an SSH transport connection are dropped. 1260 |
        • 1261 |
        1262 |
      • 1263 | FCS_SSH_EXT.1.4 The MD shall ensure that the SSH transport implementation uses the following 1264 | encryption algorithms: AES-CBC-128, AES-CBC-256, [selection: AEAD_AES_128_GCM, 1265 | AEAD_AES_256_GCM, no other algorithms]. 1266 |
        • 1267 |
        1268 |
      • 1269 | FCS_SSH_EXT.1.5 The MD shall ensure that the SSH transport implementation uses SSH_RSA and 1270 | [selection: PGP-SIGN-RSA, PGP-SIGN-DSS, no other public key algorithms,] as its public key 1271 | algorithm(s). 1272 |
        • 1273 |
        1274 |
      • 1275 | FCS_SSH_EXT.1.6 The MD shall ensure that data integrity algorithms used in SSH transport connection is 1276 | [selection: hmac-sha1, hmac-sha1-96, hmac-md5, hmac-md5-96]. 1277 |
        • 1278 |
        1279 |
      • 1280 | FCS_SSH_EXT.1.7 The MD shall ensure that diffie-hellman-group14-sha1 is the only allowed key exchange 1281 | method used for the SSH protocol. 1282 |
        • 1283 |
        1284 |
      1285 |
      • 1286 |
    • 1287 | HTTPS 1288 | FCS_HTTPS_EXT.1 Explicit: HTTPS 1289 |
        1290 |
      • 1291 | FCS_HTTPS_EXT.1.1 The MD shall implement the HTTPS protocol that complies with RFC 2818. 1292 |
        • 1293 |
        1294 |
      • 1295 | FCS_HTTPS_EXT.1.2 The MD shall implement HTTPS using TLS as specified in section 4.3.2. 1296 |
        • 1297 |
        1298 |
      1299 |
      • 1300 |
    • 1301 | Baseband Trusted Channel 1302 |
        1303 |
      • 1304 | CNAU-1: (High-security) (Objective) The MD shall authenticate all base stations of the cellular network to 1305 | which it connects unless the cellular protocol does not support authentication. 1306 |
        • 1307 |
        1308 |
      • 1309 | CNAU-2: (High-security) (Objective) The MD shall visually indicate to the user the cellular protocol it is using 1310 | and the network to which it currently is connected. 1311 |
        • 1312 |
        1313 |
      • 1314 | CNAU-3: (High-security) (Objective) The MD shall be configurable to connect to cellular network base 1315 | stations using only the cellular protocols configured by the user or MDM agent. 1316 |
        • 1317 |
        1318 |
      1319 |
      • 1320 |
    1321 |
    • 1322 |
1323 |
    1324 |
  • 1325 | Identification & Authentication 1326 |
    1327 |
      1328 |
    • 1329 | AUTH-1: The MD shall detect when an administrator-configured positive integer (MGMT-5 and MGMT-6) 1330 | within [assignment: range of acceptable values] unsuccessful authentication attempts by a user on the MD 1331 | occur related to unsuccessful authentication attempts since the last successful authentication by that user. 1332 | [MDPP FIA_AFL.1.1 and MDM PP 2.1.1 Screen Lock] 1333 |
      • 1334 |
      1335 |
    • 1336 | AUTH-2: When the defined number of unsuccessful authentication attempts has been [selection: met, 1337 | surpassed], the MD shall perform a remediation action set by the administrator MGMT-10. [MDPP 1338 | FIA_AFL.1.2 and MDM PP 2.1.2 Authentication Failures] 1339 |
      • 1340 |
      1341 |
    • 1342 | AUTH-3: The MD shall enforce a delay between incorrect authentication attempts. The minimum delay shall 1343 | be such that no more than 10 attempts can be attempted per 500 milliseconds. 1344 |
      • 1345 |
      1346 |
    • 1347 | AUTH-4: The MD shall provide a mechanism to verify that the Password Authorization Factors comply with 1348 | the password policy set by the administrator in MGMT-6. [MDPP FIA_SOS.1] 1349 |
      • 1350 |
      1351 |
    • 1352 | AUTH-5: The MD shall transition to the locked state after a time interval of inactivity set by the user within a 1353 | range specified by the administrator according to MGMT-5 or MGMT-6 by: [MDPP FTA_SSL.1 and MDM 1354 | PP 2.1.1 Screen Lock] 1355 |
        1356 |
      1. 1357 | clearing or oveerwriting display devices, making the current contents unreadable; 1358 |
        2. 1359 |
      2. 1360 | disabling any activity of the user's data access/display devices other than unlocking the session 1361 | or those allowed in AUTH-8 1362 |
        3. 1363 |
      3. 1364 | clearing all sensitive data/keys and all plaintext keying material (authentication data, 1365 | secret/private symmetric keys, etc.) for sensitive data/keys in volatile memory according to KEY-12 1366 | (DAR-5) 1367 |
        4. 1368 |
      1369 |
      • 1370 |
      1371 |
    • 1372 | AUTH-6: The MD shall allow user-initiated locking of the user's own interactive session, by: [MDDP 1373 | FTA_SSL.2] 1374 |
        1375 |
      1. 1376 | clearing or overwriting display devices, making the current contents unreadable; 1377 |
        2. 1378 |
      2. 1379 | disabling any activity of the user's data access/display devices other than unlocking the session 1380 | or those allowed in AUTH-8 1381 |
        3. 1382 |
      3. 1383 | clearing all sensitive data/keys and all plaintext keying material (authentication data, 1384 | secret/private symmetric keys, etc.) for sensitive data/keys in volatile memory according to KEY-12 1385 | (DAR-5) 1386 |
        4. 1387 |
        1388 |
      1389 |
      • 1390 |
    • 1391 | AUTH-7: The MD shall require the user to enter the correct Password Authorization Factor when the user 1392 | changes their Password Authorization Factor, following MD-initiated locking (AUTH-5) in order to transition 1393 | to the unlocked state, following user-initiated locking (AUTH-6) in order to transition to the unlocked state, 1394 | [selection: [assignment: other conditions], no other conditions]. 1395 |
      • 1396 |
      1397 |
    • 1398 | AUTH-8: The MD shall allow the user to limit information that may be automatically displayed to 1399 | unauthenticated users in the locked state. [MDPP FIA_UAU.1.1] 1400 |
      • 1401 |
      1402 |
    • 1403 | AUTH-9: The MD shall support the following for the Password Authorization Factor: 1404 |
        1405 |
      1. 1406 | Passwords shall be able to be composed of any combination of upper and lower case letters, 1407 | numbers, and special characters: [selection: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, “)”, *assignment: 1408 | other characters; 1409 |
        2. 1410 |
      2. 1411 | Passwords of up to 14 characters. 1412 |
        3. 1413 |
      1414 |
      • 1415 |
      1416 |
    • 1417 | AUTH-10: The Password Authorization Factor shall be used to derive a KEK as specified in KEY-4. 1418 |
      • 1419 |
      1420 |
    • 1421 | AUTH-11:  If the product supports additional forms of authentication, such as a raw key stored on an 1422 | external token or biometrics, and if the product uses these factors to derive KEKs, these additional 1423 | authentication factors shall be conditioned to have size equal to the size of the KEK derived by the 1424 | Password Authentication Factor and shall be used in conjunction with the KEK derived from the Password 1425 | Authentication Factor. 1426 |
      • 1427 |
      1428 |
    1429 |
    • 1430 |
1431 |
    1432 |
  • 1433 | Integrity 1434 |
    1435 |
      1436 |
    • 1437 | INT-1: The MD shall run a suite of tests, at least during initial start-up, to demonstrate the correct operation 1438 | of the MD. At a minimum, the MD is expected to perform tests to confirm correct operations of 1439 | crypto-related hardware functionality. [MDPP FPT_TST.1.1] 1440 |
      • 1441 |
      1442 |
    • 1443 | INT-2: The MD shall notify the user and, if configured, the administrator when the following types of failures 1444 | occur: 1445 |
        1446 |
      • failures resulting from self-tests performed per during self-testing under INT-1
        • 1447 |
      • MD software integrity verification failures under INT-4
        • 1448 |
      • [assignment: other failures].
        • 1449 |
      1450 |
      • 1451 |
      1452 |
    • 1453 | INT-3: The MD shall take the following actions for failures specified in INT-2: 1454 |
        1455 |
      • log failures in the audit record
        • 1456 |
      • preserve a secure state and transition to non-operational mode,
        • 1457 |
      • [assignment: other actions taken].
        • 1458 |
      1459 |
      • 1460 |
      1461 |
    • 1462 | INT-4: The MD shall verify the integrity of the bootloader software either by a digital signature using an 1463 | hardware-protected asymmetric key or by a hardware-protected hash before loading additional software. The 1464 | software integrity of both the firmware/software on the AP and the firmware/software on the BP shall be 1465 | verified. The asymmetric key or hash shall be either protected by a REK or stored in a hardware module. 1466 | The key or hash shall only be updated by verified and authenticated software. 1467 |
      • 1468 |
      1469 |
    • 1470 | INT-5: (Objective) Each software piece (starting with the bootloader) thereafter shall verify the integrity of any 1471 | software it loads using a digital signature or hash. The software integrity of both the firmware/software on the 1472 | AP and the firmware/software on the BP shall be verified. 1473 |
      • 1474 |
      1475 |
    • 1476 | INT-6: (BYOD) The MD shall provide users the ability to initiate updates to MD system software. The MD 1477 | may also provide the administrator the ability to initiate updates. 1478 |
      • 1479 |
      1480 |
    • 1481 | INT-7: The MD shall verify software updates to the MD using a digital signature mechanism implemented 1482 | according to ALG-5 prior to installing those updates. The update mechanism itself shall have been verified 1483 | by INT-4 and INT-5. 1484 |
      • 1485 |
      1486 |
    • 1487 | INT-8: The MD shall by default only accept operating system and firmware software updates 1488 | cryptographically signed by the vendor or a party authorized by the vendor. The signing key shall be 1489 | validated to a hardware-protected public key (either stored in a hardware module or in the Trust Anchor 1490 | Database) or shall match a hardware-protected public key. If the signing public key is part of a certificate, 1491 | this certificate shall be verified to have the Code Signing purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3) in the 1492 | extendedKeyUsage field and shall be validated according to CER-4. The MD shall not install software 1493 | updates to the MD if the code signing certificate is deemed invalid. 1494 |
      • 1495 |
      1496 |
    • 1497 | INT-9: (BYOD) The MD shall provide users the ability to initiate updates to mobile applications. The MD 1498 | should also provide the administrator the ability to initiate application updates. 1499 |
      • 1500 |
      1501 |
    • 1502 | INT-10: The MD shall verify software updates to mobile applications using a digital signature mechanism 1503 | prior to installing those updates. The MD shall validate the code signing certificate used to sign the 1504 | application in accordance with CER-4.  This certificate shall be verified to have the Code Signing purpose 1505 | (id-kp 3 with OID 1.3.6.1.5.5.7.3.3) in the extendedKeyUsage field. The MD shall not run or install 1506 | applications or updates to applications if the code signing certificate is deemed invalid. 1507 |
      • 1508 |
      1509 |
    • 1510 | INT-11: (Objective) The MD shall require applications to be signed by either a vendor-assigned public key(s) 1511 | or by a user/administrator configured public key(s). 1512 |
      • 1513 |
      1514 |
    • 1515 | INT-12: The MD shall be able to generate an audit record of the following auditable events: 1516 |
        1517 |
      1. Start-up and shutdown of the audit functions;
        2. 1518 |
      2. All auditable events for the any level of audit; and
        3. 1519 |
      3. All administrative actions;
        4. 1520 |
      4. Authentication failures (AUTH-1, AUTH-2, AUTH-7);
        5. 1521 |
      5. Failures of security functions (INT-1);
        6. 1522 |
      6. Integrity verification failures (INT-4);
        7. 1523 |
      7. Software upgrades (INT-6, INT-7, INT-8)
        8. 1524 |
      1525 |
      • 1526 |
      1527 |
    • 1528 | INT-13: The MD shall record within each audit record at least the following information: 1529 |
        1530 |
      1. 1531 | Date and time of the event, type of event, subject identity, and the outcome (success or failure) of 1532 | the event; and 1533 |
        2. 1534 |
      2. 1535 | For each audit event type, based on the auditable event definitions of the  functional components 1536 | included in the PP/ST, auditable events to be derived from the requirements in this profile. 1537 |
        3. 1538 |
      1539 |
      • 1540 |
      1541 |
    • 1542 | INT-14: (Objective) The audit record shall be cryptographically protected from modification using a digital 1543 | signature mechanism implemented according to ALG-5. The key used to perform this signature shall be 1544 | protected by the secure key storage (KEY-6).  The key should be unique per mobile device and should be 1545 | capable of being signed by an external Certificate Authority. 1546 |
      • 1547 |
      1548 |
    • 1549 | INT-15: The MD shall be able to provide reliable time stamps. 1550 |
      • 1551 |
      1552 |
    • 1553 | INT-16: The MD shall overwrite the oldest stored audit records if the audit trail is full. 1554 |
      • 1555 |
      1556 |
    1557 |
    • 1558 |
1559 |
    1560 |
  • 1561 | Documentation 1562 |
      1563 |
    • 1564 | Guidance Documentation 1565 | The guidance documents will be provided with the ST. Guidance must include a description of how the user 1566 | verifies that the Operational Environment can fulfill its role for the security functionality. The documentation 1567 | should be in an informal style and readable by the user. 1568 |
      1569 | Guidance must be provided for every operational environment that the product supports as claimed in the 1570 | ST. This guidance includes 1571 |
        1572 |
      • 1573 |  Instructions to successfully install the MD in that environment; and 1574 |
        • 1575 |
      • 1576 | Instructions to manage the security of the MD as a product and as a component of the larger 1577 | operational environment. 1578 |
        • 1579 |
      1580 | Guidance pertaining to particular security functionality is also provided; requirements on such guidance are 1581 | contained in the assurance activities specified with each requirement. 1582 |
      1583 | Operational User Guidance 1584 | The developer shall provide operational user guidance.  It shall be expressed in the eXtensible Configuration 1585 | Checklist Description Format (XCCDF) to support security automation. 1586 |
      1587 | The operational user guidance shall describe the user- accessible functions and privileges that should be 1588 | controlled in a secure processing environment, including appropriate warnings. 1589 |
      1590 | The user guidance should focus on the management of the MD by the administrator in addition to local 1591 | management by the local mobile user. 1592 |
      1593 | The operational user guidance shall describe how to use the available interfaces provided by the MD in a 1594 | secure manner. 1595 |
      1596 | [Appendix for US only] The operational user guidance shall express each configuration guidance item that 1597 | could be used in a compliance checking regime as an XCCDF Rule element, and provide references to the 1598 | NIST 800-53 controls which the item satisfies. 1599 |
      1600 | The operational user guidance shall describe the available functions and interfaces, in particular all security 1601 | parameters under the control of the user, indicating secure values as appropriate. 1602 |
      1603 | The operational user guidance shall clearly present each type of security-relevant event that require user 1604 | approval resulting from applications under the control of the MD changing security characteristics of the MD. 1605 |
      1606 | The operational user guidance shall identify all possible modes of operation of the MD, their consequences 1607 | and implications for maintaining secure operation. 1608 |
      1609 | The operational user guidance shall describe the security measures to be followed in order to fulfill the 1610 | security objectives for the operational environment as described in the ST. 1611 |
      1612 | The operational user guidance shall be clear and reasonable. 1613 |
      1614 | Setup Guide 1615 | The developer shall provide the MD including its preparative/setup procedures. 1616 |
      1617 | As with the operational guidance, the developer should look to the assurance activities to determine the 1618 | required content with respect to preparative/setup procedures. 1619 |
      1620 | The preparative/installation procedures shall describe all the steps necessary for secure setup of the MD 1621 | and for the secure preparation of the operational environment in accordance with the security objectives for 1622 | the operational environment as described in the ST. 1623 |
      1624 | Life Cycle Support 1625 | Life-cycle support is limited to end- user-visible aspects of the life-cycle, rather than an examination of the 1626 | MD vendor’s development and configuration management process. This is not meant to diminish the critical 1627 | role that a developer’s practices play in contributing to the overall trustworthiness of a product; rather, it’s a 1628 | reflection on the information to be made available for evaluation. 1629 |
      1630 | Labeling of the MD 1631 | This component is targeted at identifying the MD such that it can be distinguished from other products or 1632 | from other versions of the software and hardware from the same vendor and can be easily specified when 1633 | being procured by an end user. 1634 |
      1635 | The developer shall provide the MD and a reference for the MD. 1636 |
      1637 | The MD shall be labeled with its unique reference. 1638 |
      1639 | Identification of Security Measures 1640 | The developer shall produce and provide development security documentation 1641 |
      1642 | The development security documentation shall describe all the physical, procedural, personnel, and other 1643 | security measures that are necessary to protect the confidentiality and integrity of the MD design and 1644 | implementation in its development and manufacture environment. 1645 |
      1646 | Application Programming Interface (API) 1647 | The developer shall provide documentation of the API available to application developers for the MD. The 1648 | developer may reference a website accessible to application developers and the evaluator. 1649 |
      1650 | The API documentation shall include those interfaces required in this profile. 1651 |
      1652 | The API documentation shall clearly indicate to which products and versions each available function applies. 7.2.4 Timely Security Updates The vendor, in conjunction with any other parties necessary to facilitate update of end-user devices, shall provide documentation which describes the process for creating and deploying security updates for the mobile device software/firmware.  The software to be described includes the operating systems of the application processor and the baseband processor, as well as any firmware. 1653 |
      1654 | Timely Security Updates 1655 | The vendor, in conjunction with any other parties necessary to facilitate update of end-user devices, shall 1656 | provide documentation which describes the process for creating and deploying security updates for the 1657 | mobile device software/firmware.  The software to be described includes the operating systems of the 1658 | application processor and the baseband processor, as well as any firmware. 1659 |
      1660 | The vendor shall identify the maximum time window that may remain open for this process.  This time 1661 | window is defined as the length of time between public disclosure of a vulnerability and the widespread 1662 | availability of security updates to mobile devices. 1663 |
      • 1664 |
    1665 |
    • 1666 |
1667 |
1668 | 1669 |
1670 |
    1671 |
  1. The Mobile Device will be provisioned for a specific mobile user in the enterprise 1672 | environment by the administrator prior to use by the mobile user.
    2. 1673 |
    1674 |
  2. The administrator will configure the Mobile Device security functions correctly to 1675 | create the intended security policy.
    3. 1676 |
    1677 |
  3. The Mobile User will immediately notify the administrator if the Mobile Device is 1678 | lost or stolen.
    4. 1679 |
    1680 |
  4. The Mobile User is not malicious, and exercises precautions to reduce the risk of 1681 | loss or theft of the Mobile Device.
    5. 1682 |
    1683 |
1684 |
1685 | 1686 |
1687 | Optional Extensions are Identified within the Security Requirements. 1688 |
1689 | 1690 |
1691 | The Mobile Device is also vulnerable due to the access of service providers who, in their role, 1692 | can easily eavesdrop on mobile communications or inject malicious or flawed code into the 1693 | mobile device. At this time, this assurance standard provides few mitigations to the access 1694 | available to service providers, or adversaries posing as service providers; however, several 1695 | future requirements addressing this threat are identified, with the expectation that industry 1696 | will feedback as to the feasibility of such requirements. 1697 |
1698 | 1699 | --------------------------------------------------------------------------------