search

w3c / webauthn

Web Authentication: An API for accessing Public Key Credentials
https://w3c.github.io/webauthn/
Other
1.18k stars 171 forks source link

SafetyNet response as an extension #1011

Closed gmandyam closed 5 years ago

gmandyam commented 6 years ago

Given (a) SafetyNet response is not really an attestation to the WebAuthn credential, and (b) Android Keystore provides attestation responses related to keys that can be created and managed by a trusted execution environment, and (c) lack of ubiquity of SafetyNet in Android ecosystem - it is proposed that the SafetyNet response be offered as a client extension. This could in turn lead to also removing SafetyNet as an attestation format.

See PR https://github.com/w3c/webauthn/pull/1010.

yackermann commented 6 years ago

@gmandyam Safetynet is a secure form of attestation that is used as primary source for attesting devices by Android Pay. KeyStore attestation only used as additional factor.

yackermann commented 6 years ago

@gmandyam https://media.ccc.de/v/34c3-8965-decoding_contactless_card_payments#t=0

gmandyam commented 6 years ago

@herrjemand

Disagree. SafetyNet is implemented in rich execution environment (REE) and is subject to third-party tampering. Is it not in implemented in a RoT.

yackermann commented 6 years ago

I am lost. You argue against SafetyNet just because it's REE? And what do you mean by "third-party tampering"? Do you have any papers?

apowers313 commented 6 years ago

Note that the first batch of FIDO Certified servers will support SafetyNet as an attestation format, not an extension. If this PR is approved some consideration should be given to compatibility with in-market servers and authenticators.

gmandyam commented 6 years ago

@herrjemand

See documentation on Samsung's TIMA solution, e.g. https://www.engr.ncsu.edu/news/2014/11/19/tima-technology-is-core-to-samsungs-state-of-the-art-knox-platform/.

"Security software can be bypassed, creating vulnerabilities for smartphone companies and users, especially enterprise users. But the TIMA technology addresses this problem by incorporating security features with continuous monitoring that is well isolated and protected by hardware based mechanisms– making it difficult, if not impossible, to bypass. "

gmandyam commented 6 years ago

@apowers313

Perhaps support for a SafetyNet attestation should not be a criteria for achieving FIDO certification. It would be one less attestation format to test for. Regardless, that is a FIDO issue and this is the W3C - we should discuss in the proper forum.

ve7jtb commented 6 years ago

The soon to be released Android platform authenticator is currently using Safety Net attestations. At least on my test Pixel. So there will be a broadly deployed authenticator using that format. Removing validation from the server needs significant discussion.

yackermann commented 6 years ago

@gmandyam This is 2014 post. Anything more recent? Academic papers? Security researches?

yackermann commented 6 years ago

cc @christiaanbrand @leshi

gmandyam commented 6 years ago

@herrjemand

TIMA is a fundamental feature of the Samsung Knox security framework - see https://seap.samsung.com/faq/what-knox-tima-keystore and https://developer.samsung.com/tech-insights/knox/platform-security.

The official Knox whitepaper is available at https://www.samsungknox.com/docs/SamsungKnoxSecuritySolution.pdf. There is also an ACM paper available at https://dl.acm.org/citation.cfm?id=2660350.

gmandyam commented 6 years ago

@ve7jtb

Actually https://github.com/w3c/webauthn/pull/1010 does not remove SafetyNet as an attestation format - it only proposes the new extension. In this regards, SafetyNet can be provided as a health measurement in addition to any other attestation format supported by the authenticator.

As I said when creating the issue: "This could in turn lead to also removing SafetyNet as an attestation format." This does not mean it has to be removed in ver. 1.

ve7jtb commented 6 years ago

Adding Safety Net to a Android keystore attestation may be useful. That should be considered for the next version, however. We want to lock things down for this version.

gmandyam commented 6 years ago

@herrjemand

One more recent reference from 2017: http://s-space.snu.ac.kr/handle/10371/122680. The study presents different ways to essentially compromise an API. From the discussion section -

"Although SafetyNet seems to collect various information, fundamentally, it shares the same limitation with other cases shown in this paper as long as a compromised kernel finds ways to present fake data that make it appear unchanged when probed by SafetyNet."

There is also a corresponding ACM paper in https://dl.acm.org/citation.cfm?id=3053018.

gmandyam commented 6 years ago

@herrjemand

Please take a look at the Black Hat Europe presentation available at https://www.blackhat.com/docs/eu-17/materials/eu-17-Mulliner-Inside-Androids-SafetyNet-Attestation.pdf. The "Attacks" section documents a variety of attacks against SafetyNet, and show how they affect different versions of Android. The presenters also included several improvements, including anchoring the attestation in trusted HW.

This is the most recent reference I have found.

christiaanbrand commented 6 years ago

I'm not sure that the comments here are really relevant to the core issue: SafetyNet is suppose to give an RP some idea about the level of risk involved with trusting a key attested to in this fashion. I believe it does just that. RPs are free to make their own risk decisions when getting this attestation type. SafetyNet also continuously evolves, and the "attacks" folks refer to here might already mostly be mitigated.

Yes, I agree that in a perfect world it might make sense to have an extension that talks about "platform integrity" but this is just not something we can commit to at this point.

I vote for this staying as a form of attestation.