Signal threat model is well defined: your communications are protected even from a rogue server. It follows the Kerckhoff's principle, a crypto system should be secure if everything, except the keys, is public knowledge.

This is why jurisdiction is nearly irrelevant to the security of encrypted messaging apps

The only security property the server should be able to impact is availability, which is why the jurisdiction actually matters a bit, specially when the said jurisdiction imposes embargoes to your region. A good encrypted messaging app is one you can use.

With such a threat model, there is no need for a Trusted Execution Environment (TEE) like SGX, which is supposed to ensure the storage is accessible to attested programs only. So, why Signal does need a TEE?

TL;DR

Signal uses your PIN to encrypt and upload your keys; set a high-entropy PIN (+20 random alphanums) to stay resistant to brute force and dictionary attacks if the PIN infrastructure is ever compromised.

Account and identities

When you register on Signal, you get 2 different identities: one for your phone number, the PNI, and another for you account, the ACI.

The application generates 2 identity keys (IK) during the registration, one for each identity. And these keys are the root of all the session keys encrypting and protecting your communications.

The safety number you can use to verify a contact is generated from your and your contact IK.

After generating the identity keys, the mobile application generates prekeys that are signed by the IK and stored on signal server. These prekeys are used by other users for a first contact, to calculate a shared secret. These prekeys are what allows you to be contacted when you're not online. When the session keys with a contact are desynchronized, your contact picks new prekeys and calculate a new shared secret.

Keeping these IK secret is mandatory to avoid Adversary-In-The-Middle. If the server has access to the IK, it can send your contact prekeys it has generated. Doing it allows the server to decrypt incoming messages, and forward them re-encrypted with a legit prekey you have generated.

Registration lock

The registration lock is a feature that prevent someone to re-register to Signal with your phone number.

If someone re-register with your phone number, and you didn't enable registration lock, a new account is created for them, with your old PNI.

They will use a new ACI and new IKs. So your contacts who haven't updated your phone number will see that the account with your (old) phone number has a new identity.

Your safety number with S1m has changed.

This warning is a solution good enough to warn about something suspicious. Or it may be expected when your contact has yet again lose their phone (👀).

But most people don't really look at the safety number: taking over a phone number may be enough to impersonate the person.

This is concerning because SMS aren't secure:

1. they are vulnerable to SCAM like SIM swap
2. they aren't encrypted and can be read using an IMSI catcher, or by your ISP (Don't use SMS as a 2FA).

To protect against SMS attacks, Signal gives the registration lock: you set a PIN to protect your account, and Signal will require this PIN to use the registered phone number.

As people may change their phone number, the registration lock expires if someone re-register with the phone number and the account has been inactive for 7 days.

Account recovery

So, what happen when you are restoring your account on a new device? You enter your phone number, receive an SMS, resolve a couple of captchas and? You verify your Signal PIN.

For this, the application will interact with the Secure Value Recovery (SVR), part of the Signal server. To prove the knowledge of the PIN, the application hashes the PIN with the argon2i algorithm (salted with the ACI, and the enclave id), and split the result in 2 different keys: the SVR access key, and the SVR encryption key.

The access key is used to request the SVR to download the encrypted masterkey. Which is the masterkey, encrypted with the SVR encryption key.

The masterkey is decrypted, and the recovery password is calculated from it. If registration lock is enabled, the registration lock token is calculated too. Then the application request the Signal server to finish the registration using the recovery password and the registration lock token.

The application download the encrypted account data (including encrypted IK) stored on the storage server. And decrypt them with a key derived from the masterkey.

You can now talk to your peers, and none of your safety numbers has changed.

Trusted Execution Environment ?

The SVR is one of the components using the SGX (Intel Trusted Execution Environment). Why? Because as we've seen above, the masterkey is stored there encrypted using a potentially very weak secret: the Signal PIN.

Using a TEE is an answer to this use of the PIN. It allows the client to verify that the code running on the enclave is the one expected, and the TEE should prevent any code outside the enclave to access its data. The certified code limits how many times you can request the service, so it should be impossible to guess the access token (and the PIN).

But, this is a huge shift in the threat model. Remember? Your communications must be protected even from a rogue server. It should be secure if everything, except the keys, is public knowledge. Now, if you use a weak PIN, your identity relies on the security of the SGX.

If an attacker can bypass SGX security: they can download your encrypted masterkey, and guess your PIN: Argon2id is pretty slow, but the PIN requirement is only 4 digits, making brute force attacks possible. Then it is possible to download and recover the account data, including the identity keys. Finally a rogue server could upload its own prekeys and start an Adversary-In-The-Middle attack.

And of course, SGX isn't immune to vulnerabilities (just random links):

• https://sgx.fail/
• https://www.intel.com/content/www/us/en/security-center/announcement/intel-security-announcement-2025-10-28-001.html
• https://nvd.nist.gov/vuln/detail/CVE-2025-38334

Weak PIN requirement

The registration lock is older than the account recovery. (cf. the migration to PIN v2)

When the PIN was only about the registration lock, it was OK to use a 4 digit PIN, as its purpose was to protect against an external attacker trying to take over a phone number identity (but not over the ACI and the IK). At this time, the PIN was sent unencrypted, and was probably stored hashed on the server, as we usually do with passwords.

When the PINv2 and the account recovery were introduced, the requirements were changed: new PIN needed to be 6 digits and more.

The old PIN (which were sent unencrypted to the server) were directly used for the new recovery system, they were used to encrypt and send the master key to the SVR.

But then, the PIN code was cleaned up, and the new requirement was dropped and stayed 4 digits until then.

Recommendations

I am sure some users have a weak PIN thinking it is only about SMS attacks. But it is arguably more risky to use the registration lock with a weak PIN than not using a PIN.

I think users are used to set "long" alphanum passwords everywhere, and it wouldn't be a friction to users if Signal were increasing their requirements, especially when the PIN isn't required.

With the introduction of the new cloud backup, Signal asks the user to write down the root of other secrets (the AEP) which is probably going to replace any use of the PIN. So, it looks like Signal is already working to totally get rid of this.

As you likely have a password safe, generate a high-entropy PIN (+20 random alphanums) and you're good.