Table of Contents

• 1. Notation
  • 1.1 Version
• 2. Introduction
• 3. Requirements for Restricted Operating Environment to be Allowed
• 4. Allowed Restricted Operating Environments
• A. References
  • A.1 Normative references
  • A.2 Informative references

1. Notation

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].

2. Introduction

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 Level 2, we are mostly concerned about the protection against client side scalable attacks (e.g. malware). At FIDO Security Levels 3 and 3+ we also require protection against physical attacks.

The following aspects of the AROE are relevant for the FIDO Security Certification:

3. Requirements for Restricted Operating Environment to be Allowed

• The AROE security configuration MUST be controlled by the vendor of the commercial device or its delegates or its suppliers.
• The AROE MUST protect itself from modifications degrading its security. This includes modifications when powered-off. It hence requires a secure boot process of the AROE.
• The AROE MUST provide full isolation from any rich OS or external devices or operating environments it connects with except for conveyance of protocol messages intended for communication with the rich OS and external devices or operating environments. As a consequence, it MUST NOT be possible for SW or HW on the same device but outside the AROE to modify any state, registers, memory or storage inside the operating environment.
• The AROE SHOULD be security-oriented with the bulk of the functionality it hosts and provides being focused primarily on security (e.g., not large graphics engines, signal processors, general purpose app hosting, network stacks and such).
• If multiple apps or processes are allowed within the AROE and they are not within the authenticator boundary, there must be strong and complete isolation between the authenticator and those apps.
• The apps hosted by the AROE SHOULD be primarily security-oriented (e.g., does not host thousands of downloadable games, complex productivity apps like word processors, or large scale network apps like web browsers).
• A security oriented SW engineering practice SHOULD be followed
  • Code is reviewed by security experts
  • A security patch system is in place
  • Security incidents are tracked
  • Security coding practice is followed
  • System documentation is produced

4. Allowed Restricted Operating Environments

The following is the official lists of Approved Restricted Operating Environments (AROEs) FIDO Certification.

All entries in this list implement the requirements listed in Section 3.

Additions to this list must meet the requirements listed in Section 3 and must be voted on to the list by the FIDO SPWG. The vote approval is simply a vote on a new version of this document.

The above list is for specific technologies that can be given blanket AROE status.They can be approved before use in any particular authenticator. Once approved the approval is for any authenticator they are used in.

Sometimes authenticators are built using technologies that can't be given blanket approval because the security of their application is too variable. Another case is where the technology employed for the authenticator is entirely bespoke, and no technology can be named. Nonetheless, many authenticators do possess the characteristics of an AROE and must be allowed by certification.

In these cases, the authenticator vendor can provide a detailed description of the software and the hardware used to build the authenticator that answers all of the criteria listed in section 4 below. The FIDO security secretariat will take extra time on the certification to evaluate this detailed description and make a determination whether it is considered and AROE or not.