There is a brute-forcing possibility if the REE side purposely causes DB update failure after invalid PIN check.

The PKCS#11 TA updates its database on PIN check failure, but not on success, from non-trusted side (REE), we can discard the related media write access (e.g. RPMB write) to prevent PKCS#11 database update.

Trigger the problem

Simplified flow

1. db.pin-counter = 0
2. Pin check failure
3. db.pin-counter = 1
4. save(db)
5. return error

If REE side (REE-FS, RPMB etc) causes step 4 to fail (TA panic), an attacker can retry PIN check with a zero pin-counter on next boot.

1. db.pin-counter = 0
2. Pin check failure
3. db.pin-counter = 1
4. save(db) => discard, panic, reset...

This change ensures that the pin counter is pre-incremented before PIN checking and only cleared on success.

Patches

optee_os.git

• ta: pkcs11: Improve PIN counter handling robustness

Workarounds

Make sure to include the patch above in your builds.

References

N/A

OP-TEE ID

OP-TEE-2023-0002

Reported by

• Linaro (Loic Poulain)

For more information

For more information regarding the security incident process in OP-TEE, please read the information that can be found when going to the "Security" page at https://www.trustedfirmware.org.

Timeline

2023-10-27: Report received.
2023-10-30: Proof of concept code provided.
2023-11-08: Notified Trusted Stakeholders, mitigation patch provided.
2023-11-10: Pull request 6445 merged.
2024-02-02: Issue published and stakeholders notified.