On Thu, Oct 03, 2019 at 09:02:01PM +0300, Jarkko Sakkinen wrote: > On Thu, Oct 03, 2019 at 09:02:32AM -0400, Mimi Zohar wrote: > > That isn't a valid justification for changing the original definition > > of trusted keys. Just as the kernel supports different methods of > > implementing the same function on different architectures, trusted > > keys will need to support different methods of generating a random > > number. > > This is completely incorrect deduction. The random number generator > inside the kernel is there to gather entropy from different sources. > You would exploit trusted keys to potential weaknesses of a single > entropy source by doing that. > > Of course in TEE platform, TEE can be one of the entropy sources but > there is no reason to weaken the security by using it as the only > sources. I.e. where you go wrong is that you are inter mixing requirements for the payload and for sealing. They are disjoint assets. The rules for the payload should not be dependent on how you seal your trusted key. /Jarkko
