Hashing and Authentication Engine


Currently, most malicious code detection technologies employ a “permit all, except” model, where all code is allowed to execute unless it is on a list (a signature file) of known, malicious code. If a signature-based malicious code detection technology does not have an original example of malicious code, it cannot derive a signature. Unknown, or hitherto unseen malicious code can defeat a signature-based approach.

The technology proposed in this paper is based on a “deny all, except” model, where all code is denied execution unless it is on a list of authorized code. Such an approach does not depend on having examples of all forms of malicious code, and is capable of detecting unknown, and possibly malicious code because the suspect code is not on the list of authorized code.

Clearly, the “deny all, except” model is more effective than the “permit all, except” model.


The COTS program under consideration in this paper uses a technique called “authenticated execution”. The idea of authenticated execution is that before a program loads into system memory, a cryptographic hash of the program is generated and is compared against a database of cryptographic hashes of all authorized executables for the system. If the program’s hash matches an authorized hash, the executable is permitted to load into memory. If the program’s hash does not match that of any authorized executable, the program is not allowed to load into memory and execute. Also, when an unauthorized program is detected, both its cryptographic hash and a notification of a security event are sent to the COTS program’s security management console.

The fact that the cryptographic hash of the unauthorized executable is sent to the COTS program’s security management console is of particular significance. It means that a database of the cryptographic hashes of known, hostile executables can be prepared and the cryptographic hash of the unauthorized program can be compared against the database. If there is a match, then investigators will know that someone (or some process) tried to execute hostile code on a specific system. This knowledge would allow investigators to open an investigation to determine the circumstances surrounding this suspicious event. In effect, the COTS program (suitably enhanced) becomes a distributed sensor for hostile activity by trusted insiders.


A key element in the concept proposed in this paper is the creation of the database containing the cryptographic hashes of known hostile code. Examples of known hostile code will fall into two categories; unclassified system exploit or communications tools commonly found on the Internet, and classified FIS system exploit or communications tools that have been obtained by US intelligence agencies.

The process of populating the database will require collecting a large set (as large as possible) of hostile code tools obtained from both the Internet, and from US intelligence agencies. Every tool will need to be run through a hashing function (SHA1 is the default function for the COTS software), and the resulting hashes will be entered into the database.

Note: Because the hostile code database will contain only cryptographic hashes, it will be completely unclassified. Further, US intelligence agencies that may be reluctant to provide actual classified FIS tools that have been collected during US intelligence operations, may instead be willing run the FIS tools through the SHA1 hashing function themselves and contribute just the hashes to the hostile code database.

There is an additional benefit of the fact that the hostile code database will contain only unclassified cryptographic hashes. Because the hostile code database will be unclassified, it can be on-line and available for real-time hash matching. This means that the moment a hostile insider tries to execute any type of unauthorized code, the cryptographic hash of that code can be matched against the hashes in the hostile code database.


If adopted, the techniques proposed in this paper would enable investigators/analysts to:

  • Detect & observe the activities of a hostile insider
  • Enable a centrally managed, espionage detection, analysis and exploitation center
  • Determine the extent and nature of hostile insider activities
  • Analyze the technical tradecraft used in cyber-espionage
  • If the counterespionage capabilities are intended to remain undisclosed, the COTS program’s information assurance benefits provide ready-made cover for the presence of the COTS software
  • If the counterespionage capabilities are publicized, the presence of the COTS program serves as a deterrent to espionage


If adopted, the COTS software described in this paper could:

  • Stop all unauthorized code – even unknown attacks
  • Provide enterprise situational awareness of unauthorized executables
  • Permit rapid analysis & response to threats
  • Enable centrally managed host based sensors for unauthorized code
  • Reduces virus entry vectors
  • Provide enhanced system security without depending on training or policy adherence
  • Control configuration management & maintain accreditations (unauthorized installation programs won’t run)


There is a demonstrated need for a capability to detect trusted insiders when they attempt to run unauthorized, possibly hostile software tools. The COTS software described in this paper, suitably enhanced with a database of known hostile code, could provide such a capability.

In order to test and refine the hostile activity detection capabilities described above, recommend that a government sponsor field a small pilot project to measure the effectiveness of the technical investigation concepts discussed in this paper. Part of the project’s evaluation criteria should include the controlled introduction of known hostile code to test the core concept of the project.

The project sponsor should also consider deploying the project technologies to several different organizations to test its capabilities in diverse technical environments and to increase the chance of detecting real hostile insider activity.

The scope and specific capabilities of the proposed pilot program can be further defined in a detailed statement of work, to be provided upon request by a government sponsor.