Login functionality

Raymond Causton raymond at causton.net
Sun Feb 22 11:21:25 PST 2004


> You state the obvious but make no point.  Public key 
> encryption is a very poor choice for logs (or bulk encryption 

Well, I'll have to chip in my two cents - I totally aggree that RSA/public
key cryptography is way too computationally intensive and a bad choise for
BULK data encryption. 

The point of this thread however was to log failed usernames into
/var/log/auth.log's failure messages and thereby enable the adminstrators to
profile possible intrusion attempts to screen out just typical CAPS-LOCK,
etc, errors. 

So with a modified login, which either 

1) encrypts selectively just the loginname that is subsequently echoed to
the log-file directly with the designated RSA/PGP public key. This (abt. 8
chars / failed login attempt) doesn't amount to a very big bulk of data as
the general log-file is still plaintext as always. E.g.
E_public_key(loginname) -> echo to log-file

In this case to read the log-files in plain text the administrator should
have his RSA_private_key available to decipher the ciphered parts of the
log-file. This might pose a slight problem in building a parser to find the
encrypted parts of the log-lines, but it doable I think. 

This isn't a very usefull operations mode if the RSA private key is stored
on a token e.g. a smartcard as they are way too slow to do multiple
deciphering computations and require the PIN-code to be entered every
log-line that needs to be deciphered.

2) If someone wants to have entirely encrypted log-files the RSA/public key
can be used to encrypt the "session key" for this rotation of the log-file
and encrypt the entire logfile with say AES-256 using this machine generated
key that is appended to that logfile in encrypted form for future analysis -
e.g. E_AES_encryption_key(log-file)+Append(E_RSA_public_key(encryption_key))

To read this kind of log-file the administrator must possess the
RSA_private_key to extract the AES_encryption_key from the appended
RSA-encrypted "key-safe" to feed that key to the AES-decipher to read the
log-files.

This is a much usable mode of operation when working with smartcards as you
need to provide the PIN-code only once to retrieve the AES_encryption_key
and then you can use this to decipher the logs with much faster
en/decryption speeds.

I'm sure some sort of a hybrid scheme of these two extremes could be
developed to achieve a good solution to this little problem - something
along the lines like 

3) encrypt only the failed login-names with an per-log-rotation AES-key that
is enciphered with a RSA-key and appended/prefixed to the plaintext/ciphered
login-names log-file maybe MIME-coded so that it can be sent to a central
log-server in ASCII.

This will sort of have best of both worlds as the en/decryption is fast and
the RSA-key needs to be used only once when beginning to read the file. 

With this sort of a scheme you can throw pretty much as much data at the
logger and still not be much wiser about the encryption keys.

Here we have to notice though that whenever the server boots or syslog is
restarted it has to rotate the logfiles as the server can only use the
encryption key for as long as it's stored in memory as it cannot decipher
the key out of the RSA-encrypted container. 

Cheers,

	Raymond





More information about the hlfs-dev mailing list