Visible to Intel only — GUID: GUID-0C5146AB-3F38-4AD0-97D2-4A672C7B628A
For API Level 1 - Intel® ME 7.x - Sandy Bridge
For API Level 1.1 - Intel® ME 8.x lite - Sandy Bridge
For API Level 2 - Intel® ME 8.0 - Ivy Bridge
For API Level 3 - Intel® ME 8.1 - Ivy Bridge
For API Level 3 - SEC1.0, SEC1.1, SEC1.2, SEC2.0
For API Level 4 - Intel® ME 9.5, Intel ME 9.5.55 - Haswell
For API Level 4 - Intel® ME 9.1, Intel ME 9.1.35 - Haswell
For API Level 5 - Intel® ME 10.0.0 - Haswell
For API Level 6 - Intel® ME 10.0.20 - Broadwell
For API Level 7 - ME 11.0 - Skylake_LP and Skylake_H
For API Level 8 - TXE3.0 - Broxton, ME 11.5/11.8 - Kabylake_LP, Kabylake_H
For API Level 9 - Intel® ME 12.0 - Cannon Lake
Trusted Application Validation Guidelines
Validating the Manifest
Memory and Performance
Error Handling and Recovery
Functional Validation and Multi-Instance Support
Pack and DALP Generation and Validation
Host-Side Software Validation Guidelines
Trusted Application Management Flows
Error Handling and Recovery Flows
Multi-Instance and Interoperability Testing of Trusted Application Management
General and Platform-Related Events
End-to-End and Setup Validation Guidelines
Cross Trusted Application Interoperability Functional Testing
Creating a New Project
Importing an Existing Project
Converting an Existing Project
Building and Packaging Your Project and Running in Emulated Environment
Running Your Project
Running and Testing on Emulation and on Silicon
Debugging Trusted Applications
Preparing and Submitting Your Project for Signing
Signing an Applet
Signing New Versions
Visible to Intel only — GUID: GUID-0C5146AB-3F38-4AD0-97D2-4A672C7B628A
Secure Display Security Guideline
This page provides useful information when working with the Secure Display feature. For an overview of what the feature does, see the appropriate Features page.
- The S1 key (which is responsible for Secure Display image encryption) and all other keys should be completely random and produced inside the trusted application or on a remote server. If they are generated remotely, they should be passed through a secure channel to the trusted application (refer to crypto guidelines).
- The widgets inside the Secure Display image must be random. This includes not only the buttons, but also where pictures and text appear. The better the randomization, the more secure the Secure Display window is, making it harder for a malware to guess components' locations and try to compromise them.
- Failed user attempts to enter the wrong password, click the right button, and so forth must be logged on the server side and not in the trusted application. This is to avoid an attack where after each failed attempt the trusted application is uninstalled and the counter for the attempts is zeroed.
- Windows form objects appear above the Secure Display window, so this should be taken into account when implementing transaction authorization - it cannot be only an OK button. The transaction approval should include data from the transaction itself.
- Randomization of the 'OK' button is limited in its defense, statistically; about 1 in 20 random presses will hit the 'OK' button (depending on the window/button size ratio), so this cannot be the only security mechanism implemented in the authentication process.
- The Secure Display window is not the top window on the z-order, so a clickjacking attack is possible, in which the malware obtains the user PIN/Password by covering the Secure Display window with its own form and then recording user clicks. This is harmful if the PIN/Password is also used elsewhere - so the Secure Display PIN should be unique and not used elsewhere in the authentication.
Known Issues
- Widgets are added to dialog by reference. It is recommended to use a new instance for each widget added to a dialog, even if the widget appears multiple times. For example, if the same image appears multiple times in a dialog, a new Image instance should be created for each image in the dialog.
- BigImage is released after the dialog is rendered. The BigImage object is obsolete. It is strongly recommended not to use it again.
- BigImage is always rendered as the first layer of the dialog and all other widgets are rendered on top of it.
Limitations
- All widgets and dialog are limited to used width and height not bigger than 4096.
- • Dialog width should be multiple of 32. Using dialogs with a width that is not a multiple of 32 will cause the GFX driver to not display the dialog properly.
- BigImage object can have a single instance at any time. In other words, it is impossible to have two instances of BigImage objects in the system. Image.create() call for the second instance of the BigImage object will fail with an exception. Although, it is possible to have a reference to obsolete instance of the BigImage and create a new BigImage.
Sample one
Image bg1 = Image.create(<BIG IMAGE PARAMS>);
Image bg2 = Image.create(<BIG IMAGE PARAMS>); // Will throw an
// exception.
Sample two
Image bg1 = Image.create(<BIG IMAGE PARAMS>); bg1.releaseImage(); Image bg2 = Image.create(<BIG IMAGE PARAMS>); // OK, bg1 is // obsolete.
Sample three
Image bg1 = Image.create(<BIG IMAGE PARAMS>); Dialog d = Dialog.create(…); ProtectedOutput out = ProtectedOutput.getInstance(…); out.startRendering(d, …); // Render dialog with big image here. // Big image will became obsolete. Image bg2 = Image.create(<BIG IMAGE PARAMS>); // OK, bg1 is // obsolete.
- Line object is described by two points: Start & End. Line object can be one of the following types:
| Line Type | Parameters | Example |
| Horizontal: left to right (0 degree) | Start.X < End.X Start.Y = End.Y | Start = (10, 10) End = (70, 10) |
| Horizontal: right to left (180 degree) | Start.X > End.X Start.Y = End.Y | Start = (80, 10) End = (20, 10) |
| Vertical: top to bottom (270 degree) | Start.X = End.X Start.Y < End.Y | Start = (25, 25) End = (25, 80) |
| Vertical: bottom to top (90 degree) | Start.X = End.X Start.Y > End.Y | Start = (25, 40) End = (25, 10) |
| Diagonal: bottom-left to top-right (45 degree) | Start.X < End.X Start.Y > End.Y ∆(X) = ∆(Y) | Start = (10, 60) End = (60, 10) |
| Diagonal: bottom-right to top-left (135 degree) | Start.X > End.X Start.Y > End.Y ∆(X) = ∆(Y) | Start = (60, 60) End = (10, 10) |
| Diagonal: top-right to bottom-left (225 degree) | Start.X > End.X Start.Y < End.Y ∆(X) = ∆(Y) | Start = (60, 10) End = (10, 60) |
| Diagonal: bottom-right to top-left (315 degree) | Start.X < End.X Start.Y < End.Y ∆(X) = ∆(Y) | Start = (10, 10) End = (60, 60) |
Performance
In order to use less memory when creating Dialog with BigImage, it is recommended to use BigImage with the same size as Dialog size, in such manner, both Dialog and BigImage are sharing the same memory. As the result, the BigImage is used as the first layer of the Dialog and all Widgets will be rendered upon it.