Tom Proett <[EMAIL PROTECTED]> writes:
> Is it useful without lsh_writekey? That is, would it be reasonable to
> do something like "lsh_keygen > keypair" and store the SPKI s-expressions
> in a raw form?
lsh_keygen generates a key including the private information. So
redirecting it to a file directly, like above, may be a security
problem. But of course, that depends on the application of the key and
other circumstances.
For instance, private host keys are usually stored without any
encryption (/etc/ssh_host_key, for ssh). I think this is reasonable
(as long as it is readable for root only): A compromise of the key
will anable an attacker to mount a man-in-the-middle attack on the ssh
protocol. But if the attacker has already been able to read a root
only file on the target system, the possibility of a MITM attack is a
comparatively minor problem (this is not necessarily true, but I think
it is how ssh:s use of unencrypted host keys is justified).
> Would doing the above be a security problem?
For more sensitive keys (for instance keys used for granting login
access; i.e. ~/.ssh/identity and ~/.ssh/authorized_keys), the normal
mode of operation will be to *pipe* the output from lsh_keygen
directly into lsh_writekey or some other program which stores the key
securely. I don't think the pipe is weaker than the rest of the
system; if an attacker can read the pipe, he can most likely read
kernel memory or attach a debugger to one of the involved processes,
and we lose anyway.
For high security you might run lsh_keygen on a personal machine in a
locked room without any network connection, and pipe it into a program
that downloads the key into a smartcard or something like that.
> Unless the answers to the these are "YES" and "NO", I think splitting the
> functionality into two programs might be a mistake. I understand you
> are going for the unix philosophy, but if there is a conflict between that
> and good security, I think security must win.
As far as I can tell, there's no conflict in this particular case.
Another note on security: lsh does not attempt to store secret keys
into special locked unswappable memory pages or anything like that.
That is also a deliberate decision. I think that it can be a real
security problem that sensitive data is written out to a swap
partition. However, I don't see any satisfactory solution on the
application level.
It might be possible, although quite painful, to hack lsh to allocate
data that it *knows* is sensitive in "secure" unswappable memory (GNU
Privacy Guard does it). But that doesn't solve the problem, and the
reason is quite simple: lsh can't know for sure whether or not some
piece of information is sensitive. In fact, it seems quite likely that
the data processed by lsh is sensitive as well, and should be
protected... (Say, I write some sensitive data into a temporary emacs
buffer, and then send it to another machine by running
shell-command-on-region and lsh. Or I do lsh_keygen | lsh some.host
lsh_writekey).
On the other hand, I think it would be fairly straight forward to
implemente encrypted swap at the OS level, and that this would solve
the problem of sensitive information leaking onto the swap, for *all*
applications that handle sensitive data, including standard utilities
such as, say, sed.
The idea is to have the kernel choose a random key when each process
is created (this feature could be enabled on a per user or per process
bases, or by some environment variable). Data pages (except perhaps
shared pages) should be encrypted with this key when swapped out, and
decrypted when read back into core. When the process dies, the key is
destroyed. Note that the key management issues are trivial in
comparison with things like encrypted file systems.
Regards,
/Niels
