ls -l /dev
on your phone would reveal the 4 distinct areas of the eMMC drive (only one of which, the normal data area, is currently being used). NB: I am using the term ‘area’ here as distinct from ‘partition’. The normal data area is itself split into two partitions but that is different and more vanilla.
Ah, well, being quantum resistant may go beyond the scope of this topic. The key is 32 bytes (256 bits). It’s not an encryption key though. It’s a signing key. The readable content of the RPMB is in plaintext (unless of course the actual original content that you wrote to the RPMB were first encrypted).
The goal of the RPMB is integrity, not confidentiality.
Yes, you must protect this key (keep it secret) for this functionality to be useful. However you don’t need the key to reside anywhere on the phone except when you are actually updating e.g. uboot, which would be infrequent. (So you could e.g. keep it on a flash drive and just plug the flash drive in on the rare occasions that you would use it. Of course it is also essential to keep some kind of backup copy of the key if you intend to use the key.)
I think I am right in saying that Jumpdrive does not (yet) support the RPMB area. The area is not exposed and probably the necessary specialised read and write commands are not supported. So this would mean that you can’t delegate maintenance of the RPMB area to the host computer.
As a hypothetical, you could make the RPMB completely and irrevocably read-only by generating the key, sending the key to the eMMC drive, writing the RPMB area once, and then throwing away the key. For some threat models that would be good.
Vendor keys are, well perhaps I won’t say anathema but, not a good thing. It opens you up to having to trust the vendor. It opens you up to situations where the vendor gets taken over, goes out of business, obsoletes the product. It opens you and the vendor up to situations where the vendor is compromised, either by a hacker or by government coercion.