Each samhain executable contains a compiled-in key, that is used when the signatures of emails and/or logfile entries are verified. By default, a cryptographically strong random key is generated by the configure script at compile time. Thus, each build is unique, and signature verification will fail if a different build is used, except if the compiled-in key was set to a common value for both builds.
To set a user-defined key, there is an option
where B1,B2 should be two integers in the range 0...2147483647.
The key generated by configure is printed in the configure script's output. It is recommended that you save this key and use it for further builds.
Whenever you try to verify the integrity of e-mails or log file entries, this compiled-in key is used (to be more specific: the signature key is encrypted with a one-time pad generated from the message itself and the compiled-in key). As a result, if executable B is used to verify the integrity of e-mails sent by executable A, integrity verification will fail if the compiled-in keys of A and B do not match. This can be used to check the integrity of A in a straightforward way (check e-mails on another host, using a different executable compiled with the same key).
Obviously, this scheme can be broken, but it requires an intruder to disassemble/decompile and analyze the existing samhain executable, rather than simply replace it with a precompiled trojan.
However, if you use a precompiled samhain executable (e.g. from a binary distribution), in principle a prospective intruder could easily obtain a copy of the executable and analyze it in advance. This will enable her/him to generate fake audit trails and/or generate a trojan for this particular binary distribution.
For this reason, it is possible for the user to add more key material into the binary executable. This is done with the command:
This will read the file
/path/to/samhain_executable, add the key
key, which can be a string of arbitrary
length, except that it should not contain a '@' (because it
has a special meaning, separating key from path), and write
the new binary to the location
/path/to/executable.out(i.e. with .out
Please note that --add-key does not replace a compiled-in key but only adds to it. Integrity verification depends on both the compiled-in and any added key material, and integrity verification using different binaries will therefore only work if all were compiled with the same key and had the same extra key material (if any) added in.
Using a precompiled samhain executable from a binary package distribution is not recommended unless you add in key material as described above.