| |||||||||||||
Forward secure sealingForward secure sealingPosted Aug 25, 2012 0:53 UTC (Sat) by Cyberax (✭ supporter ✭, #52523)In reply to: Forward secure sealing by dlang Parent article: Forward secure sealing
It does not use hash _chaining_, i.e. making a hash dependent on all the previous hashes.
Each log block is hashed and sealed separately. Using hashes, of course, but each such block is independent from all the previous blocks.
(Log in to post comments)
Forward secure sealing Posted Aug 25, 2012 1:00 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
> Each log block is hashed and sealed separately. Using hashes, of course, but each such block is independent from all the previous blocks.
so what stops someone from deleting an entire block?
Forward secure sealing Posted Aug 25, 2012 1:03 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
You can store information about the number of previous blocks and/or date of the last sealed block in the current block (in clear text).
Forward secure sealing Posted Aug 25, 2012 1:10 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
but you can fake that information in a replacement sealed block as well, can't you?
Forward secure sealing Posted Aug 25, 2012 1:15 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
It's actually even more simpler. The sealing key itself depends on the block number.
I.e. if you delete a block then the administrator would be able to see that your current key can't be generated without skipping a block.
Forward secure sealing Posted Aug 25, 2012 1:26 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
so you just delete the entire file and recreate the entire file, there's no prior block to compare to and notice a missing block.
Forward secure sealing Posted Aug 25, 2012 1:30 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
Nope. Suppose that you hack into a system and delete block 3 (while block 4 is the current one). Admin will see the following:
<block_1> - key_1 <block_2> - key_2 <block_3> - key_4
You can't recreate key_3 from key_4 (which you know) and you can't modify the sealed block.
Forward secure sealing Posted Aug 25, 2012 1:33 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
right, so you delete everything, not just one bock, and the admin sees
<block> key_4
how is the admin supposed to know that this log file was supposed to start with key_1? remember that logs rotate and so you cannot count on having logs since the beginning of time, so make the nubmers 748934 and up instead of 1 and up.
Forward secure sealing Posted Aug 25, 2012 1:40 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
That's the point - you have to delete EVERYTHING. Also, keys can be made time-dependent if they are regenerated at predictable intervals. "Gaps" due to system downtime can be bridged by special log entries.
I have not yet checked how log sealing actually works, so I'm making it up as I go along. But it certainly seems doable.
Forward secure sealing Posted Aug 25, 2012 1:47 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
I guess the thing is that deleting everything and recreating it doesn't seem like a problem to me. you can create the new logs containing everything that was in the old logs, except what you don't want to be there. you don't even have to have an algorithm to make up log entries.
I don't see how keys can be time dependent. As you note there will be downtime when keys don't get rotated, and any records of what those downtimes were are subject to being tampered with.
Forward secure sealing Posted Aug 25, 2012 1:48 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
You can't recreate everything, as your key is time-dependent. It'll be obvious that timestamps inside the faked blocks and the key-derived timestamps are different.
Forward secure sealing Posted Aug 25, 2012 2:01 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
only if you have a way of knowing
A) which of the keys was used to sign this block
and
B) which key should have been in use at that time
If such technology exists, I'm very interested in learning about it. But I would have expected that technology like this would be in use for things much more significant than just logs.
Forward secure sealing Posted Aug 25, 2012 2:12 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
>A) which of the keys was used to sign this block
? You know this, otherwise signature can not be validated.
> B) which key should have been in use at that time
Suppose that you have the initial key (key_0) constructed on 24 Aug 2012, 00:00 UTC. You encode the key update interval (say, 10 minutes) in this key and start using it. Every 10 minutes you then generate the next key and use it for signing.
Each signed block is numbered, without gaps.
If it turns out that your current system time is ahead of the key's time (because you've resumed your computer from a long sleep) then you insert a special "skip-time" block, signed by your existing (and now obsolete) key and the time-derived key. I.e. that block in essence authenticates a legitimate gap in the log history.
Again, I'm making it up as I go along :) So I might be incorrect.
Forward secure sealing Posted Aug 25, 2012 3:22 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
are you sure? it could be that you know that it's signed by A valid key, but not know which one. I really don't know how this sort of "many signing keys, one verification key" setup works. I'm interested to learn.
I am assuming that this is an asymmetric key, and so knowing the validation key does not let you know the signing key. If that's not the case, all you would need to do is to seed a PRNG and use the output as your symmetric key along with a generation number. That wouldn't be nearly as good as as if this is an asymmetric key.
your 'skip time' log entry does you no good if you don't have logs from all time (what happens when you delete the 'skip time' log entry), you would have to chrun thorugh however many key generation cycles you need to get you to the valid key (and hope that time never goes backwards on your box) as was noted by someone else on this thread.
we can speculate and design what we think is a valid algorithm here, but we don't know if that's what's being implemented in this case.
|
|||||||||||||