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ä, juhajat_private > 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 <jogataat_private> National Oceanographic Data Center You can't step into the same river twice. -- Herakleitos
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:43:48 PDT