DBSCs are an antidote to session cookie theft. Once a website sets a session cookie, the visiting browser must send a form of the cookie that’s signed with the key stored in the silicon. Properties in the TPM or secure enclave isolate the key in a way that prevents it from being extracted. Apple explains the process here.
“The attacker can’t steal the private key from the device because the TPM / Secure Enclave will not release it. That is the core protection here,” Scott Helme, a researcher and founder of Report URI who blogged about the new protections on Tuesday, told Ars. “The attacker can steal the cookie, but they can’t answer a DBSC challenge by signing it with the private key, which is still safe on your device.”
For the moment, DBSCs are supported only in Chrome version 147 for Windows and 150 for macOS. Even then, DBSCs are turned on only for a limited set of users. Presumably, Google is testing the feature before making it generally available. Chrome users on Windows and macOS can check whether it’s running in their browser by opening developer tools, clicking on the application tab across the top, and scrolling down. When a user is logged into a site that supports DBSCs, “device bound sessions” will appear if the protection is turned on.
It’s unclear when, or if, other Chromium-based browsers will implement DBSCs, but it’s likely they will be coming.
DBSCs are the latest form of authentication that eliminates the reliance on a shared secret, which, as the world has known for years, is painfully easy for attackers to steal. Under this new model, web servers store the visitor’s public key. The servers then send an authentication challenge incorporating the session cookie. Unless the resulting answer, known as an authentication assertion, is signed by the private key stored safely in the TPM or secure enclave, the assertion is rejected. Passkeys—which you can read about in this post published earlier on Tuesday—work the same way.