| |||||||||||||
Forward secure sealingForward secure sealingPosted Aug 25, 2012 0:55 UTC (Sat) by dlang (✭ supporter ✭, #313)In reply to: Forward secure sealing by nybble41 Parent article: Forward secure sealing
If an attacker can delete individual log entries, the sealing or hashing of the logs is worthless
If an attacker can delete all log entires newer than X and put whatever they want after that point, the logs are again worthless.
These are the sorts of things that the initial hashing implementation from systemd was broken on, and why I am skeptical of further security claims from the same product.
(Log in to post comments)
Forward secure sealing Posted Aug 25, 2012 1:10 UTC (Sat) by nybble41 (subscriber, #55106) [Link]
> If an attacker can delete individual log entries, the sealing or hashing of the logs is worthless
There is some value in ensuring that an attacker can't fabricate log entries from before the break-in. If you want to prevent any individual log entries from being deleted, or (more likely) detect any such deletions, you have no choice but to send _some_ data (the log entries or an updated hash) to an external, uncompromised system.
> If an attacker can delete all log entires newer than X and put whatever they want after that point, the logs are again worthless.
That the attacker will be able to fabricate new log entries after the break-in is inevitable, even if you log to an external system. This scheme does prevent the scenario you describe for new log entries between time X (assuming X is before the attack starts) and the generation of the signing key in effect at the time of the actual compromise.
This could be combined with hash chaining to make it harder to get away with erasing individual log entries while keeping other, later, entries. For example, each message M[m] could include the signature of the previous message (S[m-1]). That would make any gaps rather obvious, without requiring you to have all previous log entries on hand to verify the hashes.
Forward secure sealing Posted Aug 25, 2012 1:24 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
> you have no choice but to send _some_ data (the log entries or an updated hash) to an external, uncompromised system.
This is part of my point
If you are required to send _some_ data, then simple hashing is enough (as implemented by logtools for example)
The claim here is that by sending the verification key off of the system at key creation time, there is no need to ever send any other data off of the system for you to know that your logs haven't been tampered with.
If you can truncate the file (either partially or create the entire logfile) and write bogus stuff after the breakin, you can truncate the part of the file that shows the breakin and re-create everything after that point, making the logs look like they had been created before the breakin.
Forward secure sealing Posted Aug 25, 2012 1:49 UTC (Sat) by nybble41 (subscriber, #55106) [Link]
> you can truncate the part of the file that shows the breakin and re-create everything after that point, making the logs look like they had been created before the breakin.
Assuming the messages are chained as I described, that's only true if you're willing to accept a gap in the logs from the first deleted entry to the beginning of the valid interval for the K[n] in effect at the time you compromised the system.
> If you are required to send _some_ data, then simple hashing is enough
The "simple hashing" requires you to send data _continuously_ as the logs are updated. That's a more difficult problem than making a record of a single verification key once at the beginning of the log.
Forward secure sealing Posted Aug 25, 2012 1:59 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
> hat's only true if you're willing to accept a gap in the logs from the first deleted entry to the beginning of the valid interval
so you delete everything and there's no 'valid' entry to compare anything to that will let you detect the gap.
I understand that they are claiming that this verification key eliminates the need to send any data off the box ever again, I'm just not believing it. If someone can point me to the peer reviewed papers that describe how the technology can work, I'll believe it.
Forward secure sealing Posted Aug 25, 2012 2:12 UTC (Sat) by nybble41 (subscriber, #55106) [Link]
> so you delete everything and there's no 'valid' entry to compare anything to that will let you detect the gap.
If you deleted everything then I wouldn't need a "valid" entry to compare against; the simple lack of previous logs would be plenty suspicious by itself.
|
|||||||||||||