Android Install kernel module, prompting required key not

Android Install kernel module, prompting required key not available

Recently, when debugging a driver, loading with Insmod. Ko, the prompt required key not available, the first reaction is the signature problem, the kernel module also began to use a similar apk signature. This is what happens when you look up the data. The problem is not Android, it's the Linux system, and Android itself is a Linux system.

Come down one step at a step to analyze the problem.

Kernel configuration

The kernel supports module signatures from 3.7 onwards, which allows the kernel to only install modules that have a specific key signature.
Kernel Configuration Items
Config_module_sig=y
Indicates that the signature mechanism is turned on, but it can be used when the module is signed or not signed.
Config_module_sig_force=y
If the above configuration item is enabled, the module must have the correct signature to work properly.
Config_module_sig_all=y
The kernel does not take the initiative to sign the module when it is compiled, unless you open the configuration item above.

Look at the kernel configuration file and find that all 3 of the above configuration items are open, so it must be a problem with Ko signing.

How the kernel is signed

The makefile in the kernel Kernel/kernel are as follows,

Signing_key.priv signing_key.x509:x509.genkey
@echo "###"
@echo "### now generating a X.509 key pair to be us Ed for signing modules. "
@echo "###"
@echo "### If This takes a long time, you might wish to run Rngd in the"
@echo "### background to Keep the supply of entropy topped up.  It "
@echo" ### needs to be run as root, and uses a hardware random "
@ echo "### number generator if one is available."
@echo "###"
OpenSSL Req-new-nodes-utf8-$ (config_module_sig_hash)-days 36500 \
-batch-x509-config x509. Genkey \
-outform der-out signing_key.x509 \
-keyout signing_key.priv 2>&1
@echo "###"
@echo "### Key pair generated. "
@echo "###"

X509.genkey:
@echo generating X.509 key generation config
@echo   >x509.genkey "[req]"
@echo >& Gt;x509.genkey "default_bits = 4096"
@echo >>x509.genkey "distinguished_name = req_distinguished_name"
@ echo >>x509.genkey "prompt = no"
@echo >>x509.genkey "string_mask = utf8only"
@echo >>x509.genk EY "x509_extensions = myexts"
@echo >>x509.genkey
@echo >>x509.genkey "[Req_distinguished_name]" br> @echo >>x509.genkey "O = Magrathea"
@echo >>x509.genkey "CN = Glacier signing Key"
@echo >>x 509.genkey "EmailAddress = slartibartfast@magrathea.h2g2"
@echo >>x509.genkey
@echo >>x509.genkey "[Myexts]"
@echo >>x509.genkey "Basicconstraints=critical,ca:false"
@echo >>x509.genkey " Keyusage=digitalsignature "
@echo >>x509.genkey" Subjectkeyidentifier=hash
@echo >>x509.genkey " Authoritykeyidentifier=keyid "

Wherein, X509.genkey is the configuration item when the key pair is generated, Signing_key.priv signing_key.x509 is private key and digital certificate respectively. The digital certificate is packaged into the kernel, which has a public key and so on to decrypt it. Every time a compilation is compiled, the configuration file is the same, but the generated key pair is different.

Viewing signature information

Use the command below to view the KO file information in the device.

Hexdump-c My_ko.ko |tail

The following is the output (the kernel signature will attach the signature information to the end of the module).

00538760 D3 1c 5f F2 (7d c8) 2f | Hp2.6u._.9.}. w/|
00538770 DB 1d B6 1a 4b b5 0f 0f 5a F9 C3 1d D7 66 | K... Dz....f|
00538780 d5 ab 3e f6 4b bayi b3 A4, ab 3d |. ". K8 ..... V. " =|
00538790 FE cc 2b 9c-0e-DF-A3 2a BC B4 | U.. +.. (9.g.c.*..|
005387A0 C9 A2 6a 6e 4c F7 4f B3 (1b) B8 |s. xjnl.o6.e.ds.|
005387B0 1d CA ' FF "6a, 4b 5b" 1e | i.yj.k[.@u....|
005387c0 7e 4d 6f to |........~module 6c (m) |
005387d0 6e-A-|signature append|, 6e-A-
005387e0 7e 0a |ed~.|
005387e4

From the above output, we found that the KO already has signed information (Module signature appended), why the prompt key is not correct. So I will compile the version of the My_ko.ko and equipment in comparison, found only the last part of the difference, I guess it must be two KO signature different, this should be the primary reason.

The root of the problem

After careful analysis, get the reason:
The kernel in the original device was later compiled and I burned the kernel into the device (the kernel must have been placed on the kernel partition) without changing the file system (which would cause the digital certificate in the new kernel to change, but the My_ in the file system) Ko.ko is not changed, but is signed with the private key in the previous kernel. After the full burn version, all functions are normal!