Proof of Presence

From MgmtWiki
Revision as of 13:03, 7 June 2021 by Tom (talk | contribs) (→‎Taxaonomy)

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)
  • Third Authentication Factor = something your are.

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.

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.

Solutions

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

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