Develop programs for Arm trust zone

不羁岁月 提交于 2019-11-28 20:55:14
artless noise

There are two extremes. These are documented in the Software overview chapter of ARMs Security Technology: Building a Secure System using TrustZone Technology.

APIs

At the one end of the spectrum, there is only a set of APIs which can be called from the normal world. This is detailed in the SMC calls for Linux. For instance, if the device contains a public-private key, an API call could sign data. The normal world would never have access to the private key, but anyone can verify that the device is original by verifying the signature. So the normal world is free to forward this request over any communications interface. This maybe part of authenticating a device.

Co-operative OSs

In this mode, there is a full blown OS in both the secure and normal world (called TEE and REE elsewhere). The OSs must co-operate with interrupts and scheduling. They may also use SMC calls, lock free algorithms and semaphores along with shared memory.

ARM recommends using the FIQ for the secure world and to leave the IRQ for the normal world. Specifically, there are settings to stop the normal world from masking the FIQ ever. All of these issue rely on the type of IPC, scheduling, interrupt response, etc that the system needs.

The simplest Secure scheduler would always pre-empt the normal world. Only the idle task would yield the CPU to the normal world. A more flexible solution would have the schedulers co-operate so that both worlds can have higher and lower priority tasks.

The better way is install a REE OS and a TEE OS in one device. When a program wants to do some sensitive things, the device will change to TEE OS, so you can deal with sensitive date securely. When you have done with sensitvie date, device will change to REE OS. But implementing two OS switch on a device is a tough work.

Operating Systems such as MobiCore already exist and have been deployed on mass market devices such as Samsung Galaxy S3.

MobiCore is an OS that runs alongside Android, so trustlets (= MobiCore apps) can communicate with Android apps via a set of system calls to the MobiCore driver, which is the part of the Android OS in charge of communicating with the trusted execution enviromnent.

If you are looking to develop trustlets for MobiCore as explained above, you must become a MobiCore developer, which you could theoretically do by signing up as a developer for MobiCore's Trustonic venture.

If you wish to use ARM's TrustZone technology on your own device / dev board with an open-source secure OS, perhaps you can use OpenVirtualization's SierraTEE, which seems to be compiled for Xilinx Zynq-7000 AP SOC and also compatible with Android as the rich OS.

You can use OPTEE(Open Sourec Portable Trusted Execution environment) OS. If you are looking for trusted execution environment application examples, which are also know Trusted Applications(TA), then you can check this optee trusted applications examples repository and this TA using OP-TEE and Comcast Crypto API.

  • Optee os provides following APIs for writing Trusted Applications:
    • Secure Storage APIs for secure storage
    • Cryptographic Operations APIs for encryptiion, decryption of secure credentials and data
    • Secure Element API which help in hosting applications or applets on tamper-resistant platform
    • Time APIs
    • Arithmetical APIs For client side or normal world optee provides:
  • Tee client side Apis

You can refer documentation here.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!