Re: stored credentials was: Netscape 4.5 vulnerability

[jogata () NODC NOAA GOV (Jefferson Ogata)]

What if the OS itself maintains a database of randomized encryption keys,
and allows access to a key only to a binary whose inode and filesystem
matches the one under which the key was stored. I'm being needlessly
specific here, but I lack the vocabulary to describe this in more general
terms.

Here's a specific example. Netscape asks the OS for an encryption key via
a system call. The kernel looks at the Netscape binary that made the
system call and makes a database key from its filesystem and inode. It then
checks in a private database for a record under that key. If the record is
found, its value is returned to Netscape. If no record is found, the kernel
generates a new random value, stores it in the database, and returns it to
Netscape. Netscape then uses the random value to encrypt/decrypt the user's
password for storage in prefs.js.

The encryption key then can only be retrieved by a user that can arrange
that its own program have the filesystem.inode under which a key was stored,
i.e. the owner of the directory where the binary is located, or root. Root
could also just pull the key directly out of the database.

I guess the original topic of discussion was the feasibility of a system
that not even root could subvert. This doesn't qualify, but it does allow
programs to save encrypted passwords that can be decrypted only by the
program that stored them (or root) in a publically readable file. And I'm
sure there's something fundamentally flawed about it, because I'm not a
cryptography expert. I suppose it's not unlike using the Windows registry
to store a key generated by the program....? I suppose also that there are
ways to do this without adding a system call.

Another alternative would be to use a cryptographic signature of the
binary as the database key. This would make the system more tolerant of
a binary being relocated or restored from backup tape.

Any thoughts? Flames?

Juha Jäykkä wrote:
> > Well actually you can use one key/passphrase to secure all the stored
> > credentials. This has the advantage that you dont need to rember all
> > credential (which is impossible for secret keys anyway). But it has the
> > disadvantage, that the security is
> > a) breakable by trojans/backdooring
> > b) as secure as the (weakest) manual entered passwort
>
>   No, no, no. You missed the point. We were discussing programs (or
> bunches of programs or even OSes) which store user credentials for later
> access WITHOUT the need for a user to supply any password, key or
> credential. Such as is implemented in netscape communicator when it
> stores pop/imap passwords in prefs.js. In this case the credentials
> stored by the program are indeed "encrypted" (XORed) but in order to
> enable the program to retrieve this information without user interaction
> even after a system restart, the password used to "encrypt" the
> credentials is stored somewhere within the binary itself, the windows
> registry or even derived from the user name or something. Which ever the
> method, the password is easily reproduced and used to decrypt the
> credentials protected with it. There is no way around this when we want
> to access the encrypted credential information without user interaction
> (to be precise I should add: after a system restart). There can never be
> true security in such a system. End of story.
>   What you propose is basically a Single-SignOn technique which still
> needs ONE passphrase. They are a totally different story and not the
> subject here.
>
> --
> Juha Jäykkä, juhaj () iki fi
> PS See http://www.dcs.ex.ac.uk/~aba/rsa/ for latest version of RSA in
> perl.
> Here goes the RSA code in two lines:
> print pack"C*",split/\D+/,`echo
> "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

--
Jefferson Ogata <jogata () nodc noaa gov> National Oceanographic Data Center
You can't step into the same river twice. -- Herakleitos