|
| Here's the readme for the initial release of LogCrypt. It can be found here:
http://www.lunkwill.org/logcrypt/
-J
LogCrypt 0.3
Jason Holt <logcrypt@lunkwill.org>
11 July 2003
Released into the public domain
Status:
-------
This is the first public release of LogCrypt. It's designed mostly
to be a proof-of-concept. It's probably not very secure, and might
even have bugs that could make your system less secure. You Have
Been Warned.
Introduction:
-------------
LogCrypt is like Tripwire for logfiles. A secret is established
at log creation time and stored somewhere safe, and changes via a
one-way cryptographic function every time a line is written to the
log. This secret is used to compute a MAC (message authenticaion
code) for each line of the log, and optionally to encrypt the log
as well.
If your system is compromised, the attacker will have no way to
recover the secrets used to create MACs for (or decrypt)
already-written lines of the log. He can delete the log entirely,
but can't modify it without detection. Later, you can use the
original secret to see if your logs are still intact. (For best
security, you should do this on a separate, secure machine).
You could also send the MACs to another machine as they're written.
Then they can serve as commitments to your log entries. So if you're
a doctor, you could send the MACs to an auditing agency. Later, you
could produce your logs in court and the auditor could vouch that
the logs you've presented match the MACs you sent out. But otherwise,
the auditor would have no way of knowing what your log entries were.
John Kelsey and Bruce Schneier wrote a paper about a technique very
similar to this: Minimizing Bandwidth for Remote Access to
Cryptographically Protected Audit Logs. You can find it here:
http://www.counterpane.com/auditlog2.html
Copyrights
----------
logcrypt only links against OpenSSL, so I'm not actually sure whether
the following are necessary. But thanks to the OpenSSL team and
Eric Young for their excellent work on OpenSSL!
This product includes software developed by the OpenSSL Project
for use in the OpenSSL Toolkit (http://www.openssl.org/).
This product includes cryptographic software written by Eric Young
(eay@cryptsoft.com).
Installation:
-------------
Type "make". This should produce two programs, "logcrypt" and
"logread". You can test them by typing "cd tests ; make ; cd ..".
(You may need to set the path to PERL in tests/test.pl).
Feedback:
---------
The amount of work I do on LogCrypt from this point on will
probably be proportional to the amount of feedback I get. If I
don't hear from anyone, I'll assume noone's using it. So let me
know if you do!
Using LogCrypt:
---------------
To keep MACs for an existing log "messages":
$ tail -n 9999999 -f messages | logcrypt >messages.mac
2af5e4e16bd3a26e744e9348432627de6db52640
The line above is the MAC secret, used for verifying log integrity.
Keep it in a safe, secret place. In particular, don't leave it
anywhere unencrypted on this machine. You could write it on a piece
of paper kept somewhere safe, for instance.
Be sure to write down the MAC secret for later verification:
$ logread -i messages.mac <messages
Enter MAC key in hex: 0x2af5e4e16bd3a26e744e9348432627de6db526
40
The log is intact.
What if somebody has altered the log?
$ echo "booga booga" > messages
$ logread -i messages.mac <messages
Enter MAC key in hex: 0x2af5e4e16bd3a26e744e9348432627de6db526
40[QUOTE][color=darkred]
The log appears to have been modified!
You could store the MACs as commitments to your log entries on
another machine. Then you can show them the log later, and they can
verify later that you haven't tampered with it, even though you know
the MAC secret. If you choose not to show them the log, they don't
learn what the log contains:
auditor$ nc -l -p 1337 >logcommitments
client$ tail -n 9999999 -f messages |logcrypt |nc auditor.example.com 1337
(Netcat is, of course, not a secure transport mechanism).
To encrypt the log as well as keeping MACs, use -e:
$ tail -n 9999999 -f messages | logcrypt -e >messages.log
4fbd7e7ea64f2288b251a8e531c1a971fb4d31f4
b0fd3cb7f2205e4baced8d2d4d69b7e5ca70c2bb
a9620d5a
The first line is the MAC secret, used for verifying log integrity.
The second line is the encryption secret, which keeps the logs
confidential. Keep them in a safe, secret place. In particular,
don't leave them anywhere unencrypted on this machine. You could
write them on a piece of paper kept somewhere safe, for instance.
Later you can decrypt. Because logcrypt has forward secrecy, even
if your system has been compromised after you started logcrypt,
the intruder can't modify or read messages.log without your
detection. With some caveats, of course - if you public-key
encrypt the key and keep it in a file, he can replace that file
with a different public-key encrypted key. And of course he may
also be able to fool you into *thinking* that the log checks out,
for instance by modifying your copy of logread. For best results,
keep the key off the system, and do your log verification on a
separate machine as well.
$ ./logread -d <messages.log
Enter MAC key in hex: 0x4fbd7e7ea64f2288b251a8e531c1a971fb4d31
f4
Enter crypt key in hex: 0xb0fd3cb7f2205e4baced8d2d4d69b7e5ca70c2
bba9620d5a
messages line 1...
messages line 2...
etc.
The log is intact.
You can encrypt the MAC secret with your public key instead of
writing it down:
$ tail -n 100000 -f messages | ./logcrypt -s \
"gpg -r LogCrypt -o messageskey.gpg -e" >messages.mac
Later, you can decrypt the MAC secret using your private key and
passphrase:
$ gpg messageskey.gpg
Enter passphrase for LogCrypt: .......
$ ./logread -i messages.mac -r messageskey <messages
The log is intact.
But be careful; when messageskey is written to disk it may be
recoverable even after you've attempted to delete it.
Managing multiple logs
----------------------
logfork.pl can be used to let a single secret protect multiple
logs created after logfork.pl is started. It works by spawning a
copy of logcrypt to keep encrypted copies of keys for other logs.
When you type a filename on stdin, it spawns a copy of logcrypt to
keep MACs for that file. Later, you can decrypt the master.log
file kept by the parent logcrypt to recover the MAC secrets for
the other logs.
logfork.pl doesn't do a good job of keeping the secrets safe -
they're written to disk temporarily when new copies of logcrypt
are spawned, and not guaranteed to be removed from RAM. If enough
people care about this feature, though, I'll add it as an integral
feature to logcrypt itself.
Example:
$ logfork.pl
b6d95ba04cc3960699394dc1cc7029fbd983ab37
6251bbf42ca78a6c629570bf0d9d4542e83eba64
d6486a14
The first line is the MAC secret, used for verifying log integrity.
The second line is the encryption secret, which keeps the logs
confidential. Keep them in a safe, secret place. In particular,
don't leave them anywhere unencrypted on this machine. You could
write them on a piece of paper kept somewhere safe, for instance.
foo
bar
baz
Now there are 3 commands running:
tail -n 9999999 -f foo | ./logcrypt -r mackey.tmp >foo.mac 2>/dev/null
tail -n 9999999 -f bar | ./logcrypt -r mackey.tmp >bar.mac 2>/dev/null
tail -n 9999999 -f baz | ./logcrypt -r mackey.tmp >baz.mac 2>/dev/null
Later, you can run:
$ logread -d <master.log
Enter MAC key in hex: 0xb6d95ba04cc3960699394dc1cc7029fbd983ab
37
Enter crypt key in hex: 0x6251bbf42ca78a6c629570bf0d9d4542e83eba
64d6486a14
Opened log foo. Mac key:
234e745faf0423c2f0ec1976427dca823456ee0c
Opened log bar. Mac key:
bdc22f6832ede48261b611af6b25ddc985b8d84e
Opened log baz. Mac key:
ab31cac4a58055828869f37d4998ae2cd538ddca
The log is intact.
Then, to verify foo.mac:
$ logread -i foo.mac <foo
Enter MAC key in hex: 0x234e745faf0423c2f0ec1976427dca823456ee
0c
The log is intact.
logfork.pl will accept arguments to pass to logcrypt. So you
could encrypt the master keys with your public key, as in the
earlier example:
$ ./logfork.pl -s "gpg -r LogCrypt -o messageskey.gpg -e"
Bugs:
-----
Bugs: Input lines longer than 8192 bytes are accepted, but will
take up multiple lines in the output file.
|
|