linux insmod error -1 required key invalid

Signed kernel module support

From Gentoo Wiki

Jump to:  navigation,  search

Since Linux kernel version 3.7 onwards, support has been added for signed kernel modules. When enabled, the Linux kernel will only load kernel modules that are digitally signed with the proper key. This allows further hardening of the system by disallowing unsigned kernel modules, or kernel modules signed with the wrong key, to be loaded. Malicious kernel modules are a common method for loading rootkits on a Linux system.

Enabling support is a matter of toggling a few settings in the Linux kernel configuration. Unless you want to use your own keypair, this is all that has to be done to enable kernel module support.Enabling module signature verification

Configuring module signature verification

Module signature verification is a kernel feature, so has to be enabled through the Linux kernel configuration. You can find the necessary options under Enable loadable module support.

 [Collapse] 

Kernel configuration Enable module signature verification

--- Enable loadable module support
[*]   Module signature verification
[*]     Require modules to be validly signed
[*]     Automatically sign all modules
      Which hash algorithm should modules be signed with? (Sign modules with SHA-512) --->

The option Module signature verification (CONFIG_MODULE_SIG) enables the module signature verification in the Linux kernel. It supports two approaches on signed module support: a rather permissive one and a strict one. By default, the permissive approach is used, which means that the Linux kernel module either has to have a valid signature, or no signature. With the strict approach, a valid signature must be present. In the above example, the strict approach is used by selecting Require modules to be validly signed (CONFIG_MODULE_SIG_FORCE). Another way of enabling this strict approach is to set the kernel boot option enforcemodulesig=1.

When building the Linux kernel, the kernel modules will not be signed automatically unless you select Automatically sign all modules (CONFIG_MODULE_SIG_ALL).

Finally, we need to select the hash algorithm to use with the cryptographic signature. In the above example, we use SHA-512.

Building the kernel with proper keys

When the Linux kernel is building with module signature verification support enabled, then you can use your own keys or have the Linux kernel build infrastructure create a set for you. If you want the Linux kernel build infrastructure to create it for you, just continue as you always do with a make and make modules_install. At the end of the build process, you will notice that signing_key.priv and signing_key.x509 will be available on the root of the Linux kernel sources.

If we want to use our own keys, you can use openssl to create a key pair (private key and public key). The following command, taken from kernel/Makefile, creates such a key pair.

 [Collapse] 

File x509.genkey Key generation configuration file

[ req ]
default_bits = 4096
distinguished_name = req_distinguished_name
prompt = no
string_mask = utf8only
x509_extensions = myexts
  
[ req_distinguished_name ]
O = GenFic
CN = Kernel Signing Key
emailAddress = server.support@genfic.com
  
[ myexts ]
basicConstraints=critical,CA:FALSE
keyUsage=digitalSignature
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid

user $  openssl req -new -nodes -utf8 -sha512 -days 36500 -batch -x509 -config x509.genkey -outform DER -out signing_key.x509 -keyout signing_key.priv

The resulting files need to be stored as signing_key.x509 and signing_key.priv in the root of the Linux kernel source tree.

The public key part will be build inside the Linux kernel. If you configured the kernel to sign modules, this signing will take place during the make modules_install part.

Validating module signature support

Reboot with the newly configured kernel. In the output of dmesg you should be able to confirm that the proper certificate is loaded:

user $  dmesg | grep MODSIGN

---

[    2.450021] MODSIGN: Loaded cert 'GenFic: Kernel Signing Key: b923a5f44eae25bbad52c8bf2742e7b7e6fb0c0e'

The kernel modules have the digital signature appended at the end. A simple hexdump can confirm if a signature is present or not:

user $  hexdump -C vxlan.ko | tail

---

00008880  cf 0e e7 cb 10 9e 98 5f  4b 21 d4 03 ba 3d 7e e7  |......._K!...=~.|
00008890  68 db f9 e3 5f 62 3c c7  d6 6c 84 c7 d6 68 c1 73  |h..._b<..l...h.s|
000088a0  3d d7 5a 38 66 99 12 b8  84 c9 84 45 dd 68 6d 17  |=.Z8f......E.hm.|
000088b0  03 24 dc 9c 6f 6d 11 01  e9 74 82 ea b5 5b 46 07  |.$..om...t...[F.|
000088c0  fe dd 66 97 1a 33 58 3d  6e d0 ac 03 08 16 73 06  |..f..3X=n.....s.|
000088d0  9f 90 c4 eb b3 82 1d 9f  48 8c 5b 51 01 06 01 1e  |........H.[Q....|
000088e0  14 00 00 00 00 00 02 02  7e 4d 6f 64 75 6c 65 20  |........~Module |
000088f0  73 69 67 6e 61 74 75 72  65 20 61 70 70 65 6e 64  |signature append|
00008900  65 64 7e 0a                                       |ed~.|
00008904

The string ~Module signature appended~ at the end confirms that a signature is present. Of course, it does not confirm that the signature is valid or not.

To remove the signature, we can use the strip command:

root #  strip --strip-debug vxlan.ko 
root #  hexdump -C vxlan.ko | tail

---

00097330  6c 5f 67 65 74 5f 73 74  61 74 73 36 34 00 72 63  |l_get_stats64.rc|
00097340  75 5f 62 61 72 72 69 65  72 00 5f 72 61 77 5f 73  |u_barrier._raw_s|
00097350  70 69 6e 5f 75 6e 6c 6f  63 6b 00 72 65 67 69 73  |pin_unlock.regis|
00097360  74 65 72 5f 70 65 72 6e  65 74 5f 64 65 76 69 63  |ter_pernet_devic|
00097370  65 00 6b 6d 61 6c 6c 6f  63 5f 63 61 63 68 65 73  |e.kmalloc_caches|
00097380  00 6e 65 74 64 65 76 5f  69 6e 66 6f 00 6e 65 69  |.netdev_info.nei|
00097390  67 68 5f 6c 6f 6f 6b 75  70 00 72 65 6c 65 61 73  |gh_lookup.releas|
000973a0  65 5f 73 6f 63 6b 00 72  65 67 69 73 74 65 72 5f  |e_sock.register_|
000973b0  6e 65 74 64 65 76 69 63  65 00                    |netdevice.|
000973ba

If we try to load this module now, we get a failure:

root #  modprobe vxlan

---

modprobe: ERROR: could not insert 'vxlan': Required key not available

This confirms that modules without a signature are not loaded.

Administering kernel module signatures

Once the kernel boots and we have validated that the signed kernel module support works, it is important to correctly handle the keys themselves.

Protecting the private key

The private key, stored as signing_key.priv, needs to be moved to a secure location (unless you will be creating new keys for new kernels, in which case the file can be removed). Do not keep it at /usr/src/linux on production systems as malware can then easily use this key to sign the malicious kernel modules (such as rootkits) and compromise the system further.

Manually signing modules

If you ever need to manually sign a kernel module, you can use the scripts/sign-file script available in the Linux kernel source tree. It requires four arguments:

1. The hash algorithm to use, such as sha512
2. The private key location
3. The certificate (which includes the public key) location
4. The kernel module to sign

In this case, the key pair does not need to be named signing_file.priv and such, nor do they need to be in the root of the Linux kernel source tree location.

user $  perl /usr/src/linux/scripts/sign-file sha512 /mnt/sdcard/kernel-signkey.priv /mnt/sdcard/kernel-signkey.x509 vxlan.ko

Distributing the kernel and modules

If we create a kernel package through make tarbz2-pkg, the modules in it will be signed already so we do not need to manually sign them afterwards. The signing keys themselves are not distributed with it.

More resources

In Booting a self-signed Linux kernel Greg Kroah-Hartman describes how to boot a self-signed Linux kernel from EFI. As having signed kernel module support is only secure if the Linux kernel is trusted, this is an important (and related) feature to work with.

最近在调试一个驱动的时候，用insmod加载.ko的时候，提示Required key not available，

内核配置
内核从3.7后开始支持模块签名，这个功能使能以后，内核只允许安装特定key签名的模块。
内核配置项
CONFIG_MODULE_SIG=y
表示开启了签名机制，但是这时候模块签名或不签名都可以使用。
CONFIG_MODULE_SIG_FORCE=y
如果上述配置项使能，则模块必须有正确的签名才能正常使用。
CONFIG_MODULE_SIG_ALL=y

内核在编译的时候，并不会主动去给模块签名，除非你把上述配置项打开。

另外CONFIG_MODULE_SIG=sha256指定了加密的算法

查看内核配置文件，发现上面3个配置项确实都打开了，因此肯定是ko签名的问题。


内核如何签名
在内核kernel/kernel下的Makefile中有如下，
signing_key.priv signing_key.x509: x509.genkey
其中，x509.genkey是生成key pair时的配置项，signing_key.priv signing_key.x509分别为private key和数字证书。数字证书会打包进内核，里面有公钥等，用来解密嘛。每编译一次，虽然配置文件每次都相同，但是生成的key pair是不同的。


查看签名信息
利用下面命令查看设备中的ko文件信息，
hexdump -C my_ko.ko |tail -5
下面是输出（内核签名后会把签名信息附在模块的最后面），
005387a0  73 c9 a2 78 6a 6e 4c f7  4f 36 b3 45 1b 64 73 b8  |s..xjnL.O6.E.ds.|
005387b0  1d ca 49 ff 59 6a 99 4b  5b 13 40 75 01 06 01 1e  |..I.Yj.K[.@u....|
005387c0  14 00 00 00 00 00 02 02  7e 4d 6f 64 75 6c 65 20  |........~Module |
005387d0  73 69 67 6e 61 74 75 72  65 20 61 70 70 65 6e 64  |signature append|
005387e0  65 64 7e 0a                                       |ed~.|
005387e4
由上面输出，我们发现这个ko已经有签名信息(Module signature appended)，为何还是提示key不对。于是我将编译机中版本的my_ko.ko和设备中的做比较，发现唯有最后部分不同，我猜一定是两个ko的签名不同，这应该就是初步原因。


问题根源
仔细分析后，得到原因：

原来设备中的内核是后来编译的，编译完成后我将内核单独烧录进设备（内核肯定就放在kernel的分区），而未改变文件系统(这样会造成新kernel中的数字证书已经改变，但是文件系统中的my_ko.ko未改变，而是用以前的内核中private key进行签名的)。重新完整烧录版本后，一切功能正常!

linux配置文件：

Linux的内核配置文件有两个，一个是隐含的.config文件，嵌入到主Makefile中；另一个是include/linux/autoconf.h，嵌入到各个c源文件中，它们由make config、make menuconfig、make xconfig这些过程创建。几乎所有的源文件都会通过linux/config.h而嵌入autoconf.h，如果按照通常方法建立文件依赖关系(.depend)，只要更新过autoconf.h，就会造成所有源代码的重新编绎。

为了优化make过程，减少不必要的重新编绎，Linux开发了专用的mkdep工具，用它来取代gcc来生成.depend文件。mkdep在处理源文件时，忽略linux/config.h这样的头文件，识别源文件宏指令中具有＂CONFIG_＂特征的行。例如，如果有＂#ifdef CONFIG_SMP＂这样的行，它就会在.depend文件中输出$(wildcard /usr/src/linux/include/config/smp.h)。

include/config/下的文件是另一个工具split-include从autoconf.h中生成，它利用autoconf.h中的CONFIG_标记，生成与mkdep相对应的文件。例如，如果autoconf.h中有＂#undef CONFIG_SMP＂这一行，它就生成include/config/smp.h文件，内容为＂#undef CONFIG_SMP＂。这些文件名只在.depend文件中出现，内核源文件是不会嵌入它们的。每配置一次内核，运行split-include一次。split-include会检查旧的子文件的内容，确定是不是要更新它们。这样，不管autoconf.h修改日期如何，只要其配置不变，make就不会重新编绎内核。

如果系统的编绎选项发生了变化，Linux也能进行增量编绎。为了做到这一点，make每编绎一个源文件时生成一个flags文件。例如编绎sched.c时，会在相同的目录下生成隐含的.sched.o.flags文件。它是Makefile的一个片断，当make进入某个子目录编绎时，会搜索其中的flags文件，将它们嵌入到Makefile中。这些flags代码测试当前的编绎选项与原来的是不是相同，如果相同，就将自已对应的目标文件加入FILES_FLAGS_UP_TO_DATE列表，然后，系统从编绎对象表中删除它们，得到FILES_FLAGS_CHANGED列表，最后，将它们设为目标进行更新。