Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
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)
Posted Aug 25, 2012 1:30 UTC (Sat) by Cyberax (✭ supporter ✭, #52523)
You can't recreate key_3 from key_4 (which you know) and you can't modify the sealed block.
Posted Aug 25, 2012 1:33 UTC (Sat) by dlang (✭ supporter ✭, #313)
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.
Posted Aug 25, 2012 1:40 UTC (Sat) by Cyberax (✭ supporter ✭, #52523)
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.
Posted Aug 25, 2012 1:47 UTC (Sat) by dlang (✭ supporter ✭, #313)
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.
Posted Aug 25, 2012 1:48 UTC (Sat) by Cyberax (✭ supporter ✭, #52523)
Posted Aug 25, 2012 2:01 UTC (Sat) by dlang (✭ supporter ✭, #313)
A) which of the keys was used to sign this block
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.
Posted Aug 25, 2012 2:12 UTC (Sat) by Cyberax (✭ supporter ✭, #52523)
> B) which key should have been in use at that time
That's true because of the key's construction.
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.
Posted Aug 25, 2012 3:22 UTC (Sat) by dlang (✭ supporter ✭, #313)
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds