[Cryptography] Usable Security Based On Sufficient Endpoint-Specific Unpredictability

[Natanael]

Den 11 okt 2015 17:32 skrev "Ralf Senderek" <crypto at senderek.ie>:
>
> I am about to secure secret information using a "password" that can be
> produced by a process on the user's endpoint device with administrative
> *execute privilege* instead of using some information from the user's
> brain. The idea is that a malware running on the user's behalf would not
> be able to produce this password unless it has execute permission as the
> root user.

Privileged services doing key management is already a thing. The idea
behind it isn't all too crazy.

> Malware that has got read access as the root user could read any file or
> information on the endpoint device, but as the production of the password
> requires execute permission, all secret information secured with this
> password is still safe until execute permission is gained.

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.

Also note that all unpredictability (computational entropy) used must be
considered part of your secret keys.

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.

> Everything short of running code as root should not compromise the
protected
> information. If such a secret-producing process existed it would be a
> substitution for user provided passwords and would increase the usability
> of crypto considerably.

There's something *almost* the same: https://en.wikipedia.org/wiki/TRESOR

This uses hardware features in the CPU to restrict what software can access
the secrets.

> In all cases in which the OS provides a properly secured admin account,
> and in which the installation of the OS has produced a sufficient amount
> of unpredictability, pieces of information can be collected by such a
process
> that are unavailable even to malware that has read access to the device
as root.

How would it be made unavailable? Like with TRESOR above? SELinux
isolation?

> I exclude everything that's stored in a file and anything that is prone to
> change. But to the best of my knowledge, the inode numbers of specific
files
> cannot be read directly by a process with read access only. These inode
> numbers are far from being random but they contain enough
unpredictability to
> construct a password that is as secure as anything a user could provide by
> picking her brain in the traditional way.

Accessible by root. Doesn't work. See comments above.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20151011/eb79764f/attachment.html>