Doubt regarding authenticator type for Platform Authenticator

81 views
Skip to first unread message

Pro Coder 101

unread,
Jan 13, 2023, 1:43:42 AM1/13/23
to FIDO Dev (fido-dev)
The various types of authentication requirements as specified by NIST SP 800-63B include Memorized Secrets, Look-Up Secrets, Out-of-Band Devices, Single-Factor OTP Devices, Multi-Factor OTP Devices, Single-Factor Cryptographic Software, Single-Factor Cryptographic Devices, Multi-Factor Cryptographic Software, Multi-Factor Cryptographic Device and so on. 

When a Smartphone is used as a platform authenticator with FIDO2 specifications, it does the same as a Multi-factor cryptographic device/software. It first verifies biometric or screen lock and then allows the use as a cryptographic authenticator. I doubt whether the phone is a Muti-Factor Cryptographic DEVICE or is it just running a Multi-Factor Cryptographic SOFTWARE. Is the phone regarded as a separate authentication device or just a running software? 

I would be obliged if this doubt is cleared as soon as possible.

Aditya Mitra

Arshad Noor

unread,
Jan 13, 2023, 8:08:25 AM1/13/23
to Pro Coder 101, FIDO Dev (fido-dev)
When the phone is used with a TEE, it is running multi-factor
cryptographic software - albeit, in a hardware-controlled execution
environment.

When the phone has a discrete cryptographic hardware module - a secure
element such as the TPM, Titan M2, etc. - it is a multi-factor
cryptographic device.

https://www.androidcentral.com/how-does-google-titan-m2-and-tensor-security-core-work

This Android client library can tell whether the mobile device is using
only the TEE or a distinct secure element for FIDO2:

https://sourceforge.net/projects/strongkeyfido/files/v4.8.0/sampleapps/java/sacl/

Arshad Noor
StrongKey
> https://AdityaMitra5102.github.io <https://AdityaMitra5102.github.io>
>
> --
> You received this message because you are subscribed to the Google
> Groups "FIDO Dev (fido-dev)" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to fido-dev+u...@fidoalliance.org
> <mailto:fido-dev+u...@fidoalliance.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CAN%2B3J_i-o0WpO3iu-f-eqdiOMkaRte48Ghz33Ue6TY80tK_Ltg%40mail.gmail.com <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CAN%2B3J_i-o0WpO3iu-f-eqdiOMkaRte48Ghz33Ue6TY80tK_Ltg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

Arshad Noor

unread,
Jan 13, 2023, 8:18:09 AM1/13/23
to Pro Coder 101, FIDO Dev (fido-dev)
I may have given "multi-factor cryptographic software" too much credit -
the phone does not have to have a TEE to be using multi-factor
cryptographic software; it can simply use cryptographic keys in the
standard operating environment and be given the same label.

Using a TEE does provide an additional layer of security that still
classifies the solution as "multi-factor cryptographic software", but
with the additional protection of a restricted operating environment
controlled by the TEE.

The "multi-factor cryptographic device" label still requires a discrete
cryptographic hardware module.

Arshad

Arshad Noor

unread,
Jan 13, 2023, 10:30:29 AM1/13/23
to Pro Coder 101, FIDO Dev (fido-dev)
It depends. In most cases, that characterization would be true - but
apparently, the Galaxy S20 does have a secure element. If they have
integrated it with AndroidKeystore, then it can be classified as a
multi-factor cryptographic device (when used with biometrics/PIN/Pattern
for user verification).

https://www.androidauthority.com/samsung-secure-element-1087561/

https://news.samsung.com/global/samsung-introduces-best-in-class-data-security-chip-solution-for-mobile-devices

Arshad

On 1/13/23 5:31 AM, Pro Coder 101 wrote:
> Thanks for the clarification. Does this imply that Samsung Knox which
> uses the ARM TrustZone environment, works as "multi-factor cryptographic
> software' in relation to FIDO?
> Aditya Mitra
> https://AdityaMitra5102.github.io <https://AdityaMitra5102.github.io>
>
>
> On Fri, Jan 13, 2023 at 6:48 PM Arshad Noor <arsha...@strongkey.com
> <mailto:arsha...@strongkey.com>> wrote:
>
> I may have given "multi-factor cryptographic software" too much
> credit -
> the phone does not have to have a TEE to be using multi-factor
> cryptographic software; it can simply use cryptographic keys in the
> standard operating environment and be given the same label.
>
> Using a TEE does provide an additional layer of security that still
> classifies the solution as "multi-factor cryptographic software", but
> with the additional protection of a restricted operating environment
> controlled by the TEE.
>
> The "multi-factor cryptographic device" label still requires a discrete
> cryptographic hardware module.
>
> Arshad
>
> On 1/13/23 5:08 AM, Arshad Noor wrote:
> > When the phone is used with a TEE, it is running multi-factor
> > cryptographic software - albeit, in a hardware-controlled execution
> > environment.
> >
> > When the phone has a discrete cryptographic hardware module - a
> secure
> > element such as the TPM, Titan M2, etc. - it is a multi-factor
> > cryptographic device.
> >
> >
> https://www.androidcentral.com/how-does-google-titan-m2-and-tensor-security-core-work <https://www.androidcentral.com/how-does-google-titan-m2-and-tensor-security-core-work>
> >
> > This Android client library can tell whether the mobile device is
> using
> > only the TEE or a distinct secure element for FIDO2:
> >
> >
> https://sourceforge.net/projects/strongkeyfido/files/v4.8.0/sampleapps/java/sacl/ <https://sourceforge.net/projects/strongkeyfido/files/v4.8.0/sampleapps/java/sacl/>
> <mailto:fido-dev%2Bunsu...@fidoalliance.org>
> >> <mailto:fido-dev+u...@fidoalliance.org
> <mailto:fido-dev%2Bunsu...@fidoalliance.org>>.
> >> To view this discussion on the web visit
> >>
> https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CAN%2B3J_i-o0WpO3iu-f-eqdiOMkaRte48Ghz33Ue6TY80tK_Ltg%40mail.gmail.com <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CAN%2B3J_i-o0WpO3iu-f-eqdiOMkaRte48Ghz33Ue6TY80tK_Ltg%40mail.gmail.com> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CAN%2B3J_i-o0WpO3iu-f-eqdiOMkaRte48Ghz33Ue6TY80tK_Ltg%40mail.gmail.com?utm_medium=email&utm_source=footer <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CAN%2B3J_i-o0WpO3iu-f-eqdiOMkaRte48Ghz33Ue6TY80tK_Ltg%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
>

rick.h...@att.net

unread,
Jan 16, 2023, 4:13:54 PM1/16/23
to Pro Coder 101, FIDO Dev (fido-dev)

Good question that points up a bit of contention. The screen lock is separate and apart from cryptographic software and worse yet, optional in both use and type. Added to that, neither android or iOS provide api’s to verify type and use. Thus, a strong argument can be made that screen lock is not a factor in the authentication ceremony. On the other hand, if the multi-factor cryptographic software did for example require a biometric as a condition of use then that biometric would be considered a factor.

--

You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CAN%2B3J_i-o0WpO3iu-f-eqdiOMkaRte48Ghz33Ue6TY80tK_Ltg%40mail.gmail.com.

Mike Hill

unread,
Jan 17, 2023, 7:14:19 AM1/17/23
to rick.h...@att.net, Pro Coder 101, FIDO Dev (fido-dev)
Unless the biometric can be reset by restarting the device and using a PIN.  Then the number of user authentication factors boils down to PIN + cryptographic key (hardware or software).  Isn't that so?



--
Michael Hill
Founder & CEO
------------------------------------------------------------------
USA: +1 (202) 412-0821
IRL: +353 85 8334477
www.SensiPass.com
@sensipass

Authenticating people, not just credentials.

This transmission is issued by SensiPass Inc. and/or SensiPass Ltd. This email and the information it contains may be legally privileged and/or confidential. It is for the intended recipient only. If an addressing or transmission error has misdirected this email, please notify the author by replying to this email. If you are not the intended recipient, you may not use, disseminate, alter, print or copy any information in or transmitted with this message or deliver to anyone. SensiPass is incorporated and registered in the United States and Ireland. 

Registered offices:
3101 Wilson Boulevard, Suite 240, Arlington, VA, 22201, USA
Guinness Enterprise Centre, Taylor's Lane, Dublin D08 YE0P, Ireland.  
©2023 SensiPass. All rights reserved.

rick.h...@att.net

unread,
Jan 17, 2023, 11:40:31 AM1/17/23
to Mike Hill, Pro Coder 101, FIDO Dev (fido-dev)

Hi Mike,

 

Not really. A phone is a platform facilitating running software apps. A software app could be an authenticator but that does not change the phone’s persona. If we look to NIST for guidance and specifically their definition of “Multi-Factor Authentication (MFA)” that references “Multi-Factor Authenticator” (SP 800-63-3) we learn “factors” relate to the authenticator and its authentication ceremonies, in other words the app. Using that as a guide as I prefer, then the Multi-Factor Cryptographic SOFTWARE FIDO2 authenticator app represents a single factor. If that app should also verify user identity using biometrics then it becomes 2 factors. And if the biometric verification includes a PIN then that is a third factor. I know of only one FIDO2 authenticator app thus far that delivers all 3 as described here.

 

Notwithstanding all of that there is also the pesky word “assumption” where reliance on screen lock is concerned. Neither Google or Apple permit an app to learn screen lock particulars. Thus the authenticator app blind to screen lock use or type or time of use, blah, blah, blah. Where screen lock is concerned, the app blindly completes the authentication ceremony as a single factor. If one prefers to accept screen lock as a factor of the authentication ceremony, they do so as an unproven “assumption”. Not exactly what NIST describes.

 

And yes, I see this applies even if the app is called a “Passkey”.

 

Rick

Reply all
Reply to author
Forward
0 new messages