Antivirus Hashes improved – a feasible protocol

I suggested the idea of maintaining a database of hash values generated at program install, to improve anti-virus efforts. Kerckhoffs’s principle, suggests that this scheme cannot practically be made secure, without a password upon which it may depend for secrecy.

A theoretical implementation would maintain a database of hashes made at install time “RootHash,” and that database would be verified by a hash of the hashes, “OSchecksum.” Then, at launch of every program the antivirus would hash the executable object code, and compare it to the relevant counterpart in the RootHash list (although merely checking if it was somewhere in the list, would ensure that it was not merely another authorized program, re-named.) If the antivirus calls for a password at every program launch, the whole process would become a horrible nag, and humans would bypass the system as an impediment.

Moreover, a determined bad actor would simply replace the relevant hash, after some investigation to locate the list, and (if necessary,) rehash the OSchecksum verifier.

Since that doesn’t satisfy the equation, we could observe that passwords are entered at the keyboard when a profile is activated, and make use of that. Instead of requiring a password at the launch of executable, we compromise, by verifying the list at every login. Changes made during a compromised session would show up later, but not persist longterm.

Please critique the following.

  • At OS install, use product key to generate a characteristic identifier. Many Windows OS’s already do this.
  • When installing, require root to enter password. Maintain a separate list of hashes for every profile, “P#hash,” each salted with the user profile password. Root hashes this with a P#OSchecksum. Root also maintains a master “RootHash” list, and a RootChecksum of the list, salted with the product key identifier.
  • Whenever root logs in, as a matter of course, the antivirus program generates a new RootChecksum checksum for the RootHash list, and if it is correct, proceeds to perform the added overhead of hashing every program, comparing it to RootHash list, then regenerating each P#hash list, and a P#checksum, based on profile password “P.” The antivirus then verifies the P#checksums for each profile, as an obligation of root login.
  • At user login, the user profile is granted read authority to the relevant P#hash list and verifies the P#checksum of the list, as an obligation of logging in. If the data doesn’t match, the antivirus is deemed to have found a threat.
  • After profile login, when an executable is called, the antivirus hashes the object code, and checks it against the P#hash list, for authorization.
  • If it doesn’t match, then the executable has changed since install, and the antivirus has found a threat.
  • If all is well, the program proceeds to execute with minimal intervention on the part of the user.

(Original comments on Hashes in entry “Antivirus gambit – hash code indentifiers.”)

04/19 – NOTE: I was incorrect above, in supposing that using the product identifier as a salt, would secure the list better than root credential, standing alone.

The RootHash list needs to be salted with the root password. However, if the characteristic identifier contributes (deterministically) to the result, black hat cannot generate a false list remotely based on a stolen or compromised root credential standing alone.


About James Johnson

I am an amateur mathematician & political theorist who enjoys (occasionally cerebral) humor.
This entry was posted in Uncategorized and tagged , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s