|
+3.2.13 Exportability |
3.2.13 ExportabilityExportability is the ability of an authenticator to replicate, share, or store its authentication keys outside of the protected boundary of the authenticator (e.g., copying it to another authenticator, backing up a key to a separate storage location). Generally, authentication keys are considered exportable unless the authenticator generates, stores, and uses the keys in a protected hardware environment that prevents software from accessing the keys, such as in a security coprocessor (e.g., TPM) or a dedicated device (e.g., a security key). This is intended to prevent software on the endpoint from copying or leaking the authentication secret. Non-exportable authentication keys are considered more secure, and accordingly, non-exportable cryptographic keys are required at AAL3. The authentication keys on syncable authenticators are inherently exportable (see Appendix B). To be considered non-exportable, an authenticator SHALL either be a separate piece of hardware or an embedded processor or execution environment (e.g., secure element, TEE, TPM). These hardware authenticators and embedded processors are separate from a host processor, such as the CPU on a laptop or mobile device. A non-exportable authenticator SHALL be designed to prohibit the export of the authentication secret to the host processor and SHALL NOT be capable of being reprogrammed by the host processor to allow the secret to be extracted. The authenticator is subject to applicable [FIPS140] requirements. Organizations SHOULD employ authenticators that have undergone independent security testing, such as authenticators validated to [FIPS140] security level 2 overall with level 3 physical security6 or evaluated against relevant Common Criteria Protection Profiles. Invalidation can take several forms, including the revocation of a public-key infrastructure (PKI)-based authenticator and removal from the subscriber account. ↩ Federal enterprise systems include those considered in scope for PIV guidance, such as government contractors, government employees, and mission partners. It does not include government-to-consumer or public-facing use cases. ↩ The limit of 240 meters was chosen based on the maximum expected range of a Bluetooth connection. ↩ As used in this section, the term pairing code does not imply that a persistent pairing process (e.g., Bluetooth) is necessarily used. ↩ Detailed information on generating random values may be found in [SP800-90A], [SP800-90B], and [SP800-90C]. ↩ In this case, the FIPS 140 evaluation would satisfy the minimum [FIPS140] security level 1 validation requirement for authenticators procured by federal agencies. ↩ 1. Visão geral
1.1 Referências1.2 Requisitos identificados1.3 Regulamentos relacionados2. Requisitos identificados
3. Regulamentos relacionados
|