Hi Alexander, Johannes,
[ Added linux-crypto to Cc: ]
Wow, this is _one_ *intrusive* patchset indeed :-)
But first: Have you checked the digsig project? It's been doing
(for some time) what your current patchset proposes -- and
it uses public key cryptosystems for the key management,
which is decidedly better than using secret-keyed hashes
(HMAC, XCBC). Also, digsig aims to protect executable
binaries in general, and not just suid / sgid ones.
Second: Can we have some discussion on the security model /
threat model / trust model / cryptographic key management
scheme of your signing mechanism? [I had read through the
[0/4] mail you had sent yesterday, but found no relevant
discussion on these aspects there.]
From the patchset, it appears you use a *common* secret key
for _all_ signed binaries, and it is set at kernel build-time itself:
On 6/22/07, Alexander Wuerstlein <arw@xxxxxxxx> wrote:
sns_secret_key.dat contains the 'secret key' which is used for HMAC.
Where:
--- /dev/null
+++ b/security/sns_secret_key.dat
+#define SNS_SECRET_KEY_SIZE 8
+static char sns_secret_key[SNS_SECRET_KEY_SIZE] =
+ {
+ 'd', 'e', 'a', 'd', 'b', 'e', 'e', 'f'
+ };
[ Ok, I won't nitpick as to why does this file look like a header,
is #include-d in the C source as a header, but still has a .dat
extension :-) ]
Anyway, this is *totally* insecure and broken. Do you realize anybody
who lays hands on the kernel image can now _trivially_ extract the
should-have-been-a-secret key from it and use it to sign his own
binaries?
Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
