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.