SafetyNet response as an extension

[gmandyam]

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 #1010.

[yackermann]

@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]

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

[gmandyam]

@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]

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]

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]

@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]

@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]

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]

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

[yackermann]

cc @christiaanbrand @leshi

[gmandyam]

@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]

@ve7jtb

Actually #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]

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]

@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]

@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]

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.