Browse Prior Art Database

Scheme for restricting execution of unlicensed or virus-infected software on a hardware platform. (Virus and Pirated software resistant system)

IP.com Disclosure Number: IPCOM000014766D
Original Publication Date: 1999-Sep-01
Included in the Prior Art Database: 2003-Jun-20
Document File: 2 page(s) / 42K

Publishing Venue

IBM

Abstract

Main Idea

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

  Scheme for restricting execution of unlicensed or virus-infected software on a hardware platform. (Virus and Pirated software resistant system)

Main Idea

*Title of disclosure (in English)

Scheme for restricting execution of unlicensed or virus-infected software on a hardware platform. (Virus and Pirated software resistant system)

*Idea of disclosure

One problem that administrators and IT organizations have today is not having control over what software is being run on the system they administrate. This can lead to legal problems of pirated software running on corporate systems, or viruses being introduced into PCs on a manufacturing line by an employee who brings in an infected game to run on a computer on the manufacturing line (i.e. CIH virus) or it can lead to unauthorized use of systems.

In those cases it is important to be able to restrict the programs that can run on a particular platform to those that are approved. This invention describes how that can be accomplished:

The basic problem is to provide a means of authorizing code as being "runnable" on a system. In most Operating Systems, there is a kernel routine (such as command.com) that launches programs according to their extension. Exe, com, cmd, bat, ini, etc. files are recognized by their extension as being runnable, and then launched. We suggest that this routine be modified to first check for authorization, by using an embedded security coprocessor. This would be done via the same type of hook that virus software checkers use for scanning software before it is run.

There are a couple of ways this can be done:

1) The embedded hardware security coprocessor can be used to obtain a DES key (normally stored using the security coprocessor) which is used to "decrypt" the executable before it is run. In the case that the executable was not encrypted...