On Mo, 11.10.21 17:08, Andreas Krueger (andreas.krue...@fmc-ag.com) wrote:
> Hi Folks,
>
>
> I am currently working in an embedded project that uses Journal for logging.
> The logging data shall be protected by the Journal's sealing mechanism FSS
> and for various reasons the verification key is located unprotected in memory.
>
> Regarding this constellation, my first question is that:
>
> If an attacker knows the verification key, is he able to modify the
> logging data in such a way that its tempering remains undetected,
> even if this has happened e.g. one day ago (which means that several
> new sealing keys has been generated in the meantime) ?
Yes, the verification key should be kept secret. (The text output when
it is generated should make this very clear, actually.)
if you don't keep it secret, then all bets are off, the construction
of the underlying cryptography does not work then.
> Since sealing is always done for a time interval, my second question is that:
>
> What will happen to the logging data and sealing mechanism when the
> system clock is suddenly modified? This can e.g. happen, when the
> board starts first with a default time value and then synchronized
> after a while by a time daemon.
the sealing key is "evolved" based on time (which means a new key is
generated from the old and the old one is securely deleted). When time
jumps forward, then this scheme automatically keeps up, and if needed
will evolve a number of steps at once, as necessary.
If time jumps backwards things are more problematic though: the key
appropriate for the old time has already been generated likely, and
while a newer key can be derived from the old an older cannot be
derived from the new (this fact is after all the whole point of the
excercise).
For cases like this it might make sense to ensure that flushing of the
journal to disk (i.e. systemd-journald-flush.service) is scheduled
after correct time has been acquired (i.e. time-sync.target).
Lennart
--
Lennart Poettering, Berlin
