Steve Gibson (158:31)
Yeah, to the device. So if someone takes them elsewhere, they can't use them for long. Perfect. And if there's any question about them, then a re authentication can be required Anyway, so this says DBSC is bound to a device with cryptographic keys that cannot be exported from the user's device. Under normal circumstances this is called device binding. Unfortunately it's not hyphenated in the rest of this document. DBSC provides an API that servers can use to create a session bound to a device. And this session can periodically be refreshed with an optional cryptographic proof. The session is still bound to the original device, which I didn't understand the first time I read it, but it'll get clear in a minute. At sign in, the API informs the browser that a session starts which triggers the key creation. It then instructs the browser that anytime a request is made while the session is active, the browser should ensure the presence of certain cookies. If these cookies are not present, DBSC will hold network requests while querying and configured the configured endpoint for update cookies. Updated cookies now. Okay, let me stop because now I under. I didn't understand what the heck they were talking about the first time I read that. Now I get it. So we're going to log in to a service. So in with DBSC present the after the user authenticates themselves with a browser on a device, there is now a new API that causes the devices DBSC public key to be sent to the remote server, to the website server. So, so as part of the user default authentication on the device, the DBSC public key is sent to the remote server. That's what it uses then to re authenticate the user whenever necessary. And we also now need to think of not just a web server but but an authentication side of the server that is there sort of an asynchronous separate authenticator on the website that that is running adjacent to the regular website. So, so what happens then is the the website tells the browser you need to give, you need to have session cookies and you're not sending me any session cookies. So the browser then queries this new authenticating portion of the site through an API and says I need updated session cookies, please challenge me. So that authenticating side sends a random blob to the browser. The browser uses the systems tpm, the trusted platform module that maintains a private key that never leaves, that cannot leave to sign that challenge. The blob is the challenge that has never existed before, never exist again and it just be an always increasing random number. Doesn't matter, just has to be unique. And that's a good way to get it unique. It signs it and sends it back signed. So that proves to the authenticating portion, this DBSC authenticating portion that it's still in communication. This browser is on the device that originally logged in because that's the only way that it could sign a challenge using the private key that exists only on that device and having performed that successfully performed that cryptographic challenge, that authenticating portion. The new authenticating portion of the website then sends new fresh but short lived session cookies, old school cookies to the browser which the browser then returns to the regular website saying hey look it's me and I've just reproven who I am. And so the website says oh good, okay, now we can proceed. So and that's where in what I just read it said if these cookies are not present, DBSC will hold network requests, meaning keep them pending, like not answer them, while querying the configured endpoint for updated cookies. So it goes through all that to get the updated cookies, then it's able to provide them and we proceed. So they wrote DBSC's goal is to reduce session theft by offering an alternative to long lived cookie bearer tokens. That's what we've always had up until now that allows session authentication that is bound to the user's device. This makes the Internet safer for users and that it is less likely their identity is abused since malware is forced to act locally and thus becomes easier to detect and mitigate. At the same time, the goal is to disrupt the cookie theft ecosystem and force it to adapt to new protections. DBSC's primary threat model is that of an attacker who can read and tamper with the user agent, such as with a malware compromised browser or like for example bad extensions in your browser in which the malware can read and modify browser memory and secrets stored on disk. In many operating systems, malware may be able to obtain privileged root, kernel, etc. Access. DBSC aims to address this threat by establishing a cryptographic protocol in which secrets can be stored in dedicated systems such as secure enclaves, though DBSC does not specify how implementers should store backup or sync keys, as long as such storage is robust against the described threat. As a secondary consideration, DBSC also mitigates against certain types of network and server compromise, such as network attackers in the middle, where an attacker can read or modify network traffic, or HTTP server log leaks, where a server mistakenly logs full HTTP request and response headers to logs which can be read by unprivileged insiders. And of course, if they had full headers, they would be seeing the cookies that are being transacted. In all of these scenarios, DBSC aims to enforce the specific constraint that temporary read write access to a user agent or network traffic does not enable long lived access to any established DBSC sessions. For example, if an attacker has malware running within a victim browser process, they should be unable to continue to authenticate as the victim browser once that malware has been removed. Note, however, that the definition of long lived depends upon the configuration refresh period. Within that period, attackers may continue to have short lived access to any established sessions. And the reason for that is we're still using cookies. And the reason we're still using cookies is that it's still too expensive to use this crypto all the time. I mean it's important to understand what an insane number of queries our browsers are generating. I mean it's just a flood of queries coming out of our browsers. They cannot be each individually cryptographically authenticated every time. It's still too expensive. So the idea is we're going to compromise. We're going to, we're going to be able to periodically re authenticate short life cookies. And importantly, before something critical is done, like acknowledging a funding transfer or confirming a purchase or something, it's absolutely practical to ask for an updated reconfirmation of the device's authentication. So on an interactive level we certainly have the speed to do that. And so, so a compromise has been necessary. The previous approaches to replace cookies for binding sessions have failed because they were unwilling to make a compromise and it's just too expensive. So this is a nice solution. And the other important aspect of this is that most of the website doesn't need to change. Most of the website, all of the website that is not about dbsc, it just sees session cookies. So it's got everything it's always had. We're only adding a new authentication slice to the overall site. So they said what are the non goals? DBSC will not prevent temporary access to any browser sessions while the attacker has ongoing access to a compromised user agent. Right, because we're still, you know, we're still using cookies but not long an attacker with ongoing access to a compromised user agent or decrypting middlebox etc. Will be able to continuously access fresh DBSC controlled bearer tokens cookies. And an attacker with malware running on a compromised device will on many modern operating systems be able to treat even secure elements as assigning Oracle, meaning able to get it to sign for on their behalf in order to provide proof of possession of the DBSC secret keys. So again they've as, as do all modern security protocols. They clearly outline these are the things we do, these are the things we, we know we don't do and we're not, we're not claiming to be able to do everything. So they said so what makes device bound session credentials different? And they wrote DBSC is not the first proposal towards these goals with a notable one being token binding. This proposal offers two important features that we believe makes it easier to deploy than previous proposals. DBSC provides application level binding and browser initiated refreshes that can make sure devices are still bound to the original device. For websites, device binding is Most useful for securing authenticated sessions for users, DBSC allows websites to closely couple the setup of bound sessions with user sign in mechanisms, makes session and key lifetimes explicit and controllable, and allows servers to design infrastructure that places verification of session credentials close to where user credentials cookies are processed in their infrastructure. Other proposals have explored lower level APIs for websites to create and use protected private keys, for example via web crypto or APIs similar to WebAuthn. While this works in theory, it puts a very large burden on the website to integrate with. In particular, since the cost of using protected keys is high, websites must design some infrastructure for collecting signatures only as often as needed. This means either high touch integrations where the keys are only used to protect sensitive operations like making a purchase, or a general ability to divert arbitrary requests to some endpoint that collects and verifies a signature, then retries the original request. The former doesn't protect the whole session and violates the principle of secure by default, while the latter can be prohibitively expensive for large websites built from current multiple components by multiple teams and may require non trivial rewrites of web and RPC frameworks. Finally, they said DBSC instead allows a website to consolidate the session binding to a few points at sign in it informs the browser that a session starts which triggers the key creation. It then instructs the browser that any time a request is made while that session is active, the browser should ensure the presence of certain cookies. The browser does this by calling a dedicated refresh endpoint specified by the website whenever such cookies are needed, presenting that endpoint with a proof of possession of the private key. That endpoint, in turn, using existing standard set cookie headers, provides the browser with short term cookies needed to make other requests. Okay, so again we there we finally get some sense for what's going on. Many previous efforts, as I said, to replace cookies have been proposed. None have taken hold. This one demonstrates a carefully crafted compromise. Rather than constantly and continually using expensive public key crypto to prove its identity, DBSC sets up a secondary essentially a cookie supplier for a website. The website tells the browser which cookies it needs to be providing. If the browser doesn't have those, or if they're near expiring, then and only then it separately connects to the cookie supplier where it uses rigorous state of the art crypto to authenticate its device. Not its browser, not its user, its device to the hardware. I mean the device's hardware to the website's cookie supplier. Having done so, the cookie supplier returns regular old fashioned cookies which the browser will then use when subsequently transacting with the main website's pages. The explainer continues saying this provides two important benefits. First, session binding logic is consolidated in the sign in mechanism and the new dedicated refresh endpoint point. All other parts of the website continue to see cookies as their only authentication credentials. The only difference is that those cookies are now short lived. This allows deployment on complex existing setups, often with no changes to non auth related endpoints. And second, if a browser is about to make a request where it has been instructed to include such a cookie but doesn't have one, it defers making that request until the refresh is done. While this may add latency to such cases, it also means non auth endpoints do not need to tolerate unauthenticated requests or respond with any kind of retry logic or redirects. This again allows deployment with minimal changes to existing endpoints, they said. Note that the latency introduced by deferring of requests can be mitigated by the browser in other ways, which will be discussed later. And interestingly, under TPM considerations, you know Trusted Platform module, they wrote DBSC depends on user devices having a way of signing challenges while protecting private keys from exfiltration by malware. This usually means the browser needs to have access to a trusted platform module on the device which is not always available. Tpms also have a reputation for having high latency, meaning they're not fast and not being dependable. Having a TPM is a requirement for installing Windows 11 and can be available on previous versions. All our studies are for public key cryptography using Elliptic Curve DSA P256 algorithm. Chrome has done studies to understand TPM availability to understand the feasibility of secure sessions. Current Data shows about 66.0percent and currently growing of Windows users would be offered protections. Studies have also been done on the current populations of TPMs both for latency and predictability. Currently the latency for Signing operations averages 200 milliseconds, so 1/5 of a second with only 5% of signing operations exceedingly 600 milliseconds and the error rate is very low, currently around 0.001% and you if you got an error you just retry. Based on this research, tpms are widely available with a latency and consistency that is acceptable for the proposed usage. And as we know tpms of the future, having some some crypto engine as part of every device is absolutely the future. So the spec is here, we already have 60% coverage and that's Only going to be going up over time. So they ask what about privacy considerations? They said an important high level goal of this protocol is to introduce no additional surface for user tracking. Implementing this API for a browser or enabling it for a website should not entail any significant user privacy trade offs. There are a few obvious considerations to ensure we achieve that goal. Lifetime of a session and key material. This should provide no additional client data storage, for example a pseudo cookie. As such, we require that browsers must clear sessions and keys when clearing other site data like cookies. So like no DBSC residual will will outlive cookie life. Cross site cross origin data leakage. It should be impossible for a site to use this API to circumvent the same origin policy and similar cookie policy. Implementing this API should not meaningful increase the entropy of heuristic device fingerprinting signals. Right? So you're not there. I mean they're, they're, they're designing this very much with the state of the art of privacy in mind. This API, which allows background pings to the refresh endpoint when the user is not directly active, must not enable long term tracking of a user when they've navigated away from the connected site. That's a very good point because there is a new communications protocol set up between the browser and the refresh endpoint to obtain updated cookies. But that only needs to be happening while the user is actively looking at that tab on that site. Each session has a separate new key created and it should not be possible to detect that different sessions are from the same device. So the keys are all isolated. Registration and refresh will only be performed over a secure connection or with localhost for testing, they said. To achieve these goals, we add the following constraints to DBSC requests. Registration and refresh are made in the context of the request that triggered them. For registration, this is the request serving the SEC session registration header. For refresh, this is the request referred deferred due to missing cookies. They said cookie refresh only occurs if the cookie is accessible. DBSC will not attempt to refresh a third party cookie if the third party cookies are blocked. And proactive refreshes must only occur if any tab has a page from the site currently loaded. And then lastly, while DBSC addresses a general problem of session hijacking and can be applicable to any browser consumer, it is possible to expand this protocol to better support enterprise use cases. By adding specifics to key generation, we can provide a more secure environment for enterprise users. This is the goal of DBS ce, which is an extension to dbsc. The high level design of DBS CE is described in the DBS CE overview. DBSCE removes the vulnerability DBS C has where a malware, if already present in the device during the key generation, can potentially take over a session. DBSCE proposes to mitigate this vulnerability by introducing device key chaining okay, so I am fully aware that what we've just done was a lot to digest and we're at the at, you know, at the end of a lengthy podcast with no time to dig further into this, but at least the essence of this new system is probably now clear. Cookies still exist, but they are short lived rather than persisting as they often do these days, essentially forever. I mean, I can't remember the last time I logged into many services that I use every day or two. They are staying current as cookies near what will now be their shorter end of life. The browser will be able to ping a website a newly defined website endpoint, meaning you know, something that is is part of the specification where it'll be, you know, some some.name directory off of the root where there where a specific service newly defined service will always be available. If DBSC is supported, the browser will be able to ping that at any time separately in order to obtain a refresh of the cookies that are that are about to be expiring and at that time re authenticate its device to that remote site. So to do this, that authenticating endpoint will send a cryptographic challenge that the browser must sign and return, and the browser can only do so using an unexportable private key that's buried in the hardware of the device that the browser is running on top of, the only thing that can be done with that key is signing cryptographic challenges to prove that the device has the key. Once the browser returns the challenge properly signed, the cookie provider will refresh the cookies for the domain and the browser will then continue to be able to use the original website without trouble. The cleverness of this solution is that it minimizes the changes that are required for the rest of the website by concentrating the new authentication scheme in one location and by using shorter lifetime old school cookies, it achieves compatibility with existing systems while also using the cookies as a as a shorm as a form of short term identity cash so that the system's far far slower crypto hardware is not overwhelmed and is only needed to occasionally refresh the cookies. Chrome, Firefox and Safari are all have all added support for device bound session credentials to their web browser offerings. So now People, websites, researchers can begin experimenting with this and start bringing this on board. And I'm sure we'll be talking about this more in the future.
