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: IPCOM000124004D
Original Publication Date: 1999-Sep-01
Included in the Prior Art Database: 2005-Apr-05
Document File: 2 page(s) / 83K

Publishing Venue

IBM

Related People

Ovies, H: AUTHOR [+3]

Abstract

One problem that administrators and IT organizations have today is not having control over what software is being run on the systems 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 or it can lead to unauthorized use of systems.

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

Scheme for Restricting Execution of Unlicensed or Virus-Infected
Software on a Hardware Platform (Virus and Pirated Software Resistant
System)

One problem that administrators and IT organizations have
today is not having control over what software is being run on the
systems 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 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,
files are recognized by their extensions 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 several ways that this can be done:
  1) The embedded security coprocessor can be used to sign
     an executable, using a private key that is stored by the
     embedded security coprocessor, the signature then compared
     to an attached signature on the executable.  If they match,
     it is allowed, otherwise not.
  2) The embedded hardware security coprocessor can be used
     to obtain a DES key (normally stored us...