[otp_ctrl] Access to the key derivation interface from software + some questions about secret partitions

According to the otp_ctrl [Theory of Operation](https://opentitan.org/book/hw/top_earlgrey/ip_autogen/otp_ctrl/doc/theory_of_operation.html) documentation:

> The Key Derivation Interface (KDI) on the bottom right side interacts with the scrambling datapath, the EDN and the partition holding the scrambling root keys in order to derive static and ephemeral scrambling keys for FLASH and SRAM scrambling.

I don't see any documentation or DIF API calls for software access to the KDI. I'm curious if there are any plans to implement that, or if there is a suitable alternative.

Suppose I have an external SPI flash device that I access via OpenTitan's SPI Host peripheral (on an Earlgrey OpenTitan chip). I would like to encrypt the data on that SPI flash device using a key from (or derived from) OTP. Because that key is secret, it should live in one of the scrambled secret partitions. Therefore, I would need to have access to the KDI to derive keys from material in one of the secret partitions, but that doesn't appear to exist.

I would like to hear any possible existing solutions or potential future solutions for this problem.

On a related side note, I would really like the ability to put my own material to derive keys from into one of the secret OTP partitions. Based on the Direct Access Memory Map table in the otp_ctrl [Programmer's Guide](https://opentitan.org/book/hw/top_earlgrey/ip_autogen/otp_ctrl/doc/programmers_guide.html) documentation, my understanding is that all the secret partitions will have been written to by the time they are sold by the Creator to the Owner. Even if the Creator will flash the Owner's key material in the factory, that leaves questions about the Creator's secret material handling process (e.g. potential retention of key material). So my question is, will the producers of the Earlgrey chip sell me chips that don't have the `CREATOR_ROOT_KEY` flashed so that I as the Owner can flash them myself?

Thank you for your help!

Start with the linked otp_ctrl Theory of Operation and Programmer's Guide, then inspect the existing otp_ctrl DIF API and SPI Host integration. The issue would need a decided, scoped solution for software KDI access and owner-controlled secret provisioning before implementation can be considered done.

Written by the indexing model from the issue text.