ssh-decrypt

[Pawel Krupinski]

Hi,
 
One of the problems we are facing is secure storage of
passwords (database, bestcrypt, other
applications/systems, 
) and availability within
users' scripts (perl, python, ...) or applications
(Java, C, 
). I'm sure that there are quite a few
people who are facing the same issue and there are
quite a few home made solutions, such as password
obfuscators and/or solutions based on the access
control lists. 
 
As OpenSSH is currently a standard for us, I have an
idea how to solve this problem without introducing
other products or implementing home made solutions.
Instead I would like to use the ssh agent. 
 
I'm using ssh agent currently just to manage my keys
and practically they are used only to provide me with
SSO to other ssh based systems. Why not use these keys
(or a separate ssh key pair) to protect passwords to
things such as database? 
 
To put it simple the way I see it is as follow. Your
passwords (apart from your main ssh password) will be
stored encrypted using your ssh public key. After
logon, ssh-agent will be started and relevant key(s)
added. When a script will require access to a
password, it will:
1. Retrieve the data from somewhere (outside the
scope);
2. Decrypt using the ssh utlity (ssh-decrypt(?)) -
using ssh-agent or a file.
3. Provide credentials back to script. Or will create
the establised connection to the database. Or

(anyway, I think it is outside the scope ;-)).
 
The bit that cannot be done currently is number 2 -
OpenSSH doesn't provide ssh-decrypt functionality, but
it is relatively easy to change it - I've played with
OpenSSH 4.4/4.4p1 and it took me one evening (sorry -
it was my first approach to OpenSSH as a developer
;-)) and 50 lines of code to implement it (based on
the ssh-add tool using ssh-agent for decryption). In
my solution, ssh-decrypt tool sends encrypted secret
to the ssh-agent, which decrypts it (without sending
any keys to the ssh-decrypt tool) and sends back just
an error information or the plaintext password. 
 
>From the cryptography perspective this approach would
be definitely better than password obfuscation and if
someone wants he may still implement whatever access
control lists he wants, but even root access won't
automatically give you access to users' keys. You need
to:
1. Obtain encrypted key material;
2. Have access to user's ssh private key - so access
to a file + passphrase is required (eventually ability
to talk to the ssh-agent, so root account)
I don't think it would weakened ssh-agent. If I'm
wrong, please let me know.
 
If it is something of interest for you, I can do all
the development and provide you with all the code.
 
Comments and feedback welcome,
 
Cheers,
pak76
 
PS1. Above I'm talking about passwords, but as a
matter of fact it can be anything that can be saved as
a string. Of course RSA puts limits on the data that
can be encrypted, so probably scenario: secrets
encrypted with a symmetric cipher, a symmetric key
encrypted with the public key is more applicable.
Again this is outside the scope - whichever project
will be building SSH-SAFE will have to deal with this.
PS 2. Just to clarify - I suggest the ssh-decrypt
name, as ability to decrypt encrypted data using
private key - either from file or ssh-agent - is
crucial. Encryption can be done without ssh-agent -
public key is not a secret. 
PS3. It is not a problem to setup two pairs of keys -
one for authentication and one for password
encryption/decryption.
PS4. Depending on individual requirements
(authentication/authorization/accountability/scalability/
)
different groups may use ssh-decrypt for different
purpose - password safe is just one of the examples.
It maybe a good idea for a separate project (or even
several projects :-)).


		
___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com