Device Tree Bindings
--------------------
The following properties are required in the FIT's signature node(s) to
-allow thes signer to operate. These should be added to the .its file.
+allow the signer to operate. These should be added to the .its file.
Signature nodes sit at the same level as hash nodes and are called
-signature@1, signature@2, etc.
+signature-1, signature-2, etc.
-- algo: Algorithm name (e.g. "sha1,rs2048")
+- algo: Algorithm name (e.g. "sha1,rsa2048")
- key-name-hint: Name of key to use for signing. The keys will normally be in
a single directory (parameter -k to mkimage). For a given key <name>, its
- comment: Additional information about the signer or image
+- padding: The padding algorithm, it may be pkcs-1.5 or pss,
+ if no value is provided we assume pkcs-1.5
+
For config bindings (see Signed Configurations below), the following
additional properties are optional:
- hashed-nodes: A list of nodes which were hashed by the signer. Each is
a string - the full path to node. A typical value might be:
- hashed-nodes = "/", "/configurations/conf@1", "/images/kernel@1",
- "/images/kernel@1/hash@1", "/images/fdt@1",
- "/images/fdt@1/hash@1";
+ hashed-nodes = "/", "/configurations/conf-1", "/images/kernel",
+ "/images/kernel/hash-1", "/images/fdt-1",
+ "/images/fdt-1/hash-1";
- hashed-strings: The start and size of the string region of the FIT that
was hashed
Public keys should be stored as sub-nodes in a /signature node. Required
properties are:
-- algo: Algorithm name (e.g. "sha1,rs2048")
+- algo: Algorithm name (e.g. "sha1,rsa2048")
Optional properties are:
- required: If present this indicates that the key must be verified for the
image / configuration to be considered valid. Only required keys are
normally verified by the FIT image booting algorithm. Valid values are
-"image" to force verification of all images, and "conf" to force verfication
+"image" to force verification of all images, and "conf" to force verification
of the selected configuration (which then relies on hashes in the images to
verify those).
/ {
images {
- kernel@1 {
+ kernel-1 {
data = <data for kernel1>
- signature@1 {
+ signature-1 {
algo = "sha1,rsa2048";
value = <...kernel signature 1...>
};
};
- kernel@2 {
+ kernel-2 {
data = <data for kernel2>
- signature@1 {
+ signature-1 {
algo = "sha1,rsa2048";
value = <...kernel signature 2...>
};
};
- fdt@1 {
+ fdt-1 {
data = <data for fdt1>;
- signature@1 {
+ signature-1 {
algo = "sha1,rsa2048";
vaue = <...fdt signature 1...>
};
};
- fdt@2 {
+ fdt-2 {
data = <data for fdt2>;
- signature@1 {
+ signature-1 {
algo = "sha1,rsa2048";
vaue = <...fdt signature 2...>
};
};
};
configurations {
- default = "conf@1";
- conf@1 {
- kernel = "kernel@1";
- fdt = "fdt@1";
+ default = "conf-1";
+ conf-1 {
+ kernel = "kernel-1";
+ fdt = "fdt-1";
};
- conf@1 {
- kernel = "kernel@2";
- fdt = "fdt@2";
+ conf-1 {
+ kernel = "kernel-2";
+ fdt = "fdt-2";
};
};
};
configuration 3 with kernel 1 and fdt 2:
configurations {
- default = "conf@1";
- conf@1 {
- kernel = "kernel@1";
- fdt = "fdt@1";
+ default = "conf-1";
+ conf-1 {
+ kernel = "kernel-1";
+ fdt = "fdt-1";
};
- conf@1 {
- kernel = "kernel@2";
- fdt = "fdt@2";
+ conf-1 {
+ kernel = "kernel-2";
+ fdt = "fdt-2";
};
- conf@3 {
- kernel = "kernel@1";
- fdt = "fdt@2";
+ conf-3 {
+ kernel = "kernel-1";
+ fdt = "fdt-2";
};
};
With signed images, nothing protects against this. Whether it gains an
advantage for the attacker is debatable, but it is not secure.
-To solved this problem, we support signed configurations. In this case it
+To solve this problem, we support signed configurations. In this case it
is the configurations that are signed, not the image. Each image has its
own hash, and we include the hash in the configuration signature.
/ {
images {
- kernel@1 {
+ kernel-1 {
data = <data for kernel1>
- hash@1 {
+ hash-1 {
algo = "sha1";
value = <...kernel hash 1...>
};
};
- kernel@2 {
+ kernel-2 {
data = <data for kernel2>
- hash@1 {
+ hash-1 {
algo = "sha1";
value = <...kernel hash 2...>
};
};
- fdt@1 {
+ fdt-1 {
data = <data for fdt1>;
- hash@1 {
+ hash-1 {
algo = "sha1";
value = <...fdt hash 1...>
};
};
- fdt@2 {
+ fdt-2 {
data = <data for fdt2>;
- hash@1 {
+ hash-1 {
algo = "sha1";
value = <...fdt hash 2...>
};
};
};
configurations {
- default = "conf@1";
- conf@1 {
- kernel = "kernel@1";
- fdt = "fdt@1";
- signature@1 {
+ default = "conf-1";
+ conf-1 {
+ kernel = "kernel-1";
+ fdt = "fdt-1";
+ signature-1 {
algo = "sha1,rsa2048";
value = <...conf 1 signature...>;
};
};
- conf@2 {
- kernel = "kernel@2";
- fdt = "fdt@2";
- signature@1 {
+ conf-2 {
+ kernel = "kernel-2";
+ fdt = "fdt-2";
+ signature-1 {
algo = "sha1,rsa2048";
value = <...conf 1 signature...>;
};
You can see that we have added hashes for all images (since they are no
longer signed), and a signature to each configuration. In the above example,
-mkimage will sign configurations/conf@1, the kernel and fdt that are
-pointed to by the configuration (/images/kernel@1, /images/kernel@1/hash@1,
-/images/fdt@1, /images/fdt@1/hash@1) and the root structure of the image
+mkimage will sign configurations/conf-1, the kernel and fdt that are
+pointed to by the configuration (/images/kernel-1, /images/kernel-1/hash-1,
+/images/fdt-1, /images/fdt-1/hash-1) and the root structure of the image
(so that it isn't possible to add or remove root nodes). The signature is
-written into /configurations/conf@1/signature@1/value. It can easily be
+written into /configurations/conf-1/signature-1/value. It can easily be
verified later even if the FIT has been signed with other keys in the
meantime.
In addition to the options to enable FIT itself, the following CONFIGs must
be enabled:
-CONFIG_FIT_SIGNATURE - enable signing and verfication in FITs
+CONFIG_FIT_SIGNATURE - enable signing and verification in FITs
CONFIG_RSA - enable RSA algorithm for signing
WARNING: When relying on signed FIT images with required signature check
Testing
-------
-An easy way to test signing and verfication is to use the test script
+An easy way to test signing and verification is to use the test script
provided in test/vboot/vboot_test.sh. This uses sandbox (a special version
of U-Boot which runs under Linux) to show the operation of a 'bootm'
command loading and verifying images.
projects / platform / kernel / u-boot.git / blobdiff