Proof of Presence

From MgmtWiki
Jump to: navigation, search

Full Title

Proof of Presence of user and app.

Context

  • Proof of Presence devices have been issued to guards on patrol for many years. The current incarnation of these is a FIDO/WebAuthN key that contains an embedded private key.
  • Traditional X.509 Certificates are designed to link a collection of attributes to a real-world name of an entity.
  • With the introduction of Verifiable Credentials attributes are just linked to Identifiers which resolve to public keys.
  • Decentralized IDs are one of those linked only to a public key and present a problem with assurance of the trustworthiness of the wallet apps.

Goal: to convert a verifiable credential into a verifiable presentation that includes online proof of presence of the subject of the Verifiable Presentation.

  • Orie Steele (Transmute) reported on some work on biometric verifiable presentations a while ago. He used BioID Face Recognition & Liveness Detection Software. BioID provides software-based biometric authentication with presentation attack detection using face recognition and liveness detection. Most likely you would make a presentation that included a short lived liveness credential and the credential of primary concert to the Verifiable Presentation, for example: {DriversLicense, BiometricLivenessCheck}.

Taxaonomy

  • Biometrics = “automated recognition of individuals based on their biological and behavioral characteristics.” (800-63-3)
  • First Authentication Factor = something your know.
  • Second Authentication Factor = something your have.
  • Third Authentication Factor = something you are.
  • Liveness = evidence that the personal biometric measurement is taken directly from the presence of the individual.
  • Proof of Control = The user has complete control of the credential (aka private key) that is used in signing. It typically is created by the wallet that "holds" the key in hardware.
  • Proof of Possession = The user has access to credentials (typically a priavate key) that can be used to prove they control that credential.
  • Proof of Presence = The user performs some act that can tie their real-wold presence at the device that is creating the message (that test can be run either local or remote)
  • Camera Use = The user device can scan data or faces and forward them to the verifier as a part of on-line proofing that is not part of this topic.

Some of these definitions come from the wiki page Multi-factor Authentication.

Problems

  • By far the biggest impediment to create a proof of presence reporter is trust by the Relying Party of the code that report the claim. Wallets in Apple and Android smartphone have the advantage be being provided the the o/s vendors which are known quantities. Wallets from third parties have a huge hill to climb in getting that kind of acceptance by the other sites.
  • Collecting data, particularly biometric data, about the user carries privacy concerns listed in NIST 8334.
  • Rates of error, both false positives and false negatives, are hard to find and may be consider propriety so it it hard to evaluate biometric results.
  • In some environments it is difficult to acquire biometric data, for example a first responder could be wrapped in protective gear.
  • Some mobile devices are used by more that one user, for example at a disaster site, which creates some confusion about the user at a particular time.
  • Faces Are the Next Target for Fraudsters The Wall Street Journal Parmy Olson 2021-07-07
    Facial recognition systems increasingly are a target for fraudsters. Identity verification company ID.me Inc. found more than 80,000 attempts to trick facial identification verification to claim fraudulent unemployment benefits between June 2020 and January 2021. ID.me's Blake Hall said these attempts involved people wearing masks, using deepfakes, or holding up images or videos of other people. Veridium LLC's John Spencer said fraudsters sometimes try to carry out "presentation attacks" by using a photo of someone's face, cutting out the eyes and using it as a mask. Adversa.ai's Alex Polyakov said the algorithms underpinning these systems need to be updated, or the models need to be trained with a large number of adversarial examples, to protect against such spoofing.

Standards

Cloud based

The IATA traveler Identification process is compliant with ICAO standards. The process that a passenger would take to securely identify themselves in the IATA Travel Pass uses government issued ePassports to create a digital travel credential as per the standards developed through ICAO. The process has six steps:

  1. Download the free IATA Travel Pass to their Smart phone and login
  2. Take a selfie with the smart phone
  3. Complete a liveness test as instructed by the phone – i.e., move their head, close their eyes in front of the camera as instructed
  4. Scan the data on the two lines at the bottom of the passport photo page with their smart phones and scan the data-chip on the passport as prompted by the phone
  5. The IATA Travel Pass then matches the photo with the passport data (which contains a digital biometric photo of the passport holder) to verify that:
    1. the passport belongs to the person in front of the phone and
    2. that the passport is genuine and has not been tampered with.
  6. The verified digital travel credential is then stored on the passenger's phone and can be used as their ‘digital passport/ ID’.

Wallet

  • Trust registries for native code applications have been proposed but not yet widely implemented.
  • NISTIR 8334 was release in 2021-05 in draft form and was the source of the following.
    • The most common use of biometrics in smartphones is for screen unlock.
    • If the phone could prove that biometrics were used for unlocked, it might be sufficient as a third factor. (That was not possible on the date released.)
    • NIST 800-63-3 require that biometrics be used with something you have, which the phone as the potential for providing.
    • Local validation of the biometric measurement is preferred (over cloud based validation.)

FIDO

FIDO authenticators can provide MFA by requiring verification with a biometric. Biometric verification occurs locally, activating a private key that is then used to sign an authentication challenge. For privacy reasons, the FIDO standards explicitly disallow the extraction of biometric information from the client device, so they cannot support server-side biometric verification. A FIDO authenticator could meet the requirements from NIST Special Publication (SP) 800-63B [6]—part of the Digital Identity Guidelines—for single or multi-factor hardware or software cryptographic authenticators, depending on the characteristics of the specific authenticator.

Wearables

  • Liveness is easily checked by smart watches but it requires some initialization to be sure of the identity of the user.

Solutions by Type

Liveness

User Verifying Platform Authenticator (UVPA)

A UVPA is a biometric or fingerprint used by a device running some sort of authenticator. A platform authenticator is an authenticator built into a device. The user verifying means that the authenticator has an ability to verify the user, typically with a fingerprint sensor, but it could be with facial recognition, a PIN, a password, or pattern depending on the device. These are usually referred to as screen lock on Android and Touch ID or Face ID on iOS. (This description is from Android.)

Solutions by Manufacturer

There are two ways to get a trusted signer on the phone or other user computing device.

  1. Register an app that is trusted. If that is the method the easiest way is to register the actual instance of the wallet itself to the user.
  2. For a high assurance credential presentation to work, there has to be an element on the phone that is a "trusted" issuer.

The most likely solution is a certified wallet that includes some "credential" that is securely stored in the Trusted Execution Environment, for example the Android KeyStore and depend on the trusted element in the phone to boot up an assurance element - the TPM code in the TEE could do that, but it depends on a trusted server in the could. All of these depend on a web of trust that is not based on any human intervention. Not sure what the rWOT guys think about that? (nb this could be accomplished with a webauthn token like that from Yubikey)

Note that more than one type of "credential" is implied here.

  1. The Private Key under the control of the user.
  2. Credentials with data bound to that Private Key.

Android

Chomium Browser

Apple

Windows

The user must have either an Azure Active Directory or Microsoft (Passport) Account connected to their Windows settings to use Windows Hello. (This does not imply that other Windows PoP, like Microsoft Authenticator, cannot still be used.)

When a user sets up Windows Hello on their machine, it generates a new public–private key pair on the device. The trusted platform module (TPM) generates and protects this private key. If the device does not have a TPM chip, the private key is encrypted and protected by software. In addition TPM-enabled devices generate a block of data that can be used to attest that a key is bound to TPM. This attestation information can be used in your solution to decide if the user is granted a different authorization level for example. Windows Hello provides strong Multi-factor Authentication that is fully integrated into Windows and replaces reusable passwords with the combination of a specific device, and a biometric gesture or PIN. An application can never use the keys from another application, nor can someone ever use the keys from another user.

To enable Windows Hello on a device, the user must have either their Azure Active Directory account or Microsoft Account connected in Windows settings.

References

Context

Problem

Solution

References

Retrieved from "http://tcwiki.azurewebsites.net/index.php?title=Proof_of_Presence&oldid=15581"