WICG
non-TPM devices? Android and iPhone / iOS | iPadOS TPM equivalents?
hi!
just some questions that I'm sure have already been addressed, but seeking confirmation / perhaps they could be in an FAQ?
If a desktop OS does not have a TPM, will this 'fail safe'? Conceptually similar to falling back from TLS 1.3 to TLS 1.2 if necessary.
is the expectation that authentication servers will have a policy capabilities;
- no DBSC requirements
- should use DBSC, but it is acceptable not to
- most use DBSC; cannot proceed without
equally, is the expectation that browsers can implement policies;
- no DBSC requirements
- should use DBSC, but it is acceptable not to
- must use DBSC; cannot proceed without [if a server can't do DBSC, then the user cannot authenticate; might be inconvenient, but organisational security policy might require this]
As an example, as a Google Workspace admin, I set my tenancy to require DBSC, and I apply a Google Chrome policy that requires DBSC. My users can logon to my tenancy and stolen tokens are now useless.
Not an expert, but I am guessing the isolation on iOS | iPadOS and Android means token theft isn't possible, so DBSC isn't required?
How will a [single] authentication endpoint handle desktop apps and mobile apps; in other words, use DBSC for desktop, and not for mobile OSes? The user agent is an indicator, of course, but not dependable. For example, if I use developer tools, I can make my desktop browser appear to be an iPad, thus would not use DBSC. This could be an attack vector; essentially attacker tricks the user to browse to a malicious website presenting a mobile user agent.
I am guessing that this isn't intended to address malicious domains. For example, a user receives an email with a link to https://acounts.google.com [accounts is misspelled] and authenticates. The attacker is using MITM to steal tokens.
[not saying DBSC should address malicious domains; merely seeking confirmation that it isn't intended to do so, and does not]
[forgive my naivete; I'm sure these are dumb questions that have been considered; I just can't find anything]
Answering some of your questions and a bit out of order:
- Cookie theft happens on every Chrome platform, even though some has strong app isolation. It happens a lot more on some specific platforms so we are focusing the effort there but would like to support all platforms in time.
- If a device does not have a TPM, Chrome has chosen to not respond to the header at all, similar to how user agents that do not support DBSC.
- Servers can always try to start a DBSC session, and if the user agent does not support it on the specific device the header should be ignored. That is what we do for the Google prototype.
For your malicious domain example, I would need a bit more details to be sure what you mean.
For Google Workspace, that is not directly related to the official spec so I cannot comment on that here.
thanks @kristianmonsen really helpful!
For Google Workspace, that is not directly related to the official spec so I cannot comment on that here.
Imagine I am a sysadmin for Mandarin Industries. I subscribe to an email service provider called GeeMail. Users access their mail in a browser using mail.mandarin.geemail.org.
The CEO understands the importance of security. Her employees can use MFA and must access using organisational devices only. This offers a very high degree of security.
But once a user authenticates with MFA on an organisational device, the token could be stolen and used elsewhere.
The CEO requires countermeasures to token theft.
She asks me to implement policies against token theft. As the sysadmin, I...
- apply a policy to mail.mandarin.geemail.org that requires DBSC; now, if a browser is unwilling or unable to do DBSC, mail.mandarin.geemail.org will refuse access.
- apply a policy to organisational devices that require DBSC when accessing mail.mandarin.geemail.org. Now, if a browser is unwilling or unable to do DBSC, it will refuse access.
An employee accesses their email as normal.
A genuine-looking, sincere and urgent email gets past filters, but it's malicious. It arrives in the employee's mailbox. The employee opens the malicious email. The payload activates. The payload steals the token. The payload forwards the token to the attacker who attempts to use it. They find it's rejected.
Threat neutralised.
My Friend Sally SysAdmin works for Satsuma Enterprises. They also use GeeMail. Their domain is mail.satsuma.geemail.org
Security is an inconvenience.
- don't apply a policy to mail.satsuma.geemail.org that requires DBSC; access is granted, whether DBSC is used or not
- don't apply a policy to organisational devices that require DBSC when accessing mail.satsuma.geemail.org
A Satsuma Enterprises employee accesses their email as normal - it doesn't use DBSC.
A genuine-looking, sincere and urgent email gets past filters, but it's malicious. It arrives in the employee's mailbox. The employee opens the malicious email. The payload activates. The payload steals the token.
The payload forwards the attacker who attempts to use it. They can access Satsuma Enterprises systems.
Both Mandarin Industries and Satsuma Enterprises use GeeMail, which can apply policies requiring DBSC.
Mandarin Industries required DBSC; their systems remained secure against token theft.
Satsuma Enterprises didn't require DBSC; their systems were compromised.
For your malicious domain example, I would need a bit more details to be sure what you mean.
Mandarin Industries subscribes to GeeMail email service provider which requires DBSC on both browser and tenancy. But they don't require access from organisational devices, so employees can BYOD.
Users access their mail in a browser using mail.mandarin.geemail.org.
Mary Mandarin receives a genuine-looking, sincere and urgent email, but it's malicious.
Mary opens the email. Mary will have a salary deduction of $500 next week. She must check details urgently at mail.mandarin.geeemail.org.
[mail.mandarin.geeemail.org is a malicious domain - geeemail, not the correct domain of mail.mandarin.geemail.org; it uses adversary in the middle (AitM); Mary is panicking, so does not notice]
The browser opens at mail.mandarin.geeemail.org; Mary enters her username, password and the SMS 2FA code. The adversary is relaying on the details to the genuine domain mail.mandarin.geemail.org, even while using DBSC.
The attacker has acquires a valid token to mail.mandarin.geemail.org; the attacker has compromised mail.mandarin.geemail.org, even with DBSC.
[to be clear, not a a criticism of DBSC; just elaborating on what it is, and what it is not]
[mail.mandarin.geeemail.org is a malicious domain - geeemail, not the correct domain of mail.mandarin.geemail.org; it uses adversary in the middle (AitM); Mary is panicking, so does not notice]
The browser opens at mail.mandarin.geeemail.org; Mary enters her username, password and the SMS 2FA code. The adversary is relaying on the details to the genuine domain mail.mandarin.geemail.org, even while using DBSC.
Isn't this a problem for APIs like WebAuthn to solve, not DBSC?
[mail.mandarin.geeemail.org is a malicious domain - geeemail, not the correct domain of mail.mandarin.geemail.org; it uses adversary in the middle (AitM); Mary is panicking, so does not notice] The browser opens at mail.mandarin.geeemail.org; Mary enters her username, password and the SMS 2FA code. The adversary is relaying on the details to the genuine domain mail.mandarin.geemail.org, even while using DBSC.
Isn't this a problem for APIs like WebAuthn to solve, not DBSC?
agreed; as I said, not a a criticism of DBSC; just elaborating on what it is, and what it is not]
iOS, iPadOS and Android all have secure enclaves equivalent to TPMs in terms of secure, attested storage.
iOS, iPadOS and Android all have secure enclaves equivalent to TPMs in terms of secure, attested storage.
Thanks. Does that mean...
- Chrome on iOS, iPadOs and Android are capable of DBSC, using their secure enclaves instead of TPM?
- Chrome on iOS, iPadOs and Android will DBSC, using their secure enclave instead of TPM?
- Chrome on iOS, iPadOs and Android is in scope of this GitHub artefact?
All are in scope of this protocol, our aim is to support this on all version of Chrome. We cannot be sure 100% it is possible, or when it will happen, but that is our goal. It would also be possible for others to support it.
To clarify as well, Android devices do (sometimes) have a TPM, and if so that will be used.
One Mac currently Secure Enclave is used as an TPM.
For iOS my understanding is that it would have to be supported by Apple, even for Chrome.