Chrome's bug tracker is for reporting security vulnerabilities in Chrome; questions about Chrome can be filed in the discussion forums. In general, we don't make product feature announcements in bugs.

I'm not aware of any plans to change Chrome's encryption posture here, but I'm also unconvinced that using a hardware backed keystore would make any real difference here. On a rooted device, the attacker can simply read the secrets out of Chrome's process memory and achieve the same effect.

Nevertheless, in the interest of allowing others to see this, reclassifying as a feature request to allow an appropriate owner to answer your question.

Thanks a lot for your response!

Atleast, the symmetric key stored in hardware-backed keystore cannot be read from Chrome's process memory, because the key never leaves the TEE,
 which runs on a different processor(https://source.android.com/security/trusty/). Once the cookies are decrypted and given back to Chrome process, then it is possible to extract the cookies from Chrome's process memory.

But, given that Hardward backed keystore is present and Chrome has support for encrypting cookies in other platforms, could anyone please give a proper explanation as to why this feature is not being implemented?

> the symmetric key stored in hardware-backed keystore cannot
> be read from Chrome's process memory

An attacker has no interest in the symmetric key, he wants to steal the data that was encrypted by the symmetric key. Putting a symmetric key into a hardware lock box would not increase security at all, because the key can be freely used by the (compromised) process.

Thanks a lot again for your reply!!!

With all due respect, I would like to disagree with your statements:
1. >"An attacker has no interest in the symmetric key, he wants to steal the data that was encrypted by the symmetric key. "
Yes, the attacker is definitely interested in the data which is encrypted. So, the attacker is also interested in the symmetric key with which he will be able to decrypt the encrypted data. I am referring to the Law # 7 in https://technet.microsoft.com/en-us/library/hh278941.aspx which is in turn referred from https://chromium.googlesource.com/chromium/src/+/master/docs/security/faq.md#Why-arent-compromised_infected-machines-in-Chromes-threat-model:
'Law #7: Encrypted data is only as secure as its decryption key.'

2. >"Putting a symmetric key into a hardware lock box would not increase security at all, because the key can be freely used by the (compromised) process."
Hardware lock box by design is for increasing security. The compromised process will not have access to the TEE as it runs on a different processor. I know that there can sophisticated attack scenarios in TEE at the embedded layer. But, they have to be addressed by the corresponding team separately.

Hi,
Regarding your initial reply:
>"Nevertheless, in the interest of allowing others to see this, reclassifying as a feature request to allow an appropriate owner to answer your question."

Could you please ask the appropriate owner to have a look at my request and reply as soon as possible?

Thanks a lot!!!

Also, I posted on Chrome discussion forum based on your reply:
>questions about Chrome can be filed in the discussion forums.

Post: https://productforums.google.com/forum/#!topic/chrome/P9JaA6OSmmI;context-place=forum/chrome 

I *love* Microsoft's Ten Immutable Laws of Security. In particular, I draw your attention to the first two, which are the relevant ones here:

Law #1: If a bad guy can persuade you to run his program on your computer, it's not solely your computer anymore.
Law #2: If a bad guy can alter the operating system on your computer, it's not your computer anymore.

Rooting a device means that the operating system on your computer has been altered. Running a malicious app means that a bad guy has persuaded you to run his program on your computer.

> Yes, the attacker is definitely interested in the data which is encrypted

I'm glad we agree that the attacker is only interested in the protected data, and he's only interested in an encryption key if he *needs* it to read the protected data.

Perhaps I can make this more understandable with an analogy.

  1. Alice has a bunch of secrets written down on a piece of paper. 
  2. Alice wants to protect them from anyone else reading them.
  3. Alice buys a lockbox to put the password paper in. 
  4. Alice locks the lockbox with a KEY.
  5. Alice gives the KEY to Walter, a heavily-armed Navy SEAL, with instructions to open the safe using the KEY immediately any time she asks.
  6. Alice further instructs Walter not to give the KEY to anyone, including herself, ever, under any circumstances.

Now, Alice is confident that no one except her can get at the passwords. 

Why is she wrong?

  7. Craig, an attacker, wants Alice's passwords.
  8. He takes one look at Walter and says "uh, no, I'm never going to be able to steal that key from him." 
  9. Craig learns hypnosis.
  10. Craig hypnotizes Alice and directs her to follow his instructions.
  11. Craig instructs Alice to tell Walter to open the box.
  12. Alice tells Walter to unlock the box.
  13. Walter unlocks the box.
  14. Craig tells Alice to take the password paper out of the box and give it to him.
  15. Alice gives the password list to Craig.

At no point did Craig get access to the KEY, which is still safely held by Walter. Instead, he simply stole what he cared about, the password list, by taking control of Alice.

In this scenario, step #9 is where the device is rooted, and step #10 is when the malicious process injects its code into the Chrome process.

Thanks a lot once again! 

I understood your point. But, sensitive data at rest should be encrypted as a good security practice. I believe that's the reason why cookies stored in db are encrypted in some platforms by Chrome. 

I also understand that as per the threat model which Chrome has, compromised devices are not supported. But, I would be really grateful if I could get an answer from the concerned person if this security feature will be implemented in a future release or not. 

> sensitive data at rest should be encrypted as a good security practice.

Sure. https://source.android.com/security/encryption/full-disk

Ok, I agree to that as well :)

One final query as asked before:
I would be really grateful if I could get an answer from the concerned person if this security feature will be implemented in a future release or not. 

Hi,
Any update on my last comment? It will be really helpful.
Thanks!

When there's an update, you'll receive a notification by email.

 Issue 847090  has been merged into this issue.