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

Ralf Senderek crypto at senderek.ie
Sun Oct 11 06:32:48 EDT 2015


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.

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.

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.

I'd like to hammer out an idea for such a process.

It's clear to me that such a process wouldn't work on all devices let alone
all operating systems. Unfortunately it wouldn't work on the Crypto Bone,
because people would restore their system from a common image file.
In any case where systems are being cloned, this is not an option, but on
the user's individual OS installation it should work.

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.

I presume that root read access is a realistic threat on a user's endpoint
device due to the exploitation of the complexities of modern OSes by network
attackers without physical access to the device (heartbleed). And I presume
that getting code run as root is considerably more difficult than getting
read access, or in other words, in this case nothing can be done to save
the information stored on the device at all.

So, where will we find the necessary unpredictability to construct a secret
that is inaccessible to anyone not being able to run code as root?

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.

My Fedora informs me that the inode numbers of files like /root/.rnd that
live inside a directory with 700 permission differ from the parent directory's
inode number quite a bit. One should not over-estimate the unpredictability
stored in the inode number as they are allocated sequentially to new files,
but conservatively guessing there will be at least 5 bits of unpredictability
in each of them.

So imagine in a certain OS there are say 5 such files (A-E). There are 5!
permutations of their inode numbers in concatenation that each would
make up a weak password if the sequence was known in advance. But if a sixth
inode number, unknown to the attacker, defines the sequence that's actually
used the resulting string piped through a bcrypt hash function should be
secure enough to replace a user provided password.

In fact some *NIXes provide very few such files, so it might be a better idea
to generate a directory structure for this purpose by creating a random number
of files to eat up inode numbers and then pick files you need and delete
all the temporary files again. This way the unpredictability of the left-over
files can be increased way above 5 bits.

For the process that deterministically computes the local secret the
unpredictability of the result is clearly zero, but for any network attacker
it should be sufficiently high to reliably protect secret information
bound to using that specific device by an ordinary user.


      --ralf


More information about the cryptography mailing list