| |||||||||||||
Forward secure sealingForward secure sealingPosted Aug 25, 2012 1:24 UTC (Sat) by dlang (✭ supporter ✭, #313)In reply to: Forward secure sealing by nybble41 Parent article: Forward secure sealing
> 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.
(Log in to post comments)
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.
|
|||||||||||||