This document was published by the FIDO Alliance as a Final Document. If you wish to make comments regarding this document, please Contact Us. All comments are welcome.
Implementation of certain elements of this Document may require licenses under third party intellectual property rights, including without limitation, patent rights. The FIDO Alliance, Inc. and its Members and any other contributors to this Document are not, and shall not be held, responsible in any manner for identifying or failing to identify any or all such third party intellectual property rights.
THIS FIDO ALLIANCE DOCUMENT IS PROVIDED “AS IS” AND WITHOUT ANY WARRANTY OF ANY KIND, INCLUDING, WITHOUT LIMITATION, ANY EXPRESS OR IMPLIED WARRANTY OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [[!RFC2119]].
The FIDO Authenticator is typically implemented based on some hardware and firmware. For example, this might be a secure element as hardware with the basic secure element firmware in which the Authenticator Trusted Application runs. As another example it might also be a multifunctional device containing some CPUs which are securely shared between the firmware of the restricted operating environment and the high-level operating system.
It is important that by definition, all parts which are relevant for the FIDO Authenticator (e.g. underlying hardware, ...) are part of the Authenticator itself. So the FIDO Authenticator is more than just the Authenticator Application.
We use the term Authenticator Application to refer to the entity that combines the underlying hardware and firmware in a way that results in a FIDO Authenticator.
We distinguish these components as the Restricted Operating Environment can be implemented in a way that it supports more than just the Authenticator Application. Additionally the security of the Restricted Operating Environment (ROE) (without the Authenticator Application) can be demonstrated or certified using existing programs (e.g. Common Criteria).
The FIDO Security Certification covers the various components with different depths. At FIDO Security Level 1, we are concenred about the protection against scalable attacks on the server side an on the communication channel. At FIDO Security Levels 2 and 3, we are mostly concerned about the protection against client side scalable attacks (e.g. malware). At FIDO Security Levels 4 and 5 we also require protection against physical attacks.
The following aspects of the AROE are relevant for the FIDO Security Certification:
The following table outlines the Allowed Restricted Operating Environments (AROEs) for FIDO Security Certification.
|TEEs based on ARM TrustZone HW||All operating systems (ROE firmware) running on ARM TrustZone HW are accepted for Level 1 FIDO Security Certification. See ARM TrustZone Security Whitepaper and ARM Architecture Reference Manual.|
|TEE Based on Intel VT HW||All operating systems (ROE firmware) running on Intel VT HW are accepted for Level 1 FIDO Security Certification. See Intel Vanderpool Technology for IA-32 Processors (VT-x) Preliminary Specification.|
|TEE Based on Intel SGX HW||All operating systems (ROE firmware) running on Intel SGX HW are accepted for Level 1 FIDO Security Certification. See Innovative Instructions and Software Model for Isolated Execution and Innovative Technology for CPU based Attestation and Sealing.|
|TEE Based on Intel ME/TXE HW||All operating systems (ROE firmware) running on Intel ME/TXE HW are accepted for Level 1 FIDO Security Certification|
|TEE with GlobalPlatform TEE Protection Profile Certification||GlobalPlatform TEE Protection Profile Certification is NOT required for Level 1 FIDO Security Certification, but it is sufficient for any TEE to be qualified as an Allowed Restricted Operating Environment. See TEE Protection Profile v1.2.1|
|Windows 10 Virtualization-based Security.||Security apps and services that are running at Virtual Trust Level 1. See Moore Defeating - Pass the Hash Separation of Powers.|
|Secure World of AMD PSP (Platform Security coProcessor).||All operating environments running on the secure world side of the TrustZone in the AMD PSP. See AMD Secure Technology.|
|Trusted Platform Modules (TPMs) Complying to Trusted Computing Group specifications.||For example, TPM Main Specification Version 1.2 [[TPM]] or TPM Library Specification Version 2.0 [[TPMv2]].|
|Secure Element (SE)||Secure Operating Systems (ROE firmware) running on a secure tamper-resistant microcontroller.|