A mechanism (PoC) to authenticate the Client Application via some OPTEE service

[dashemsec]

Hi OPTEE Team,
w.r.t some query that I raised some times back: #3092

The question remain was What if the CA which is communicating with the TA is malicious.
As per the TEE trusted model, nothing from the non-secure side could be trusted.
There were different solutions mentioned here, like using SELINUX or other LSM's. But they comes with expense of defining rules for each and every components in the linux world.

One better solution I found is, we can use some service of the the OPTEE to authenticate the Client Application before executing.
I have done some PoC related to it, which I tested in Optee QEMU:
Here are my changes:
dashemsec/linux@9c1dfa6
dashemsec@1b75737
dashemsec/buildroot@8e102c5

The PoC contain three parts:

1. Signing the Client Application
2. Kernel Module to call for OPTEE service to authenticate the CA.
3. OPTEE service (pseudo TA) that will verify the signature of the CA.

1. Signing the CA

The signing procedure will consist of:

SIGNATURE = RSA-2048-sign(SHA-256(unsigned CA), TA private key)

The signature along with some additional info (here ref as header), could be added as a new section of the CA elf file. In this PoC I have termed this section as .caauth_sec
Here, I've used objcopy utility to add the .caauth_sec as a new section in the ELF. Refer here.

RSA KEY TO SIGN THE CA
The signing would be done by the same key used to sign the Trusted Application (present in optee_os/keys/default_ta.pem). As per OPTEE model, Public key is hard-coded inside the OPTEE binary during the build itself.

2. Kernel Module to call OPTEE service

The kernel module is written as (linux/security/optee_caauth.c)

The basic kernel security layer (linux/security/security.c), could be used to make our kernel module function call.
So, whenever we execute a linux a.out, while kernel prepares to load the elf, it set up the credential (struct cred) for the task. It lets any active Linux Security Module (LSM) know about the change in credentials.
For that, the linux elf loading function calls security_bprm_committing_creds() , that will call the respective LSM bprm_committing_creds hook.
To learn more, refer https://lwn.net/Articles/631631/

In this PoC, I've added a new member flag caauth_flag, in the struct cred
While the _security_bprm_committing_creds_() calls, _optee_find_and_validate_casignature_() function , module will extract the unsigned elf and signature in some allocated TEE shared memory and pass them to the OPTEE for authentication.
After authentication, module will set the caauth_flag as AUTHENTICATION_SUCCESS or FAILURE.
Now if the CA tries to access the /dev/tee0 or /dev/teepriv0, the caauth_flag value is first checked before processing.
Here is a diagram that explains a lot of it:

3. OPTEE CAAUTH pseudo TA that will verify the signature of the CA

The pseudo TA can be referred here.
Once it receives the unsigned CA elf and the signature as the SHM buffer, from the kernel, it verifies the signature using the TA public key.

RSA-2048-verify(SHA-256(unsigned TA elf), TA public key)

For now, I am successfully tested this PoC in qemu, with some starting kernel crash logs.
Please review this PoC and if it is found to be worthy contributing, I can raise a pull request.

[jenswi-linaro]

The weak link here is that the kernel isn't trusted by secure world. With a scheme like this we can trust the CA as if it was a part of the kernel, but not more than that. So with the trust not extending beyond the level of the Linux kernel it would be enough for the kernel itself to be able to trust that the CA is OK. I suppose it can be convenient to get the key or even verify something in secure world, but it doesn't improve the security significantly.

Another point is that I think we should somehow represent the authentication status of the CA in the TEE_Identity which is passed to a TA. Either via one of the already present TEE_LOGIN_XXX defines or via a new implementation specific. Note that TEE_LOGIN_KERNEL is one its way upstream to the Linux kernel, this define tells that it's the kernel itself that has a session.

[github-actions]

This issue has been marked as a stale issue because it has been open (more than) 30 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 5 days. Note, that you can always re-open a closed issue at any time.