OpenWrt One / project update

[Michael Richardson]

Daniel Golle <daniel at makrotopia.org> wrote:
    >> In the first PDF, there is mention of:
    >> Security Support 2 * 256-bit multi-key on OTP eFuse
    >> Support 64 version OTP eFuse for anti-rollback

    > Those features require proprietary tools provided by MediaTek only to
    > clients under NDA. Unless some 3rd-party reverse-engineers those
    > tools, we won't ever use those features. Also note that those 256-bit
    > keys are *symmetric* keys probably, so not that useful for IDevID.

Yes, I know they are symmetrical.
Typically, the way that a 256-bit seed is used is that it is blown in the
MediaTek fab with a strong random number.  This seed is then provided via
secure storage to the OEM (us). [You ought to be thinking Johnny Nmemonic,
but in practive, I think it's a USB drive with a password protected .xlsx
file, sigh]

Our factory then uses the seed to generate a (256-bit ECDSA) keypair, for
which a CSR and then certificate are generated.  The private key is securely
erased, and the certificate is loaded into the device.   The device
"simultaenously" uses the seed to generate the same keypair, and it now has
the private key that goes with the certificate.
This process has become common, but it doesn't have a good name.
https://www.ietf.org/archive/id/draft-irtf-t2trg-taxonomy-manufacturer-anchors-03.html#name-carrot-method-key-setup-bas
(I tried to rename the methods: (A)vocado, (B)amboo, and (C)arrot, but that
was considered too whimsical by some)

    >> which is often the key to getting IDevID deployed, but I didn't find further
    >> mention of that in the three datasheets.

    > Another option for deploying IDevID is using MMU to prevent access to
    > the SPI-NOR I/O range from non-secure land and handling cryptographic
    > operations entirely in the secure enclave, e.g. using OP-TEE and fTPM.

    > This is possible without burning any fuses and without any proprietary
    > tools (but will probably not be implemented in time for the firmware
    > which will ship with the device -- however, it can be done after, I
    > can help and point who ever wants to do it to the right directions.)

If we are going to use OP-TEE to get an fTPM enabled, then that can be used
for IDevID, and it's much faster (and rather more secure) than i2c interfaced
discreet chips.  But, it means more factory work for us.

Usually, the ARM TrustZone must be initialized pretty early, at the latest in
our u-boot.

https://mediatek.gitlab.io/aiot/doc/aiot-dev-guide/master/sw/yocto/secure-boot.html
Has a nice picture of how the various *SECURE BOOT* goes together.
This is not for this CPU/SOC, but the Genio eval cards.  My guess is that
it's probably pretty common across their line, and it's within epsilon of
other ARM processors.

The issue is that we don't want SECURE BOOT, at least not past u-boot,
because that would get in the way of the people who want to use this board.
We might want the orange, and red pieces in the diagram.

My suggestion (which I think is feasible) is that we put a signed u-boot onto
the board, but that we turn u-boot verification of Linux-kernel/initramfs
(the "FIT" stuff) *off*. Owners can install their own signing keys and sign
their images if they want to do that.   Probably, we can leave measure boot on.

Measured boot collects the hashes (into the fTPM usually), and then asks a
third party if they are okay.  https://www.rfc-editor.org/rfc/rfc9334#name-two-types-of-environments-o

Having orange and red pieces "secured" *does* mean that u-boot updates would
have to come from openwrt.  That's descending into a thresherous way <
https://www.gnu.org/philosophy/can-you-trust.html > a bit.
Probably we can offer to sign other people's u-boot images; but probably
there won't be more than a dozen such requests.

An alternative is that we find a way not to sign or initialize the BROM/TF-A
secured boot, leaving those fuses unblown, and leave this to end owners to do.
That might be impossible, and my experience with other ARM boards is that
unless they get the fTPM loaded by the OAM board manufacturer, it just
doesn't work out.

ps: I'm willing to operate and secure the PK *I* junk that is needed to make
    this all work. It won't pass PCI on round one, but I'm sure if that was
    important, it could be done.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 511 bytes
Desc: not available
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20240412/4b5c5588/attachment.sig>