This article is probably not correct. The actual behavior is documented [1]:
> BitLocker hashes the user-specified personal identification number (PIN) by using SHA-256, and the first 160 bits of the hash are used as authorization data sent to the TPM to seal the volume master key.
So what's actually happening is that the PIN is used to derive an authValue passed to the TPM, which compares it to the expected value, and can trigger lockout on too many mismatches.
I can't find specifics to how Windows configures the TPM wrt. lockout, but the mechanism described in the article appeared fishy to me, and contradicts official docs. It also would not make sense that TPM+PIN was known to be safe against bus sniffing attacks if it would still reveal all data required to brute-force the PIN.
Is this LLM slop? One cannot truncate RSA signatures and still check them. The sample hook code is nonsense, it lacks an address to hook (and would break Enigma‘s self-checks). The sentence structure and all lower-case looks like a bad prompt attempt to hide LLM usage.
That's including the enterprise premium for software, hardware support, and licenses. Building this in-house using open source software (e.g. Ceph) on OEM hardware will be cheaper by an order of magnitude.
You of course need people to maintain it -- the $300k turnkey solution might be the better option depending on current staff.
I'd argue that Apple fails to offer a secure way of verifying the signature: Finder only shows me that an app is signed when I first run it. It does not provide me with a signer name or team ID that I can match with information I got from the developer.
The information is available via command line by running "codesign -dvv", or by installing a Finder extension such as WhatsYourSign [0].
> BitLocker hashes the user-specified personal identification number (PIN) by using SHA-256, and the first 160 bits of the hash are used as authorization data sent to the TPM to seal the volume master key.
So what's actually happening is that the PIN is used to derive an authValue passed to the TPM, which compares it to the expected value, and can trigger lockout on too many mismatches.
I can't find specifics to how Windows configures the TPM wrt. lockout, but the mechanism described in the article appeared fishy to me, and contradicts official docs. It also would not make sense that TPM+PIN was known to be safe against bus sniffing attacks if it would still reveal all data required to brute-force the PIN.
[1] https://learn.microsoft.com/en-us/windows/security/operating...