On Thu, Mar 11, 2021 at 10:22 AM Hector Martin <marcan@xxxxxxxxx> wrote: > On 11/03/2021 09.36, Linus Walleij wrote: > > The typical use-case mentioned in one reference is to restrict > > the number of password/pin attempts and combine that with > > secure time to make sure that longer and longer intervals are > > required between password attempts. > > > > This seems pretty neat to me. > > Yes, but to implement that you don't need any secure storage *at all*. > If all the RPMB did was authenticate an incrementing counter, you could > just store the <last timestamp, attempts remaining> tuple inside a blob > of secure (encrypted and MACed) storage on any random Flash device, > along with the counter value, and thus prevent rollbacks that way (some > finer design points are needed to deal with power loss protection and > ordering, but the theory holds). Yes. And this is what mobile phone vendors typically did. But the nature of different electrical attacks made them worried about different schemes involving cutting power and disturbing signals with different probes, so they wanted this counter implemented in hardware and that is why RPMB exists at all (IIUC). It is fine to be of the opinion that this entire piece of hardware is pointless because the same can be achieved using well written software. The position that the kernel community shall just ignore this hardware is a possible outcome of this discussion, but we need to have the discussion anyway, because now a RPMB framework is being promoted. The people who want it will need to sell it to us. > > With RPMB this can be properly protected against because > > the next attempt can not be made until after the RPMB > > monotonic counter has been increased. > > But this is only enforced by software. If you do not have secure boot, > you can just patch software to allow infinite tries without touching the > RPMB. The RPMB doesn't check PINs for you, it doesn't even gate read > access to data in any way. All it does is promise you cannot make the > counter count down, or make the data stored within go back in time. This is true, I guess the argument is something along the line that if one link in the chain is weaker, why harden any other link, the chain will break anyway? (The rest of your message seems to underscore this position.) I am more of the position let's harden this link if we can and then deal with the others when they come up, i.e. my concern is this piece of the puzzle, even if it is not the centerpiece (maybe the centerpiece is secure boot what do I know). Yours, Linus Walleij
