Intel® Dynamic Application Loader (Intel® DAL) Developer Guide
Visible to Intel only — GUID: GUID-56F01FC8-CA2C-43A3-8444-FA704AFD9CC5
Visible to Intel only — GUID: GUID-56F01FC8-CA2C-43A3-8444-FA704AFD9CC5
Security Guidelines
All trusted applications must be signed by Intel before they can run on a development machine. See Signing Process for instructions.
Trusted Application Guidelines
- The data flow between the host software and the trusted application is not secure by design, so nothing secret should be passed between software and trusted application unless encrypted in some manner. Furthermore, it is important to understand that the software is outside of the trust boundary, so in general nothing secret should be generated, processed or stored in it.
- If sensitive data needs to be passed to the trusted application, it should be passed from a trusted remote server, and not from the host software. For this, a secure channel between the trusted application and the remote server needs to be established, so the software in the middle can't interpret the data.
- Nothing secret should be stored on the trusted application permanently (i.e. hard coded in the pack file). In general, anything hard-coded in the pack file is open for viewing by various tools so secrets should not be constant.
Manifest
The manifest should limit the trusted application privileges to the minimum necessary for it to function.
- Event.post and Event.register fields should be minimized so that the trusted application is not exposed to events by other trusted applications, or pose a risk to other trusted applications. Furthermore, it is important to closely monitor the event values so that they do not collide with other trusted applications.
- If used, applet.cpu.whitelist.flag and applet.pch.whitelist.flag should preferably be set to true. As a general security guideline, white listing is always better than black listing, as it is more specific about exactly what is allowed.
Security Version List
Beginning with API Level 7, the Security Version List is separated from the trusted application package and managed by the admin UpdateSVL command.
Certificates
It is the trusted application's responsibility to validate the contents of a GetInfo() result against the expected contents of such a call.
There are given GetInfo() function extensions that are allowed to be defined as critical. If a critical extension is not on the accepted list, the certificate will be rejected.
The following extensions are allowed to be critical:
- Basic Constraints
- Name Constraints
- Key Usage
- CRL Distribution Point
- Subject Alternative Name
- Extended Key Usage
- Application Policies
It is the trusted application's responsibility to query each of the GetInfo() function extensions in the list below; determine which are critical and then call the appropriate GetInfo() function to handle the extension at the trusted application level.
The following extensions will be queried by the trusted application to see if they are defined as critical:
- Key Usage
- CRL Distribution Point
- Subject Alternative Name
- Extended Key Usage
- Application Policies
In addition, CertificateChain.Verify() only checks for signature verification. All other certificate checks are the responsibility of the trusted application, e.g. null characters in the certificate subject in a null prefix attack.
Cryptography
Follow known standard security guideline for each cryptography protocol.
SIGMA and EPID
- Use SIGMA 1.1 when possible and not SIGMA 1.0.
- Use the Signature Revocation List (SIGRL) (recommended but not mandatory).
Timers
Under development
Events
Under development
WYSIWYS
- S1 key (which is responsible for WYSIWYS 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. See Cryptography.
- The widgets inside the WYSIWYS 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 WYSIWYS window is, and the harder for a malware to guess components' location and try to compromise them.
- Failed user attempts to enter the wrong password/click the right button etc. must be logged on 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 from objects appear above the WYS window, so this should be taken into account when implementing transaction authorization - it cannot just be an 'OK' button. The transaction approval should include data from the transaction itself.
- Randomization of an '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 WYSIWYS window is not the top window on the z-order, so a clickjacking attack is possible, where the malware gets the user PIN/Password by covering the WYSIWYS window with its own form and then recording user clicks. This is harmful if the PIN/Password is also used elsewhere - so WYSIWYS PIN should be unique and not in use elsewhere in the authentication.
Software Guidelines
General
All software should be compiled using all the compilation security flags (NX,GS,SafeSEH…), these flags incorporate important security mechanisms into the program, and make it harder to exploit. Compilation with these flags can be verified using the BinScope binary analyzer.
Intel® DAL Host Interface Service
- When loading the JHI.dll, the software should implement mechanisms to avoid DLL hijacking, such as using an absolute load path. For a KM on how to prevent DLL hijacking, refer to Microsoft Guidelines.
- When an application loads the JHI.dll, the application should validate the .dll's signature.