lkml.org 
[lkml]   [2011]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [GIT PULL] Crypto keys and module signing
    Date
    Arkadiusz Miśkiewicz <a.miskiewicz@gmail.com> wrote:

    > If I understand it is not possible to sign modules after they are built

    Well, modules are signed after they're built. It's a matter of creating a
    detached signature for the parts of the module file you want to protect and
    then inserting the signature into the module file. I've created a way to do
    this as part of the build process, but previously we had the spec file do it
    during the kernel RPM build.

    > and load keys without actually rebuilding kernel?

    Well, yes and no.

    The way we have used up to now involves building a set of public keys into the
    kernel so that modules can be verified with them during loading. We could make
    a way to load extra keys, but how does the kernel know it can trust those keys?

    With the new mechanism in the patches I've submitted, there is the possibility
    of using a cryptographic key storage hardware (such as a TPM) to directly store
    either extra public keys that you want to be able to verify modules with, or to
    hold a key you sign the extra public keys with.

    That way you can have modules signed with the kernel's build-time temporary key
    and also have modules signed with other keys that are trusted by the
    administrator.

    > For distro kernel the public and secret keys have to be available publicly,
    > right?

    No. The public key has to be publically available, but the secret key must be
    kept, well, secret - otherwise there's no point. If anyone can sign a module
    to run on your system, then the signature mechanism may as well not be there.

    RHEL keeps the secret key as secret as it possibly can by generating a new one
    each time a kernel RPM is built and then it's deleted afterwards when the BUILD
    directory is cleaned up. No record of the secret key is kept. It's not easy
    to have the buildfarm save the secret key in a database somewhere as anyone who
    gets hold of a RHEL kernel SRPM and wants to build it mustn't find the build
    fails because the secret-key-save mechanism doesn't work. Besides - you don't
    want it quietly saving your privately built secret key to Red Hat's big
    database, right?

    > Otherwise people using distro kernels won't be able to build own signed
    > modules for use with that distro kernel.

    That's the whole point... To a point. You can still load unsigned modules,
    but it makes a fuss in the syslog, and you can block unsigned modules.
    Hopefully at some time in the future, as mentioned above, you'll be able to use
    hardware for this.

    > Then I as admin have to rebuild the kernel to get my own keys in and prevent
    > other, "unapproved" modules to be loaded. Correct?

    Correct. You could, theoretically, extract the public keys from the kernel
    you're rebuilding and include those too, but it's messy.

    > Would be nice if the modules could be signed/re-signed after being build

    That's relatively straight forward. You can strip the existing signatures and
    replace them with your own. The modules are really signed *after* being built
    - after all, you don't know what it is you're going to be signing until after
    the things are built.

    > and prehaps kernel could load keys from initramfs?

    How do you trust the keys? If you have a TPM, then yes you can do that.

    In fact, how do you trust the public key compiled into the kernel for that
    matter? Ideally, the bootloader would have to check that the kernel image
    hasn't been tampered with. That's easier than checking the initramfs as the
    kernel is not changed after building, whereas the initramfs is.

    > Then everyone could use own keys on distro kernels without need to rebuild
    > the thing.
    >
    > I think I'm missing something :)

    Perhaps I can summarise:

    (1) The whole point of having a secret key is that you tell as few people as
    absolutely possible what it is.

    (2) Public keys have to be trusted in order for you to use them.

    (3) Cryptography is, by its very nature, inconvenient. But it only works if
    you inconvenience people who shouldn't have access more than you
    inconvenience those who should.

    David
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2011-12-10 13:53    [W:4.172 / U:0.092 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site