Hi,
I'm looking at my draft MR for persisting monitor state (https://git.glasklar.is/sigsum/core/sigsum-go/-/merge_requests/152).
There's a bit of extra complexity there because the monitor stores treeheads *including* signature. Those signatures are verified when it is restarted and state is read back from disk. It's not clear to me that provides any real value, though. Do we lose anything if we verify signatures when tree heads are received from the network, and then discard the signatures and just trust local system integrity?
One attack I'm thinking of: Say leaf 17 records some malicious act that the monitor would flag. If the monitor can be taken down when it has processed the log up to leaf 15, and then have it's state fast-forwarded so that when it is restarted, it thinks it already have looked at everything up to leaf 20, that's a problem. However, (i) verifying the tree head signature doesn't help; since attacker can get a properly signed later tree head by just asking the log, and (ii) if the attacker is control of the local storage, monitoring is broken anyway.
Almost the same question applies to witnesses, which also needs to persist latest observed and cosigned tree head. My witness implementation stores the log's signature and its own cosignature, and verifies both when state is loaded at restart. The relevant attack here is forcing the state backwards, rather than forwards, but the signatures appear to not provide any protection against that attack either.
And in either scenarios, in case the treehead is modified in any other way than to a different valid treehead in the past or in the future, that should result in a consistency error when the monitor/witness received the next treehead from the log.
Am I missing something, or can we just drop local storage of tree head signatures?
Regards, /Niels
Agreed, storing (co)signatures doesn't protect against attacks on the monitor's disk. Only storing the tree head seems fine to me, assuming that the tree head state is never moved forward without a sufficient amount of witnessing. Otherwise you probably want to know who has cosigned what when, so that it is possible to eventually trigger alerts that say too many recent cosignatures are missing. Split-view?
Out of hyugine I'd still store the latest good (signed) state for each log and witness though. Because it may be useful if an incident occurs.
-Rasmus
On Thu, Nov 16, 2023 at 03:40:05PM +0100, Sigsum General wrote:
Hi,
I'm looking at my draft MR for persisting monitor state (https://git.glasklar.is/sigsum/core/sigsum-go/-/merge_requests/152).
There's a bit of extra complexity there because the monitor stores treeheads *including* signature. Those signatures are verified when it is restarted and state is read back from disk. It's not clear to me that provides any real value, though. Do we lose anything if we verify signatures when tree heads are received from the network, and then discard the signatures and just trust local system integrity?
One attack I'm thinking of: Say leaf 17 records some malicious act that the monitor would flag. If the monitor can be taken down when it has processed the log up to leaf 15, and then have it's state fast-forwarded so that when it is restarted, it thinks it already have looked at everything up to leaf 20, that's a problem. However, (i) verifying the tree head signature doesn't help; since attacker can get a properly signed later tree head by just asking the log, and (ii) if the attacker is control of the local storage, monitoring is broken anyway.
Almost the same question applies to witnesses, which also needs to persist latest observed and cosigned tree head. My witness implementation stores the log's signature and its own cosignature, and verifies both when state is loaded at restart. The relevant attack here is forcing the state backwards, rather than forwards, but the signatures appear to not provide any protection against that attack either.
And in either scenarios, in case the treehead is modified in any other way than to a different valid treehead in the past or in the future, that should result in a consistency error when the monitor/witness received the next treehead from the log.
Am I missing something, or can we just drop local storage of tree head signatures?
Regards, /Niels
Sigsum-general mailing list -- sigsum-general@lists.sigsum.org To unsubscribe send an email to sigsum-general-leave@lists.sigsum.org
Rasmus Dahlberg rgdd@glasklarteknik.se writes:
Agreed, storing (co)signatures doesn't protect against attacks on the monitor's disk.
Ok.
Only storing the tree head seems fine to me, assuming that the tree head state is never moved forward without a sufficient amount of witnessing.
Hmm, I think that's a tangential issue, or does it relate to locally stored signatures in some way? (My thinking is that if the log signs a tree that includes a leaf with an unauthorized signature, that's worthy of alerts regardless of the presence of cosignatures. And then there should be orthogonal check to raise alerts if cosignatures are missing for too long).
Otherwise you probably want to know who has cosigned what when, so that it is possible to eventually trigger alerts that say too many recent cosignatures are missing.
Right, I plan to keep state (which probably does *not* need to persisted to disk) with the latest timestamp cosigned per log per witnesses, and the latest timestamp per log that had sufficient number of cosignatures to satisfy configured quorum.
Out of hyugine I'd still store the latest good (signed) state for each log and witness though. Because it may be useful if an incident occurs.
If that's for forensic purposes only, a monitor could store all received tree heads, including all signatures, to a write-only log file. Those signatures would never be read or verified by the monitor itself, and writing that log, if wanted, could be the responsibility of the monitor application, but out-of-scope for the core monitor library.
Or do you see any concrete benefit in having the monitor check that signature when restarting?
Regards, /Niels
On Fri, Nov 17, 2023 at 12:57:00PM +0100, Niels Möller wrote:
Rasmus Dahlberg rgdd@glasklarteknik.se writes:
Agreed, storing (co)signatures doesn't protect against attacks on the monitor's disk.
Ok.
Only storing the tree head seems fine to me, assuming that the tree head state is never moved forward without a sufficient amount of witnessing.
Hmm, I think that's a tangential issue, or does it relate to locally stored signatures in some way? (My thinking is that if the log signs a tree that includes a leaf with an unauthorized signature, that's worthy of alerts regardless of the presence of cosignatures.
I agree with your thinking here.
And then there should be orthogonal check to raise alerts if cosignatures are missing for too long).
Also agree that such checks are orthogonal.
What I'm trying to say is I don't see an obvious issue if (co)signatures are dropped on disk. The part I do see a potential issue with is if we lose track of how far each log and witness for that log progressed. And if untracked, at least ensure we had a quorum for the stored state.
Otherwise you probably want to know who has cosigned what when, so that it is possible to eventually trigger alerts that say too many recent cosignatures are missing.
Right, I plan to keep state (which probably does *not* need to persisted to disk) with the latest timestamp cosigned per log per witnesses, and the latest timestamp per log that had sufficient number of cosignatures to satisfy configured quorum.
To me it sounds like this information should be persisted to disk. And size as well as root hash that the witness timestamp is associated with.
Out of hyugine I'd still store the latest good (signed) state for each log and witness though. Because it may be useful if an incident occurs.
If that's for forensic purposes only, a monitor could store all received tree heads, including all signatures, to a write-only log file. Those signatures would never be read or verified by the monitor itself, and writing that log, if wanted, could be the responsibility of the monitor application, but out-of-scope for the core monitor library.
The angle you're describing now wrt. forensic purposes makes sense. I like it because the point of a transparency log is not that there will never be an issue. But we can debug issues, and such info = v. helpful.
Perhaps a toggle for 'store everything' and 'store latest' is a reasonable option to have? With the default being 'store latest'.
Or do you see any concrete benefit in having the monitor check that signature when restarting?
No, the only use-case I can think of is random disk-errors. I.e., it is possible to know that it's not a valid signed tree head stored on disk.
-Rasmus
sigsum-general@lists.sigsum.org
-
Niels Möller -
Rasmus Dahlberg