Notes - MCS
Identification, Authentication and Authorization
Notes - MCS
Identification, Authentication and Authorization
  • Identification, Authentication and Authorization
  • Access Control Models
    • Access types
    • Least privilege principle
    • Access control models
      • Access control kinds
    • Access control kinds
    • Separation of duties
    • Segregation of duties
    • Information flow models
    • Multilevel security
    • Windows mandatory integrity control
    • Clark-Wilson Integrity Model
  • OAuth 2.0 Authorization Framework
    • Goal
    • Roles (RFC 6749)
    • Communication endpoints
    • Application (client)
    • OAuth tokens
    • OAuth flows
      • Code flow
      • Implicit flow
      • Resource owner password flow
      • Client credentials flow
    • Proof Key for Code Exchange (PKCE, RFC 7636)
    • Device authorization grant (RFC 8628)
    • Actual protocol flow
  • Linux Security Mechanisms
    • Mechanisms
    • Linux management privileges
    • Privilege Elevation
    • Capabilities
    • Files extended attributes (xattr)
    • File capabilities
    • Capability transfer across exec
    • Control groups (cgroups)
    • Linux Security Modules (LSM)
    • AppArmor
    • Confinement
  • Authentication Protocols
    • Identity attributes
    • Authentication
    • Authentication interactions
    • Authentication of people
      • Biometrics
      • Token-based OTP generators
      • PAP & CHAP (RFC 1334, 1992, RFC 1994, 1996)
      • S/Key (RFC 2289, 1998)
      • GSM
    • Host authentication
    • Service/server authentication
    • TLS (Transport Layer Security, RFC 8446)
    • SSH (Secure Shell, RFC 4251)
    • Single Sign-On (SSO)
    • Authentication metaprotocols
    • Authentication services
    • Key distribution services
  • PAM (Pluggable Authentication Modules)
    • Motivation
    • PAM
    • PAM APIs
    • Orchestration of PAM actions
    • Module invocation
    • Configuration files
    • PAM orchestration files
    • Scenario 1 – Local authentication
    • Scenario 2 – LDAP auth with local backoff
    • Scenario 3 – MS AD auth with local backoff
  • FIDO and FIDO2 framework
    • FIDO (Fast Identity Online) Alliance
    • Universal 2nd Factor (U2F) protocol
    • WebAuthn
    • Client to Authenticator Protocol (CTAP)
    • Passkeys
  • Authentication with Trusted Third Parties / KDCs
    • Shared-key authentication
    • Key Distribution Center (KDC) concept
    • Kerberos
  • Identity Management
    • Digital Identity
    • Identity Manager (IdM)
    • Identity Provider (IdP)
    • Authoritative source
    • Identity claim
    • Approachs
    • Credential
    • Privacy issues
    • Verifiable credential (VC)
    • Self-Sovereign Identity (SSI)
    • Interoperability
    • eIDAS
  • Anonymity and Privacy
    • Privacy
    • IEEE Digital Privacy Model
    • Privacy with computing technology
    • Privacy and companies
    • Privacy and IAA
    • Identification
    • Authentication
    • Anonymity
    • Microdata privacy issues
    • Microdata privacy enhancing
    • L-Diversity
Powered by GitBook
On this page
  • U2F Devices
  • U2F Protocols
  • Upper layer
  • Certification of U2F devices
  • Anonymity of attestation key pairs
  • Uncertified U2F devices
  • FIDO2 and U2F
  • U2F JS / MessagePort API
  1. FIDO and FIDO2 framework

Universal 2nd Factor (U2F) protocol

The user has a U2F device.

  • The device creates a unique key pair per service. URL based.

  • The service registers the public key on the user account.

    • Different services get different keys.

    • No user tracking.

  • The service requests a user's device signature for their authentication.

Interface with a U2F device.

  • JavaScript API (within browsers).

  • Native OS APIs

U2F Devices

  • USB devices, with a distinctive, recognizable HID interface

  • NFC devices

  • Bluetooth LE devices

  • Software applications, possibly backed up by hardware security devices.

Devices must have a "test of user presence".

  • To prevent accessible devices from being used without user content.

  • Devices cannot respond without such consent.

  • Consent usually involves touching a button (may involve fingerprint or pin code).

U2F Protocols

Upper layer:

  • Core cryptographic protocol.

  • Defines the semantics and contents of the data items exchanged and produced.

  • Defines the cryptographic operations involved in the processing of those data items.

Lower layer:

  • Host-device transport protocol.

  • CTAP (Client To Authenticator Protocol).

Upper layer

User Registration

The U2F device is asked to generate a service-specific key pair. Service is identified with a hash of the service identity.

  • protocol, hostname, port.

The U2F device generates a key pair. And returns a Key Handle and the public key. These elements are provided to the service. The Key Handle encodes the service identity.

User Authentication

The device checks if the service identity hash is valid for the Key Handle. On success looks up the corresponding private key and uses it to sign the hashed client data.

The signature is returned to the caller, who forwards it to the service for validation, together with the client data.

The service validates the client data, and if valid, validates its signature with the user’s public key.

Certification of U2F devices

Service providers need to be sure about the quality of U2F devices, they need a certification.

U2F have an attestation key pair, with a public key certificate issued by the manufacturer, and manufacturers need to be FIFO certified.

Public keys produced by the device are signed with the attestation private key, to prove they were produced by a certified device.

Anonymity of attestation key pairs

U2F devices cannot have unique attestation key pairs. They would not be anonymous any more. Different services could track a user by their attestation public key.

Attestation key pairs are shared by batches of attestation key pairs, and thus, users' U2F devices cannot be tracked.

Uncertified U2F devices

They can exist and still be used, it all depends on the service.

In this case, services have to have their trust chain for those devices.

FIDO2 and U2F

FIDO2 is backwards compatible with U2F devices.

U2F JS / MessagePort API

JavaScript interface used by services Web pages to interact with U2F devices.

  • Using a MessagePort API.

Last updated 1 year ago