undefined | Better HN

0 pointsmindslight10y ago0 comments

It certainly means the bruteforce inhibiting was insecure.

0 comments

Explain.

Include in the explanation how removing code makes the prior state insecure.

If an attacker can modify the code, they simply nullify that check (as we're discussing here). The prior state was insecure because the whole point of crypto/trusted hardware is to prevent against such attacks, and the prior state should have never allowed a code update on a locked device (if we're talking about trusted hardware).

If we're not talking about trusted hardware, then naive code which calls sleep() is defective for the same reason - the security of the system cannot depend on running "friendly" code. See Linux's LUKS which has a parameter for the number of hash iterations when unlocking, which sets the work factor for brute forcing.

If this still isn't apparent, you need to try thinking adversarially - what would you require to defeat various security properties of specific systems?

cmurf10y ago

An attacker can't modify the code. The code isn't public. Only the sole keeper of the code can modify the code, it's proprietary software. Further the code is signed by author's private key, so even if an attacker could modify compiled code (via a decompiler for example), they still can't inject that modified code into the hardware without signing.

2 more replies

j / k navigate · click thread line to collapse

0 comments

cmurf10y ago

Explain.

Include in the explanation how removing code makes the prior state insecure.

mindslightOP10y ago

If this still isn't apparent, you need to try thinking adversarially - what would you require to defeat various security properties of specific systems?

cmurf10y ago

2 more replies

j / k navigate · click thread line to collapse