The flaws of FIDO mechanism

[John]

Hello, FIDO developers,

I just happened to see an article talking about the flaws of FIDO mechanism,

http://zeropasswords.com/pdfs/WHATisWRONG_FIDO.pdf

Some of these flaws, for example, item 3, 4, 5, 7, 10, and 11, are quite convincing to me, while some are not.

What do you think about that?

[Fred Le Tamanoir (NEOWAVE.FR)]

hmm... let's answer this lonely "old" post...

First note / Important reminder: 

The author of this "WHAT is WRONG with FIDO" document is trying to sell is own "no-it-is-not-snakeoil-but-I-can-not-give-any-details-on-it-because-it-is-patented' authentication technology.

I am more confident with FIDO U2F than with UAF but let's give a try to answer the points/flaws you referenced in this document :

3) "Chosen plaintext attacks" and/or "simple collect and break"

"Chosen plaintext" feed = Users needs to interact / to prove their presence, so it is very limited: you can't massively send things to be signed behind the back of the users

(and even if you can send data to be signed, as I will write below, it would be useless to fake an authentication to a real server)

"collect the same challenge-response pairs from an unsecure channel" = not serious at all, yes you can collect this information but it would be simply useless. 

It is not because you have an original message and a signed version too that you will manage to break elliptic curve cryptography enough to obtain the private key.

4) "Malicious challenge"

Yes, you can't guess if a challenge is genuine/legit but (at least in U2F AFAIK) but FIDO device don't just sign only challenge but challenge+appid (domain name in a website use case)+version so it would require to attack on the local FIDO Client level to fake the AppId.

Regarding signing "document digest","fraudulent transactions", "fraudulent approvals"... that is not what FIDO U2F is about, it is about authentication, not document signing or transaction confirmation that could done through other key pairs and/or not even FIDO based or FIDO based with added mutual authentication.

5) "It is not mutual authentication"

Yes, it is not. In a FIDO U2F through Chrome use case for example : the server authentication is done through SSL server certificates and the browsers CAs.

That is a known standard, not the more secure one, but FIDO is about user authentication not about mutual/server authentication. 

Two notes :

- It is outside FIDO specification but you can add mutual authentication and still can be FIDO compliant (for example if the challenge sent by the server is not fully random and contains a signature that can be verified on the FIDO device)

- More important : Even if you are sending signed challenge response to a fake / phishing server, it can't be reused by the attacker on the real server (challenge and/or appid would be different)

7) "Users and Websites are not liable"

Nothing new here, paraphrasing previous points here about lack of mutual authentication and fake challenge (already answered above).

The only new point is about the lack of local or distant log, this is ridiculous since this is not forbidden to implement such features on the client or server side and has nothing to do with FIDO authentication review.

10) "Public keys are in danger". "public keys stored at Websites cannot be public. They need to be private"

Probably the funniest part... with non-sens sentence like "if a hacker manages to switch the user’s public key with his own public key"... yeah... on the server... if you hack the server... then you can... hack the server... this has nothing to do about FIDO review again. Public key are meant to be public.Server security is about... server security. Wow... such confusion.

11) "PKI cannot authenticate users"

The guy simply plays with words. Of course, for example, if you have a UAF device with PIN code protection or biometric information, if you steal the device AND PIN Code or biometric info, you don't need the user anymore... Ok.. let's compare to something else that would be better like.... ? uh ? This kind of rhetorical argument makes no sens... unless if you are trying (like the author) to sell a non-disclosed revolutionary-wannabee snake-oil closed source techno where users have to make some visual magical drawings on their smartphones (as if it will solve anything on the authentication security level...  and by the way, at least most FIDO users won't need to have smartphones and carrier coverage...)

--

Conclusion : Case Closed. No real strong points anywhere.

I only partially agree that it would be great to have mutual authentication without having to rely on SSL for server side, but I think it is possible to add this feature to a FIDO device for known server/services (and even still be FIDO compliant...).

[John]

Thank you.

Now I have more confidence in FIDO from your analysis.
We may say most of these issues are related with a compromised RP/FIDO server.

Fred Le Tamanoir (NEOWAVE.FR)於 2015年6月19日星期五 UTC+8下午9時51分24秒寫道：

hmm... let's answer this lonely "old" post...

First note / Important reminder: 

The author of this "WHAT is WRONG with FIDO" document is trying to sell is own "no-it-is-not-snakeoil-but-I-can-not-give-any-details-on-it-because-it-is-patented' authentication technology.

I am more confident with FIDO U2F than with UAF but let's give a try to answer the points/flaws you referenced in this document :

3) "Chosen plaintext attacks" and/or "simple collect and break"

"Chosen plaintext" feed = Users needs to interact / to prove their presence, so it is very limited: you can't massively send things to be signed behind the back of the users

(and even if you can send data to be signed, as I will write below, it would be useless to fake an authentication to a real server)

"collect the same challenge-response pairs from an unsecure channel" = not serious at all, yes you can collect this information but it would be simply useless. 

It is not because you have an original message and a signed version too that you will manage to break elliptic curve cryptography enough to obtain the private key.

 Agree. Although a compromised server can have some Chosen plaintext material, but due to the user presence feature on the client side, the collected data should be too few for the attack even if a very short ECC key is used. 

 

4) "Malicious challenge"

Yes, you can't guess if a challenge is genuine/legit but (at least in U2F AFAIK) but FIDO device don't just sign only challenge but challenge+appid (domain name in a website use case)+version so it would require to attack on the local FIDO Client level to fake the AppId.

 

A compromised server has the correct AppId, doesn't it?

 

Regarding signing "document digest","fraudulent transactions", "fraudulent approvals"... that is not what FIDO U2F is about, it is about authentication, not document signing or transaction confirmation that could done through other key pairs and/or not even FIDO based or FIDO based with added mutual authentication.

How about UAF's transaction signatures?

 

5) "It is not mutual authentication"

Yes, it is not. In a FIDO U2F through Chrome use case for example : the server authentication is done through SSL server certificates and the browsers CAs.

That is a known standard, not the more secure one, but FIDO is about user authentication not about mutual/server authentication. 

Two notes :

- It is outside FIDO specification but you can add mutual authentication and still can be FIDO compliant (for example if the challenge sent by the server is not fully random and contains a signature that can be verified on the FIDO device)

- More important : Even if you are sending signed challenge response to a fake / phishing server, it can't be reused by the attacker on the real server (challenge and/or appid would be different)

7) "Users and Websites are not liable"

Nothing new here, paraphrasing previous points here about lack of mutual authentication and fake challenge (already answered above).

The only new point is about the lack of local or distant log, this is ridiculous since this is not forbidden to implement such features on the client or server side and has nothing to do with FIDO authentication review.

10) "Public keys are in danger". "public keys stored at Websites cannot be public. They need to be private"

Probably the funniest part... with non-sens sentence like "if a hacker manages to switch the user’s public key with his own public key"... yeah... on the server... if you hack the server... then you can... hack the server... this has nothing to do about FIDO review again. Public key are meant to be public.Server security is about... server security. Wow... such confusion.

 

I interpret this issue as: A compromised server may suffer from the risk that certain public keys being replaced and corresponding accounts being impersonated. Is it possible?

In PKI systems, certificates can resist such kind of key replacement attacks. 

11) "PKI cannot authenticate users"

The guy simply plays with words. Of course, for example, if you have a UAF device with PIN code protection or biometric information, if you steal the device AND PIN Code or biometric info, you don't need the user anymore... Ok.. let's compare to something else that would be better like.... ? uh ? This kind of rhetorical argument makes no sens... unless if you are trying (like the author) to sell a non-disclosed revolutionary-wannabee snake-oil closed source techno where users have to make some visual magical drawings on their smartphones (as if it will solve anything on the authentication security level...  and by the way, at least most FIDO users won't need to have smartphones and carrier coverage...)

Well, 

FIDO's biggest advantage of keeping biometric data locally, seems have a disadvantage.

[Fred Le Tamanoir (NEOWAVE.FR)]

4) "Malicious challenge"

Yes, you can't guess if a challenge is genuine/legit but (at least in U2F AFAIK) but FIDO device don't just sign only challenge but challenge+appid (domain name in a website use case)+version so it would require to attack on the local FIDO Client level to fake the AppId.

 

A compromised server has the correct AppId, doesn't it?

This use case is hardly a real use case : if your server is compromised on this level, the attacker probably already have access to everything related to this ID... and most of everyone's ID. In every authentication architecture, if your server security is broken, you can't do much...

 

Regarding signing "document digest","fraudulent transactions", "fraudulent approvals"... that is not what FIDO U2F is about, it is about authentication, not document signing or transaction confirmation that could done through other key pairs and/or not even FIDO based or FIDO based with added mutual authentication.

How about UAF's transaction signatures?

I guess UAF has the same kind of AppID protection (I am not an UAF expert).

 

10) "Public keys are in danger". "public keys stored at Websites cannot be public. They need to be private"

Probably the funniest part... with non-sens sentence like "if a hacker manages to switch the user’s public key with his own public key"... yeah... on the server... if you hack the server... then you can... hack the server... this has nothing to do about FIDO review again. Public key are meant to be public.Server security is about... server security. Wow... such confusion.

 

I interpret this issue as: A compromised server may suffer from the risk that certain public keys being replaced and corresponding accounts being impersonated. Is it possible?

In PKI systems, certificates can resist such kind of key replacement attacks.

In most of PKI systems, servers security are critical too... an attacker can change the CA if it is a local authority, remove a user certificate and enroll a new one, etc.and by the way, in many small network architecture PKI servers are used to support other roles...

11) "PKI cannot authenticate users"

The guy simply plays with words. Of course, for example, if you have a UAF device with PIN code protection or biometric information, if you steal the device AND PIN Code or biometric info, you don't need the user anymore... Ok.. let's compare to something else that would be better like.... ? uh ? This kind of rhetorical argument makes no sens... unless if you are trying (like the author) to sell a non-disclosed revolutionary-wannabee snake-oil closed source techno where users have to make some visual magical drawings on their smartphones (as if it will solve anything on the authentication security level...  and by the way, at least most FIDO users won't need to have smartphones and carrier coverage...)

Well, 

FIDO's biggest advantage of keeping biometric data locally, seems have a disadvantage.

IMHO, Biometrics solutions are about convenience, not really about security. Biometrics technologies have been proven broken for years and mixing secure PKI with information that can't be revocated is not a good idea... but that's not the subject here :)

[John]

Fred Le Tamanoir (NEOWAVE.FR)於 2015年6月22日星期一 UTC+8下午4時27分01秒寫道：

4) "Malicious challenge"

Yes, you can't guess if a challenge is genuine/legit but (at least in U2F AFAIK) but FIDO device don't just sign only challenge but challenge+appid (domain name in a website use case)+version so it would require to attack on the local FIDO Client level to fake the AppId.

 

A compromised server has the correct AppId, doesn't it?

This use case is hardly a real use case : if your server is compromised on this level, the attacker probably already have access to everything related to this ID... and most of everyone's ID. In every authentication architecture, if your server security is broken, you can't do much...

 

The so called compromised server has different levels, a database admin with bad intention, for example, doesn't need to hack the whole system, can achieve such kind of key replacement and impersonation attack. However this is really not relating to FIDO protocol but to the security of identity storage.

For traditional password systems, a simple mechanism like a well designed hash mac, can resist such kind of password replacement and impersonation attack. However, public keys are user's identity in FIDO, I don't know how to use one way hashes to this end.

--

Conclusion : Case Closed. No real strong points anywhere.

Although this forum is for fido development only, but I think discussing the possible weakness may be beneficial for developers to strengthen the security in system implementation.