<p dir="ltr">Den 11 okt 2015 17:32 skrev "Ralf Senderek" <<a href="mailto:crypto@senderek.ie">crypto@senderek.ie</a>>:<br>
><br>
> I am about to secure secret information using a "password" that can be<br>
> produced by a process on the user's endpoint device with administrative<br>
> *execute privilege* instead of using some information from the user's<br>
> brain. The idea is that a malware running on the user's behalf would not<br>
> be able to produce this password unless it has execute permission as the<br>
> root user.</p>
<p dir="ltr">Privileged services doing key management is already a thing. The idea behind it isn't all too crazy. </p>
<p dir="ltr">> Malware that has got read access as the root user could read any file or<br>
> information on the endpoint device, but as the production of the password<br>
> requires execute permission, all secret information secured with this<br>
> password is still safe until execute permission is gained.</p>
<p dir="ltr">Nope, impossible. With access to all secrets, there's no capabilities the malware lacks as it runs in a Turing complete environment. If the malware is executing as the user and also has all of the secrets, you're screwed.</p>
<p dir="ltr">Also note that all unpredictability (computational entropy) used must be considered part of your secret keys. </p>
<p dir="ltr">The only exception is if the credentials is only useful when controlling local hardware that only root can control, but that userspace software can not send commands to (such as some PCIe devices if the OS is configured properly). But if you're talking about encryption/decryption or online services, it can't be done. </p>
<p dir="ltr">> Everything short of running code as root should not compromise the protected<br>
> information. If such a secret-producing process existed it would be a<br>
> substitution for user provided passwords and would increase the usability<br>
> of crypto considerably.</p>
<p dir="ltr">There's something *almost* the same: <a href="https://en.wikipedia.org/wiki/TRESOR">https://en.wikipedia.org/wiki/TRESOR</a></p>
<p dir="ltr">This uses hardware features in the CPU to restrict what software can access the secrets. </p>
<p dir="ltr">> In all cases in which the OS provides a properly secured admin account,<br>
> and in which the installation of the OS has produced a sufficient amount<br>
> of unpredictability, pieces of information can be collected by such a process<br>
> that are unavailable even to malware that has read access to the device as root.</p>
<p dir="ltr">How would it be made unavailable? Like with TRESOR above? SELinux isolation? </p>
<p dir="ltr">> I exclude everything that's stored in a file and anything that is prone to<br>
> change. But to the best of my knowledge, the inode numbers of specific files<br>
> cannot be read directly by a process with read access only. These inode<br>
> numbers are far from being random but they contain enough unpredictability to<br>
> construct a password that is as secure as anything a user could provide by<br>
> picking her brain in the traditional way.</p>
<p dir="ltr">Accessible by root. Doesn't work. See comments above. </p>