It's possible to set a strong passphrase as this PIN and avoid depending on SGX security. The issue is how they've converted an existing feature, the lack of a proper explanation for users, their dismissive response to valid criticisms about it and inaccurate/misleading claims.
Conversation
The experience of the registration lock PIN being converted to this resembles dark patterns used by Facebook. It wasn't clear even to highly technical people what was happening and what the new PIN they were creating was doing. It is STILL a problem with them adding an opt-out.
1
2
10
They did such a good job designing features like link previews and profiles in a privacy-preserving way. Don't understand how they go from that to this. Bonus of a response resembling a cover-up hand waving away the criticism + blocking people with legitimate questions/concerns.
1
3
12
A weak PIN was fine for the registration lock feature, but it doesn't work well as a way of deriving a meaningful encryption key. Adding a way to opt-out doesn't change that they encourage doing this and it looks like you won't be able to just set a registration lock like before.
2
1
11
This Tweet was deleted by the Tweet author. Learn more
This Tweet was deleted by the Tweet author. Learn more
Replying to
I already suggested that but it doesn't change that this is a problem and that the weak PIN does not offer meaningful encryption. SGX is known to be broken. They don't need to come up with new ways to break it. SGX attestation is also not what people seem to think it is.
1
Attestation is not all equal. Verifying based on a root of trust might be good enough for DRM, anti-cheat, etc. but not real security. A key can be leaked by an employee or it can be leaked from the oldest, least secure hardware implementation with no firmware updates applied.
1
Attestation based on proper pairing is much better, but not what SGX attestation provides. However, using it to try securely running code on a computer controlled by an adversary? That just seems foolish. Doing it with SGX which isn't even a secure element is doubly foolish.
1
Every Intel CPU ships with a key usable to do SGX attestation. You only need to obtain a key from the weakest link. Revocation is not a serious response to this. A proper, secure attestation implementation has to do some kind of pairing and ideally has a unique key per device.
1
Otherwise how is this any more secure than DRM based on provisioning keys to secure elements across a whole bunch of cables boxes, etc. Pretend they had a real secure element to run the code on. Even then, attestation based on a root of trust is a huge weak link in the system.
Pairing would be difficult since then they couldn't just swap out servers without updating the app. Also, tends not to be supported by these things. I think using a secure element to implement features you'd otherwise do different is a huge mistake though. They are a nice...
1
... way to reinforce a design as a bonus layer of security provided by hardware. That's different from deploying a feature in a way that's substantially different from what you would have done if you couldn't rely on a secure element - and SGX is not actually a secure element...