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 would welcome if this global legislative push would end up in a more open app ecosystem for iOS overall.
BrowserEngineKit is a thin wrapper over XPC and iOS' extension system. The system would be so much better to develop for if XPC was an open API, and JIT for isolated sub-processes was permitted without Apple's blessing.
* Messengers could have separate sub-processes for preprocessing untrusted inputs -- iMessage already does this, third-party messengers are single-process and cannot.
* Applications could isolate unstable components for better user experience and crash recovery.
* Emulators, e.g. for retro systems, would benefit from speedy emulation.
* WASM would become useful in iOS.
* Browser could use XPC without special-purpose API wrappers such as BrowserEngineKit.
But alas, all of this would make it easier to load code that runs at native speed into an iOS app after a store review happened, and as we all know that'll be the end of the world.
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...