Trusted Execution Environment

Full Title or Meme

For any digital Entity to make trustworthy statements, it must have fully protected cryptographic means to sign any statement that it issues and evaluate any command that it receives.

Context

Early History

The origin of computers built with any sort of trusted execution is an IBM 7094 with two separate memory banks with a switch that was designed and built at MIT to support CTSS, the Compatible Time Sharing System. One bank ran kernel code and the other user code, although those were not the terms used at that time. The following quote describes the changes made for MIT.

• The hardware RPQs that made CTSS run on MIT's 7094s added an interval timer (B/M 570220) and memory boundary and relocation registers (RPQ E007291) to the 7094 processor. In addition, the MIT machines had two 32K core [36 bit word] memory banks instead of one (RPQ E02120). Core bank A held the CTSS supervisor, and B Core was used for user programs. (RPQ stood for Request Price Quotation. IBM, in those days, would engineer and sell features not part of the standard product, for a price.) More importantly, the RPQ made the 7094 a two-mode machine. When the machine was running a program in B-core, many instructions were forbidden: executing them caused the machine to trap and take its next instruction from A-core. In particular, I/O instructions were forbidden, as well as attempts to switch core banks.

The following quote is a description of the method to switch between user (slave) and kernel (master) modes in the GE 645. Which was designed by MIT & GE specifically to take over operation of the CTSS. It was later replaced with the Honeywell 6180 that had modest success running the Multics operating system.

• Because it was felt desirable to make it possible to branch easily between various programs including between slave and master programs, a certain degree of insurance has to be built into the hardware to guarantee that spurious branches would not take place into the middle of master mode programs from slave programs. As a consequence, a master mode procedure when viewed from a slave mode procedure appears to be a segment which can neither be written nor read. Further, the only method of addressing this segment that is permitted is a branch to the 0th location. Any attempt to get at other locations by branch, execute, return or any other instructions will result in an improper procedure fault causing an appropriate interrupt.

IBM did not want to be left out of the time-sharing market and so built the 360/67 to support time-sharing. It did not fit into their normal marketing program and was not successful in the same way that the rest of the 360 line of computers were.

A1 classification

The Orange Book defines Class (A1): Verified Design as meeting the highest level of security of other classes with the "distinguishing feature that an analysis derived from formal design specification and verification techniques and the resulting high degree of assurance that the TCB is correctly implemented."

Co-processors

Co-processors or management processor are not a new idea. Even the Data General Eclipse mini-computer system released in 1974 came with a management co-processor on the mother board. What is most interesting is that the Eclipse served as a Maintenance and Control Unit (MCU) for the Cray-1 supercomputer. Layers upon layers.

Solutions Today

Common TEE Platform APIs

The Global Platform standard for a Trusted Execution Environment (TEE) is designed to reside alongside the normal smartphone or other Mobile Device Rich Execution Environment (REE) (where normal applications execute) and to provide a safe area of the Mobile Device to protect assets and execute trusted code. At the highest level, a Trusted Execution Environment (TEE) is an environment where the following are true: (a) any code executing inside the TEE is trusted in authenticity and integrity; (b) the other assets are also protected in confidentiality; (c) the TEE resists by design all known remote and software attacks, and a set of external hardware attacks; and (c) both assets and code are protected from unauthorized tracing and control through debug and test features

Access APIs

• Before any of the functionality of the Trusted Execution Environment or Trusted Computing can have a measurable effect on user security, the functionality must be exposed to the programmers that code the applications that the users want. There are a few APIs, like Open SSL which are accessible to the programmers, but the key problem of protecting keys used by applications programs is still fragmented. The following are the most important APIs addressing that issue.

Windows

• Fairly early in the adoption of Public Key Cryptography Microsoft licensed the RSA API library and exposed it to programmers as a part of the Crypto API (CAPI). This had the advantage of abstracting all of the underlying key protection methods and so was quite successful. Unfortunately it was strongly oriented towards the Public Key Infrastructure (PKI) build around the X.509 Cert and its binding between the user and the private key. This clumsy design based on bindings has frustrated users and programmers for decades. It was partially corrected by the Crypto Next Generation (CNG) API which was more closely bound the the important part, the public key itself.

References

External Material

1. OWASP TrustZone and Mobile Security https://www.owasp.org/images/c/c8/OWASP_Security_Tapas_-_TrustZone%2C_TEE_and_Mobile_Security_final.pdf
2. Android Trusty is a set of software components supporting a Trusted Execution Environment on mobile devices. https://source.android.com/security/trusty/