On Fri, May 16, 2025 at 02:54:30PM +0200, Rasmus Villemoes wrote: > Background: > > I have several customers that will be using a certain remote signing > service for signing their images, in order that the private keys are > never exposed outside that company's secure servers. This is done via > a pkcs#11 interface that talks to the remote signing server, and all > of that works quite well. > > However, the way this particular signing service works is that one > must upfront create a "signing session", where one indicates which > keys one will use and, importantly, how many times each key will (may) > be used. Then, depending on the keys requested and the customer's > configuration, one or more humans must authorize that signing session > So for example, if official release keys are to be used, maybe two > different people from upper management must authorize, while if > development keys are requested, the developer himself can authorize > the session. > > Once authorized, the requester receives a token that must then be used > for signing via one of the keys associated to that session. > > I have that integrated in Yocto in a way that when a CI starts a BSP > build, it automatically works out which keys will be needed (e.g. one > for signing U-Boot, another for signing a kernel FIT image) based on > bitbake metadata, requests an appropriate signing session, and the > appropriate people are then notified and can then look at the details > of that CI pipeline and confirm that it is legitimate. > > The problem: > > The way mkimage does FIT image signing means that the remote server > can be asked to perform a signature an unbounded number of times, or > at least a number of times that cannot be determined upfront. This > means that currently, I need to artificially say that a kernel key > will be used, say, 10 times, even when only a single FIT image with > just one configuration node is created. > > Part of the security model is that once the number of signings using a > given key has been depleted, the authorization token becomes useless > even if somehow leaked from the CI - and _if_ it is leaked/compromised > and abused before the CI has gotten around to do its signings, the > build will then fail with a clear indication of the > compromise. Clearly, having to specify a "high enough" expected use > count is counter to that part of the security model, because it will > inevitably leave some allowed uses behind. > > While not perfect, we can give a reasonable estimate of an upper bound > on the necessary extra size by simply counting the number of hash and > signature nodes in the FIT image. > > As indicated in the comments, one could probably make it even more > precise, and if there would ever be signatures larger than 512 bytes, > probably one would have to do that. But this works well enough in > practice for now, and is in fact an improvement in the normal case: > Currently, starting with size_inc of 0 is guaranteed to fail, so we > always enter the loop at least twice, even when not doing any signing > but merely filling hash values. > > Just in case I've missed anything, keep the loop incrementing 1024 > bytes at a time, and also, in case the estimate turns out to be over > 64K, ensure that we do at least one attempt by changing to a do-while > loop. > > With a little debug printf, creating a FIT image with three > configuration nodes previously resulted in > > Trying size_inc=0 > Trying size_inc=1024 > Trying size_inc=2048 > Trying size_inc=3072 > Succeeded at size_inc=3072 > > and dumping info from the signing session (where I've artifically > asked for 10 uses of the kernel key) shows > > "keyid": "kernel-dev-20250218", > "usagecount": 9, > "maxusagecount": 10 > > corresponding to 1+2+3+3 signatures requested (so while the loop count > is roughly linear in the number of config nodes, the number of > signings is quadratic). > > With this, I instead get > > Trying size_inc=3456 > Succeeded at size_inc=3456 > > and the expected > > "keyid": "kernel-dev-20250218", > "usagecount": 3, > "maxusagecount": 10 > > thus allowing me to set maxusagecount correctly. > > Signed-off-by: Rasmus Villemoes <r...@prevas.dk> > --- > tools/fit_image.c | 80 +++++++++++++++++++++++++++++++++++++++++------ > 1 file changed, 70 insertions(+), 10 deletions(-)
I think some tests need to be updated now: https://source.denx.de/u-boot/u-boot/-/jobs/1156824 -- Tom
signature.asc
Description: PGP signature
