Finding a Trusted Path in Un-Trusted Computers

Tuesday, September 07, 2010

Eli Talmor


In my previous blog on Malware-resilient Software-as-a-Service Strong Authentication the issue of trust was raised. The current blog quotes publication named  Extending the Trusted Path in Client-Server Interaction by Hanno Langweg and Tommy Kristiansen.

Interacting with the local human user is the weak point in client-server communications. While machines can employ crypto-graphical mechanisms to ensure authenticity, integrity, and confidentiality of communication, humans are not capable of this. They rely on their local computer to present data and transmit their input to a server reliably. 

Today’s operating systems provide protection against unauthorized modification of operating system components and offer mechanisms like discretionary access control and process separation to users and processes. Often, all processes of the same user operate with the same privileges. 

Malicious software (malware) can exploit this fact to read input destined for other processes (e.g. a key-logger) or modify the output displayed to the user (e.g. local phishing attack).A server application needs a trusted path to the user at a network node.

This concept is not new and exists in operating systems. The secure attention sequence Ctrl+Alt+Del in MicrosoftWindows is an example of how the user can invoke a trusted path to the operating system to log on.

Output of a trusted path cannot be manipulated by other processes and input cannot be read. The process using a trusted path can be sure that input and output are shared only with the user.

Trusted Path definition: A mechanism by which a person at a terminal can communicate directly with the Trusted Computing Base. This mechanism can only be activated by the person or the Trusted Computing Base and cannot be imitated by untrusted software.

In the Microsoft Windows operating system, applications typically receive information about user actions by messages. Since these can be sent by malicious programsas well, they are a convenient attack vector. It is a vulnerability by design – Windows treats all processes equally that run on the same desktop.

If one needs an undisturbed interface, a separate desktop attached to the interactive window station should be assigned.  However, managing separate desktops can be cumbersome for software developers.

So most of today’s software that interacts with a local user runs in a single desktop shared by benign and malign programs. A number of applications today are structured after the client-server pattern: internet banking, contract signing, e.g. in e-government, or online voting.

Here, the main application is run on highly protected servers. Users connect to the server from their local machine. The machine acts as a smart terminal, collecting user input, transmitting it to the server, receiving server data and displaying server output.

The local user initiates and completes transactions with the server application. The user interacts with a local application via the local user interface. Some problems immediately arise:

1. How do user and application know which server they are talking to?

2. How does the server know which application it is talking to?

3. How does the user know which application input is directed to?

4. How does the user know which application produces the output?

5. How does the application know that user received the output?

6. How does the application know where input comes from?

The first two problems can be solved by using a cryptographic protocol that offers secure authentication of the communicating parties and integrity of the communication, e.g. SSL.

The strength of the cryptographic algorithm relies on access of the adversary to encrypted data and on it being computationally infeasible to decrypt the data or forge a digital signature.

The remaining four questions demand a trusted path between the local application and the user. The local user interface is the weak link in the interaction of the user with the server application.

An adversary is much more likely to attack here than spending resources on breaking a cryptographic algorithm – breaking cryptography is typically either a formidable mathematical challenge or requires a large amount of computing resources.

Attacks on the server are another option. However, a server is usually easier to protect than a large number of clients.

It may be possible to distinguish users and untrustworthy programs by observing their input behavior…

Our approach:

Our approach to finding trusted path does not rely on particular PC architectural strengths or weaknesses but rather on basic limitation on malware.

Limitation 1: Physically speaking  to the PC microphone is impossible for any  program residing on the  same PC.

Therefore client authentication software, requiring the user to actually speak to the PC microphone will be able to establish a trusted path to the authentication server.

On the other hand malware residing on the same computer will not be able to complete the authentication, even though it collected all necessary digital information, through key-loggers, etc…

Fig.1 : Malware un-capable to speak to PC microphone.


Limitation 2: Manipulating displayed data by one program is detectable by another program.

Protecting integrity of the information displayed to the user from being manipulated by malware is another issue. In the case malware does not care much to attack authentication mechanism, all it cares about is manipulating display.

If all processes share the same display, then it is possible to detect the discrepancy between the data presented to the user for his/her confirmation and the data being actually digitally signed.

Here again we are taking the physical path – malware can manipulate display, but this manipulation can be detected.

Fig.2 Malware is capable to manipulate display, but un-capable to steal transaction.


Possibly Related Articles:
Operating Systems
Information Security
malware Network Access Control
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.