Fixing typos to make the whole message clearer.
On Sun, Apr 14, 2024 at 01:03:04AM +0200, Enrico Mioso wrote: > On Fri, Apr 12, 2024 at 05:30:35PM -0400, Michael Richardson wrote: > > > > Daniel Golle <dan...@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. > > No thanks - enough proprietary/signing/secure crap all over already, and I've > been there long enough to tell you this is really not fun. > > Please guys wake up and stop these things. > If you really want to play with this kind of thing, why not build your own > line of hardware? > And if you're kind enough to leave off secure boot in hw, we may be able to > replace the bootloader with one allowing people to do what they feel like > with their hardware. > And I am saying nothing new here since we, as project, find ourselves having > to replace the bootloader sometimes, exactly due to signature checking and > other limitations making things overall more difficult. > I feel like we would damage our reputation allowing something like > "ask us if you want your bootloader binary to be signed". Remembers me of Symbian times, even tough it worked differently of course. > Developing the technology is of course interesting, but the decision to > engage on this should come from the user. > This may create additional problems like e.g.: the user losing the key used > to sign things and so on, and this would act as a reminder not to use this > kind of technology. > And I am all for giving a second chance to the user, so a way to disable this > thing would ideally always be in place. Yes, I know this might not be easy to > due how the SoC works, I am happy to hear from you on this matter. > > > > 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. > > > > I am not a native speaker, so don't get offended if I define this crap, also > due to the fact the PKI stuff is called "junk". > Feel free to upload the whole PKI junk to a github repository where we can > find and use it to sign whatever, thanks. > And no, I am not against you, but really against this idea. Going to faaith > against it as much as I can. > Not against you of course. :) > > Enrico > > -- > > ] Never tell me the odds! | ipv6 mesh > > networks [ > > ] Michael Richardson, Sandelman Software Works | IoT architect > > [ > > ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails > > [ > > > > > > > _______________________________________________ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
