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