From 412f740b668af0400dfe8766b7f46cae3638f5ee Mon Sep 17 00:00:00 2001 From: wj25czxj47bu6q Date: Thu, 25 Apr 2024 10:36:51 +0000 Subject: [PATCH] Update ChromeOS Questionable Encryption --- .../google-login.jpg | Bin .../ChromeOS Questionable Encryption/index.md | 28 ++++++++++++++++++ .../linux/ChromeOS Questionable Encryption.md | 26 ---------------- 3 files changed, 28 insertions(+), 26 deletions(-) rename {static/images => content/posts/knowledge/ChromeOS Questionable Encryption}/google-login.jpg (100%) create mode 100644 content/posts/knowledge/ChromeOS Questionable Encryption/index.md delete mode 100644 content/posts/linux/ChromeOS Questionable Encryption.md diff --git a/static/images/google-login.jpg b/content/posts/knowledge/ChromeOS Questionable Encryption/google-login.jpg similarity index 100% rename from static/images/google-login.jpg rename to content/posts/knowledge/ChromeOS Questionable Encryption/google-login.jpg diff --git a/content/posts/knowledge/ChromeOS Questionable Encryption/index.md b/content/posts/knowledge/ChromeOS Questionable Encryption/index.md new file mode 100644 index 0000000..024d3c0 --- /dev/null +++ b/content/posts/knowledge/ChromeOS Questionable Encryption/index.md @@ -0,0 +1,28 @@ +--- +title: "ChromeOS's Questionable Encryption" +date: 2024-04-25 +tags: ['Operating Systems', 'ChromeOS', 'Security'] +author: Tommy +--- + +## Premise + +ChromeOS encrypts user data on the disk by default. The implementation details are [documented upstream]("TPM Usage — The Chromium Projects" https://www.chromium.org/developers/design-documents/tpm-usage/#TOC-Protecting-User-Data-Encryption-Keys) but not relevant within the scope of this post. + +It is well-known that ChromeOS uses Google account passwords as the primary login credentials. This necessarily means that anyone with knowledge of the Google account password is able to unlock and therefore decrypt a ChromeOS user profile. + +## Practical Implications + +The very same Google account passwords used for ChromeOS authentication are also used for logging in to various Google services in web browsers and other apps. After a quick investigation with browser dev tools: + +![Google Login](google-login.jpg) + +…it turns out that passwords are submitted to Google servers in plaintext (see "mygloriouspassword" in the Form Data). As a result, someone with sufficient access to Google's servers would theoretically be able to obtain the actual, unhashed password for a given Google account. It follows that an adversary with physical access would be able to unlock and decrypt ChromeOS user data with cooperation from Google. + +This differs from how encryption passwords are handled by other services like cloud‑based password managers — using _client‑side hashing_. Client‑side hashing is a technique to deliberately blind the server from the actual password. As the name suggests, the browser locally executes a cryptographic hash function on the actual password and only transmits the _resultant hash_ to the server for authentication. + +## Takeaways + +If Google is malicious, coerced by the government, or hacked, their servers can record the user password prior to it being hashed. That password can then be used to gain access to the files on ChromeOS hardware if the adversary gains physical access. + +Just to be clear, this is not a vulnerability. It's just how the system is designed. \ No newline at end of file diff --git a/content/posts/linux/ChromeOS Questionable Encryption.md b/content/posts/linux/ChromeOS Questionable Encryption.md deleted file mode 100644 index 1e2a8f3..0000000 --- a/content/posts/linux/ChromeOS Questionable Encryption.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "ChromeOS's Questionable Encryption" -date: 2024-04-15 -tags: ['Operating Systems', 'Linux', 'ChromeOS', 'Security'] -author: Tommy ---- - -## How ChromeOS Encryption Works - -ChromeOS encrypts user data on the disk by default. The encryption key is protected using a number of factors, which is documented in the [ChromeOS Documentation](https://www.chromium.org/developers/design-documents/tpm-usage/#TOC-Protecting-User-Data-Encryption-Keys). - -The user's Google account password, when typed into a the Chromebook (with the security chip intact - be it the TPM, Titan C, or some other chips), will give the encryption key to unlock their files. As such, for confidentiality, it is important that the user's Google account password is never exposed to an attacker. If the threat model requires protection against Google or an attacker who has compromised their servers, the password should be hashed client side before being sent to Google's server. - -## What Happens in Practice - -I was a bit curious as to whether any client side hashing is done when you log into Google services. I had a quick look at the login page in the browser, and apparently, there is none: - -![Google Login](/images/google-login.jpg) - -As you can see in the screenshot, the login password "mygloriouspassword" is submitted directly to Google's server as part of the payload. - -## What This Means - -This means that if Google is malicious, coerced by the government, or hacked, their servers can record the user password prior to it being hashed. That password can then be used to gain access to the files on the hardware when the attacker gains physical access. - -Just to be clear here, this is not a vulnerability, it's just how the system is designed.