Difference between revisions of "Proof of Presence"

From MgmtWiki
Jump to: navigation, search
(Windows)
(Chomium Browser)
 
(43 intermediate revisions by the same user not shown)
Line 3: Line 3:
  
 
==Context==
 
==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 Certificate]]s are designed to link a collection of attributes to a real-world name of an entity.
 
* Traditional [[X.509 Certificate]]s are designed to link a collection of attributes to a real-world name of an entity.
 
* With the introduction of [[Verifiable Credential]]s attributes are just linked to Identifiers which resolve to public keys.
 
* With the introduction of [[Verifiable Credential]]s attributes are just linked to Identifiers which resolve to public keys.
Line 10: Line 11:
  
 
* Orie Steele (Transmute)  reported on some work on biometric verifiable presentations a while ago. He used [https://www.bioid.com/ 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}.
 
* Orie Steele (Transmute)  reported on some work on biometric verifiable presentations a while ago. He used [https://www.bioid.com/ 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#Standard_categories_of_Authentication_Factors|Multi-factor Authentication]].
  
 
==Problems==
 
==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.
 
* 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.
 +
* [https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Forange.hosting.lsoft.com%2Ftrk%2Fclick%3Fref%3Dznwrbbrs9_6-2be2bx32c51dx081583%26&data=04%7C01%7C%7C1b0cfc8a7db9484bb50308d946e0a1e9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637618752868995392%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Zs1FPnlYyexB5IRM3JPArxu918hSOiMYcLH3Ko6xKOU%3D&reserved=0 Faces Are the Next Target for Fraudsters] The Wall Street Journal Parmy Olson 2021-07-07<blockquote>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.</blockquote>
  
 
==Standards==
 
==Standards==
Line 28: Line 47:
 
===Wallet===
 
===Wallet===
 
* [https://trustregistry.org/ Trust registries] for native code applications have been proposed but not yet widely implemented.
 
* [https://trustregistry.org/ Trust registries] for native code applications have been proposed but not yet widely implemented.
 +
* [https://nvlpubs.nist.gov/nistpubs/ir/2021/NIST.IR.8334-draft.pdf 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.)
  
==Solutions==
+
===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===
 +
* https://diacc.ca/2021/06/29/facial-biometrics-liveness-3d-representation/ Facial Biometrics: Liveness and Anti-Spoofing] 2021-06-29 DIACC
 +
 
 +
==Solutions by Manufacturer==
 
There are two ways to get a trusted signer on the phone or other user computing device.
 
There are two ways to get a trusted signer on the phone or other user computing device.
 
# 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.
 
# 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.
Line 42: Line 77:
 
===Android===
 
===Android===
 
* [https://developer.android.com/training/articles/keystore The Android Keystore system lets you store cryptographic keys in a container to make it more difficult to extract from the device]
 
* [https://developer.android.com/training/articles/keystore The Android Keystore system lets you store cryptographic keys in a container to make it more difficult to extract from the device]
 +
===Chomium Browser===
 +
* [https://www.xda-developers.com/google-chrome-supports-windows-hello-payment-authentication/ Google Chrome supports “Windows Hello” face unlock and fingerprint for payment authentication] 2020-05-22
 +
* [https://findbiometrics.com/chrome-users-can-now-authenticate-with-windows-hello-biometrics-905267/ Chrome Users Can Now Authenticate With Windows Hello Biometrics] 2020-05-26<blockquote>To enable the feature — which requires a Windows 10 device — users need to go to the Settings menu in the Chrome browser and select the Payment Methods submenu. From there it should just be a matter of toggling the switch next to the Windows Hello option. This action is validated by a hello scan and "OK" popup.</blockquote>
 +
* [https://github.com/WICG/idle-detection/blob/main/README.md  Idle dection] has been proposed (2021-06) for Chrome but not yet for Safari.
 +
 
===Apple===
 
===Apple===
 
* [https://developer.apple.com/documentation/security/keychain_services The keychain services API helps you solve this problem by giving your app a mechanism to store small bits of user data in an encrypted database called a keychain.]
 
* [https://developer.apple.com/documentation/security/keychain_services The keychain services API helps you solve this problem by giving your app a mechanism to store small bits of user data in an encrypted database called a keychain.]
 +
* https://manuals.info.apple.com/MANUALS/1000/MA1902/en_US/apple-platform-security-guide.pdf Introduction to Apple platform security] 2021-02
 +
 
===Windows===
 
===Windows===
The user must have either an Azure Active Directory or Microsoft (Passport) Account connected to their Windows settings. (This does not imply that other Windows PoP, like Microsoft Authenticator, cannot still be used.)
+
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 [https://docs.microsoft.com/en-us/windows/uwp/security/microsoft-passport Windows Hello] on their machine, it generates a new public–private key pair on the device. The [https://docs.microsoft.com/en-us/windows/keep-secure/trusted-platform-module-overview 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.
 
When a user sets up [https://docs.microsoft.com/en-us/windows/uwp/security/microsoft-passport Windows Hello] on their machine, it generates a new public–private key pair on the device. The [https://docs.microsoft.com/en-us/windows/keep-secure/trusted-platform-module-overview 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.
Line 53: Line 95:
 
* [https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-why-pin-is-better-than-password Why a PIN is better than a password] Windows 2017-10-23
 
* [https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-why-pin-is-better-than-password Why a PIN is better than a password] Windows 2017-10-23
 
* [https://docs.pingidentity.com/bundle/pingid/page/vok1564020450231.html Using Windows Hello for authentication] Ping ID 2020-12-07
 
* [https://docs.pingidentity.com/bundle/pingid/page/vok1564020450231.html Using Windows Hello for authentication] Ping ID 2020-12-07
 +
* [https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/why-are-my-users-not-prompted-for-mfa-as-expected/ba-p/1449032 Sign-in process results in the user/Windows 10 device obtaining a new type of cloud-aware credential from Azure AD known as a “Primary Refresh Token” – or PRT. ]
 +
* [https://docs.microsoft.com/en-us/windows/win32/api/_secbiomet/ Windows Biometric Framework] root page on docs.msft is essential source of authentication factors for sign-in, payments, etc.
  
 
==References==
 
==References==
 
* This wiki is part of the larger problem of [[Apps on User Devices]].
 
* This wiki is part of the larger problem of [[Apps on User Devices]].
 
* A related problem is described in the [https://wiki.idesg.org/wiki/index.php/Over_21_with_Proof_of_Presence_Use_Case Over 21 with Proof of Presence Use Case].
 
* A related problem is described in the [https://wiki.idesg.org/wiki/index.php/Over_21_with_Proof_of_Presence_Use_Case Over 21 with Proof of Presence Use Case].
 
+
* See also wiki page on [[Biometric Attribute]]s.
  
 
[[Category: Glossary]]
 
[[Category: Glossary]]
 
[[Category: Authentication]]
 
[[Category: Authentication]]
 
[[Category: Assurance]]
 
[[Category: Assurance]]

Latest revision as of 12:58, 26 July 2021

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

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