Let's sort it out, FIDO vs. PKI
FIDO is an authentication system based on asymmetric cryptography without the typical PKI directory services on end user level.
To establish trust in FIDO tokens for Relying Parties (RP) there is a need for an "ecosystem" (environment).
Taking hints from mechanisms successfully established in classical PKI systems, pillars of this "ecosystem" could be considered.
The four pillars of trust in FIDO environments consist of:
- Trusted protocols
- Trusted key storage
- Trusted "ecosystem"
- Trusted personalization
The trusted protocols are open and published openly by FIDO Alliance. As well, the protocols are standardized and are reviewed using thorough review processes.
Trusted key storage is handled through specific requirements for key storage depending on the criticality of use cases with different trust levels such as soft token and storage in hardware.
A trusted ecosystem (environment) for FIDO to ensure reliability. The availibility of trusted meta data must be taken care of in FIDO token by relying parties (RP). Also, securing the integrity and authenticity of this meta data. This is already a classical PKI topic. For transparency reasons backend mechanisms must be modelled after already widely accepted scenarios (SSL / ETSI/ CABF). In PKI, the SSL is often used. Certification must be established to prove the compliance. Again, these widely accepted scenarios already exist in the PKI world (ETSI/CABF/ISO 27001)
Trusted personalization and integrity of key material into token must be guaranteed and kept confidential. Personalization procedures should be documented for transparency reasons and certainly also reviewed independent third parties. Can be taken after common PKI standards.
Authentification and identification comparisons
When classical PKI based mechanisms typically mix elements of authentication and identification FIDO mechanisms allow a clear differentation between authentication and identification. For FIDO, positive aspects both for the relying party (RP) as well as the user since data protection will be provided using only the minimum amount of data required.
For both techniques, the solution is spelled THE TOKEN. A token is a certified chip hardware and chip operating system (CC EAL4+). The token is a FIDO ready certified application and for PKI the application is certified according to european standards for secure signature creation devices.
Combining PKI and FIDO creates two interesting migration scenarios:
- Move an existing PKI ecosystem to a PKI+FIDO ecosystem
- Move an existing FIDO ecosystem to a FIDO+PKI ecosystem
FIDO and PKI integration in the enterprise
This leaves us with thinking about three questions:
- How can FIDO protocols deliver new or enhanced business benefits to the enterprise?
- Which enterprise applications, and application layer protocols, can use PKI?
- How can an expanded public key cryptographic system incorporating PKI and FIDO benefit an enterprise?
This blog will repeatedly come back to these questions over time.
Use of PKI in the enterprise
The use of digital certificates is supported by many applications. Some common use cases within an enterprise are:
- Server authentication
- Client authentication
- Desktop logon
- Pre-boot authentication to devices
- Remote desktop access
- Email encryption and authentication
- Internet Protocol Security (IPSec) Virtual Private Networks (VPN)
- Wireless access
- Document signing
- Transaction authorization
- Code signing
- Disk encryption
- Single Sign On (SSO)
- Federation and trust establishment
The above bullet list leaves no doubt realising the usability of PKIs. However, FIDO protocols have a few advantages over PKI in some use cases. And those use cases will be highlighted in table 1 below. In general, FIDO is simpler for end-users to use. It is also less complicated for application developers to integrate into web and mobile applications. Speaking cost, the FIDO infrastructures can also be less expensive to operate and manage given that they do not require as many prolongations generally associated with PKIs.
The table 1 below lists the use cases that can be addressed using PKI and those that can be supported using FIDO.
|Web client authentication||Yes||Yes|
|Thick client authentication||Yes||Yes|
|Email encryption and signing – S/MIME||Yes||No|
|EAP-TLS for wireless access||Yes||No|
|Single Sign On||Yes||Yes|
|Trust establishment (federation)||Yes||No|
This leaves us with scrutinizing when FIDO is considered as good as PKI.....
- Web client authentication. FIDO protocol runs over TLS with server only authentication mode meanwhile PKI is using TLS client side certificate based authentication.
- Thick client application leverages native APIs to authenticate users to a remote server. This may be a mobile or desktop application. In PKI, it is possible to enable certificate based authentication without user interactions. In FIDO, user interaction is always required to access and use the FIDO private key. Please also refer to Certificate based authentication further below.
- Document signing. However, the verification of a document signature is easiest for the relying party (RP) where the signer's FIDO public key is registered. Verifying that signature outside the domain of the RP becomes a complex issue which FIDO protocols are not designed to solve, and which are better addressed with PKI.
- Code signing can be achieved with FIDO as long as the verifier (typically the relying parties, the RP:s) has access to the matching FIDO public key.
- Single Sign On. In combination with federation protocols such as Security Assertion Markup Language (SAML) and OpenID Connect (OIDC) the FIDO protocols can enable a single sign on experience. The FIDO relying party (RP) acts as an Identity Provider (IdP) and issues authentication.
- Pre-boot authentication. User authentication before the computer boots up could be implemented using PKI or FIDO in similar fashions.
- Transaction authorization. This use case is supported by two FIDO protocols. Transaction authorization is intended for small transactions that can fit within a small secure display of a mobile device. It is possible to display a hash of a document which can be verified outside the application. Then, you can show the hash in the display of a mobile device.
...... as well as advantage FIDO....:
- The need to chain an internal PKI with an external Trusted Third Party (TTP) meaning a Certificate Authority (CA). This is to have digital certificates from the internal PKI to be trusted on the Internet. Not needed for FIDO.
..... and subsequently, advantage PKI:
- Unlike PKI credentials, FIDO credentials are bound to a specific relying party (RP) and cannot be used across multiple security domains. With a private Certificate Authority (CA) in a closed environment, a PKI certificate does not need to be trusted on the internet.
- Certificate based authentication. Please see Thick client application above.
- Email encryption and signing. Historically, email security has been used in the context of the S/MIME protocol which requires the use of an X.509 digital certificate. As FIDO protocols do not use digital certificates to identify cryptographic keys, this use case cannot be supported by FIDO protocols.
- VPN-IPSec. Use of digital certificates as for the use case Email encryption and signing. Virtual private networking has been used only with the IPSec protocol, which requires the use of an X.509 digital certificate. As FIDO protocols do not use digital certificates to identify cryptographic keys, this use case cannot be supported by FIDO protocols.
- Transport Layer Security (TLS). TLS and its' predecessor Secure Sockets Layer (SSL) are public key based cryptographic protocols designed to provide privacy, authentication and data integrity between two or more communicating applications. Using TLS, the connections between a client (for example a web browser) and a server, the server authenticates to the client using an X.509 server certificate and the client optionally authenticates to the server using an X.509 client certificate. This means client and server certificates are issued by trusted Certificate Authorities (CAs). Applications using TLS may also use other methods of client or user authentication to the server, for example HTTP Basic or HTTP Digest authentication. As already mentioned, FIDO protocols do not support certificate based authentication like CAs and are not designed for client or server authentication in TLS. However, FIDO may be used for client authentication at the application layer instead of or in addition to X.509 client certificate authentication.
- EAP (Extensible Authentication Protocol)-TLS for Wireless Access. Again, FIDO protocols do not use digital certificates.
- Document signing. Likewise as transaction authorization (see above) can digitally sign the hash of a document using FIDO. However, the verification of that signature is easiest for a relying party (RP) where the signer's FIDO public key is registered. Hence, verifying that signature outside the domain of the RP the FIDO protocols are not designed to solve, but feasible with PKI. However, it is possible to build an application that would allow RPs to have users with registered FIDO authenticators to sign documents.
- Code signing. Like document signing, if possible to verify signed code within the domain, it is feasible using FIDO protocols. Verifying signed code outside the domain are, as for now, better addressed using PKI.
- Disk encryption. This use case cannot be supported by FIDO protocols. Disk encryption can be implemented on smart cards using PKI.
- Trust establishment. In federation protocols such as SAML and OIDC a trust relationship is established between the identity provider (IdP) and the RP by exchange of certificates. FIDO protocols are not designed to establish trust between the IdP and the RP exchanging certificates.
Finalizing the advantages of PKI there is a reflection concerning a security aspect:
- Typically, digital certificates have a limited lifetime. The duration is intended to balance several risks against the inefficiency of reissuing certificates. FIDO protocols do not specify duration for registered keys with an RP. Hence, from a protocol point of view the FIDO credentials never expire and as a consequence no revocation action exists.
Benefits of the combined PKI and FIDO approach
FIDO offers strong public key based authentication that is equivalent to certificate based authentication but without the overhead of maintaining complex and expensive public key infrastructure. A variety of applications and use cases can be addressed:
- web and SaaS applications access
- mobile applications
- offline and online desktop logon
- access to shared workstations
- strong authentication for remote and non-employees workforce (contractors, guests etc...).
Organizations that invested heavily in PKI can benefit from combining their authentication solution with FIDO for a moderate investment.
Organizations who have not invested in PKI and are looking for strong authentication solutions can consider investing in FIDO if FIDO meets their security requirements and business objectives.
A vision around enabling better IoT (Internet of Things) security using PKI:
PKI managers and device managers will be deployable to on premise, in the cloud and in hosted environments. The PKI have become a protocol and it is safe for now, the use is proven. If you get the footprint right and if the key length is not too long, PKI can be perfect for IOT as it is important to design security up front. IoT use cases are different from servers as you want them to be on premise and air gapped.
The future of IoT looks promising as governments around the world are taking this seriously. As well, industries are collaborating to create standards. However, we will see more attacks and this will lead to that the level of security in PKI is very suitable.