Detection of software changes on a 1st machine by a 2nd machine across the network is difficult since the 2nd machine cannot directly observe the software executed on the 1st machine. As shown in Figure 1, in order to solve the problem, the 2nd machine should receive some "proofs" regarding the authenticity of the software that is running on the 1st machine. Such "proofs" are hard to obtain since the 2nd machine often receives only data from the 1st machine, while what is actually needed by the 2nd machine is to receive signatures (or attestations) continuously from selected parts of the software running on the 1st machine, i.e., selected applications and protocols that are executed on the 1st machine. The signatures (or attestations) will thereby authenticate the respective selected software parts executed on the 1st machine. In other words, the signatures that are continuously emanated from selected parts of the software on the 1st machine provide the "identity" of the running software and thereby enabling the 2nd machine, after validation, to entrust the software running on the 1st machine.

However, today selected applications and protocols that are developed and deployed on such 1st machines are not designed to emanate signatures (or attestations) continuously. In essence this is a paradigm shift and one of the main scientific/technical challenges introduced in the proposed RE-TRUST project.

Figure 1: Entrusting by remote software authentication during execution

As stated before, networking and computing are converging into one system, various security and trust problems are emerging. The core of the remote entrusting principle (or entrusting, for short), presented in this research project, is:

"To utilize trusted entities in the system/network (firewall, interface, server, protocol client, etc.) in order to entrust selected software components in otherwise untrusted machines across the network, assuring their on-line/run-time functionality."

Namely, entrusting is based on the assumption that there are trusted entities in the converged system of networking and computing (obviously, if nothing can be trusted, building any trust relationship is not be feasible).

The term "untrusted machine" implies that a malicious user has access to system resources (e.g., memory, disks, etc.) and tools (e.g., debuggers, disassemblers, etc.) on the 1st untrusted machine, and consequently, is capable of tampering/modifying the authentic (i.e., original) code prior to or during execution. In other words, the objective is that a 2nd entrusting machine (e.g., "Core of Trust" - see Figure 1) will entrust the 1st untrusted machine by "authenticating its execution" (i.e., in real-time). Indeed, the execution of software (code/protocol) is authentic/trusted if and only if its functionality has not been altered/tampered by an untrusted/unauthorized entity, both prior to execution and, more importantly, during run-time.

Finally, note that the basic remote entrusting scheme depicted in Figure 1, can be extended to contemplate:

• Mutual remote entrusting: where the 1st and 2nd machines are entrusting one another.
• Transitive remote entrusting: where a 1st machine is entrusting a 2nd machine and a 2nd machine is entrusting a 3rd machine.