@clever
“A register that is set to zero at boot. If I keep it at zero then the OTP is readable. If I write 1 to it, reading the OTP will return only zeroes until next reboot. Writing anything but 1 to it has no effect whatsoever”.
To me it seems simple enough to implement this in hardware, but then again I am not a hardware guy.
Something of that kind would increase the security of OTP and secure boot by quite a bit.
What kind of increased security would a “secure element” add to it? I am asking simply because I don’t know.
That is similar to how I am thinking: I am not a hardware guy, but it seems simple enough to have something like the following in hardware.one complaint ive had with the OTP key mechanism
i want there to be a way to lock reading of the keys until a reboot has completed
if that is done, then gaining root after the luks unlock wont give them access to OTP
so the thread surface is drastically reduced, to just the initrd and luks unlock process
but if the attacker has /dev/mem access, they could still undo that, so it depends on how youve built your kernel
“A register that is set to zero at boot. If I keep it at zero then the OTP is readable. If I write 1 to it, reading the OTP will return only zeroes until next reboot. Writing anything but 1 to it has no effect whatsoever”.
To me it seems simple enough to implement this in hardware, but then again I am not a hardware guy.
Something of that kind would increase the security of OTP and secure boot by quite a bit.
What kind of increased security would a “secure element” add to it? I am asking simply because I don’t know.
Statistics: Posted by yaw moo — Tue Jun 11, 2024 12:31 am