[ Pobierz całość w formacie PDF ]
A
Software
Authentication
System
for
the
Prevention
of
Computer
Viruses
Hung-Yu
Lin*
Shoubrto
Yan~*
Lein
Ham*
Science
Telecommunications
Program
* Computer
University
of Missouri-Kansas
City,
Kansas
City,
MO
64110
USA
E-mail: harn@cstp.umkc.edu
**
~p~ent
of Computer Science
University of Science and Technology of China, Hefei, Anhui 230026 PRC
Abstract
In the
absence
of systematic
techniques
to detect
the
Currently,
the
prevention
of
virus
infection
relies
on
the users’ experiences.
Vendors
are not taking
active
roles
in
existence
of
computer
viruses,
preventing
suspicious
preventing
their
released
programs
from
virus
infections.
software
from
entering
the
system
at
the
initial
point
of
entry
appears
to be the
best
method
to protect
computing
Without
vendor
involvement,
virus
problem
cannot
be
resources
against
attacks
of computer
viruses.
Currently,
solved
in any acceptable
manner.
software
is distributed
primarily
by diskettes
instead
of on-
line
transmission.
Diskettes
are
more
susceptible
to
In this
paper,
we will
review
three
different
anti-viral
moditlcation
and
masquerading
while
on-line
transmission
approaches
and
their associated
problems.
Then,
a software
usually
follows
proper
user/message
authentication.
A
authentication
system,
which
requires
a software
vendor
to
software
authentication
system
is proposed
which
does
not
sign his released
programs
and
provides
users
an easy
way
require
a mutually
trusted
center
of both
soflware
vendors
to
verify
the
authenticity
of
the
programs,
is
pro~sed
and users,
or users’ interaction
with any key center.
Vendors
along
with
the
discussion
of
several
practical
assume
responsibility
by
signing
released
software
and
considerations.
users
verify
the
authenticity
of
received
software
before
using
it.
Through
such
an
authentication
process,
users
II.
Review
of
Anti-viral
Approaches
eliminate
the
risk
of
running
“unlicensed”
or
modified
programs,
thus
eliminating
the
possibility
of
virus
Recently,
three
different
anti-viral
approaches
are well
infections.
discussed
in
literatures.
Here
we
review
each
of
them
together
with their associated
problems.
Introduction
1,
1.
Pattern-matching
In recent
years,
computer
viruses
have
become
major
This is the most
straightforward method and widely
used in many commercial anti-viralproducts. It searches for
code sequences (virus signatures,
which may be those used
by the virus
itself to avoid reinfection) that are known to
exist in programs infected by a specific strain of virus.
Once a code pattern is matched, a certain virus is detected.
However, it cannot detect arty new/unknown virus.
Whenever there is a new virus, the anti-viral products also
need to be upgraded. Such upgrades result in the increase of
program size and the downgrade of its performance. When
the number of viruses increases beyond some point, this
approachwill become impractical.
threats
to
the
computing
environment.
Many
anti-viral
products
to protect
systems
from
infections
are available
on
the
market.
These
products
do
help
users
protect
their
computers
from
viral
attacks
to
some
extent
by
either
monitoring
running
programs
or
by
identifying
certain
in infected
programs.
pauerns
However,
a satisfactory
solution
to prevent
virus
attack
[1,
2, 3]
has
not
yet
been
reached.
Formal
secure
models
mayhelp
to reduce
the
possibility
of a virus
infection
by
logically
isolating
or
limiting
access
to
computing
resources.
However
these
methods
are
usually
too
complicated
and
expensive
to
implement.
Also,
they
unnecessarily
limit
the sharing
of computing
resources.
2. Software
integrity-checking
Based
on
the fact
that
detecting
a virus
(especially
an
Permission
to
copy
without
fee
all
or
part
of
this
matarial
ia
granted
provided
that
tha
copias
ara not made
or distributed
for
unknown
one)
is difficult
[4], and a program
will always
be
direct
commercial
edvantaga,
the
ACM
copyright
notice
and tha
modifkd
after
being
infected
by a virus,
software
integrity
title
of the
publication
and
its date
appear,
and
notice
is given
that
copying
is by permission
of the
Association
for Computing
checks
(more
spec~lcally,
the checksum
method
[5]) turns
Machinary.
To
copy
otherwise,
or to
republish,
raquires
a fae
out
to
be
a
promising
and
cost-effective
approach
in
and/or
spacific
permission.
detecting
potential
virus.
e
1992
ACM
089791
-472-4/92/0002/0447
$1.50
447
to
software vendors. Thus, any new sofhvare vendor cannot
be registered after the center is destroyed. This situation is
also totally unacceptable. Vendors are established on an
almost daily basis. Therefore, this center can never be
destroyed, and it leads to the risk that once the registration
center is compromised, one can pretend to be a licensed
software vendor to distribute virus-infected programs or
Trojan horse. Under this situation, should software vendors
be responsible for the darnages caused by these programs?
Thus, no vendor wants to risk their reputation
by “trusting”
someone
The checksum algorithm is carried out by executing a
checksum generator utility over the program resulting in a
checksum value which is then stored along with the
program for latex reference. Any change in program content
will be reflected in a change of the checksum value
regenerated later. By comparing this regenerated checksum
value with the pre-stored one, we can detect any
mcxification of the program. However, one implicit but
dangerous assumption has been made in the realization of
this method. It assumes that all counteqmrts -- original
program, checksum value and the checksum utility itself --
are virus-free. This dangerous assumption usually comes
from our common belief that software purchased from well
known
who cannot be really trusted.
Proposed
Software
Authentication
III.
The
vendors
is
trustworthy.
Is this
common
belief
System
justified?
In order to alleviate the worry of software vendors, the
software authentication system should allow vendors to
sign programs with their own secret keys. In order to make
the verification
Consider the case of software counterfeiting, where one
sells a fake program claimed to be the one from a famous
vendor with its
checksum vahe computed according to the
publicly known checksum generating algorithm of the
vendor. The user will falsely believe that this program is
“clearI” after checksum verification, even when this fake
program contains a Trojan horse or is already virus-infected,
Another possible situation is that the virus-infected
program is indeed written by a malicious employee of the
vendor who carelessly distributes it. How can one make a
clear distinction between these two cases, and who should
be responsible for the damages caused to the user?
Unfortunately, most solutions in tiis approach cannot
answer this question because the released software contains
insufficient information for the user to verify the
authenticity of the software. Without proper authentication
one can never be sure that a received program is indeed fmm
the original licensed vendor and therefore it has no way to
resolve the dispute, if any, between a software vendor and a
user.
of an acquired
program
as convenient
as
possible,
the verification
process
should
be performed
locally
by
the
user
only
without
interacting
with
any
registration
or key center.
With
these considerations
in
mind, a software authentication system is proposed here.
1. System Components
In
this system, there are four major components:
software vendors
Who se~ software.
users who irnpmt software from software vendors.
the secret-generating machine@GM) which generates
one pair of public and secret keys and breaks the secret
key up into pieces to be held by several certification
centers.
certification centem(CC’s) which are accredited
organizations select&l by the users and each provides a
partial certiilcate for the signature system of a vendor.
a.
b.
c.
d.
3. Software authentication
The SGM and the certification centers do not have to
be trusted by vendors and the SGM can be destroyed after
distributing secret keys to certification centers.
In order to overcome the problems associated with the
previous approach, the software authentication method
nx@es software vendors to sign their released programs and
users to accept
2. System Initialization
only genuine
programs
by verifying
the
signatures of received software.
Based on RSA cryptosystem [8], the SGM generates a
small public key e, the corresponding secret key d, and
the modulus n. Then it breaks d up into t
ShadOWS,
a.
Although a public-key cryptosystem can provide digital
signatures for the released software of vendors, its
implementation is not so simple and straightforward as
mentioned in a recent paper [61, In that paper, a medmd was
also proposed to realize software authentication in which it
assumes the existence of a mutually trusted center of both
software
dj,
j=ltot, suchthat
dl + d2 +...+ dt = d
~d dishibutes dj to certilleation center CCj WCRMy.
The
SGM publishes e and n, and is then destroyed.
vendors
and
users.
This
assumption
is hardly
b.
E~h vendor i chooses a signature system and a pair of
public ~d secret keys (ai, hi), ad then M his {IDi, S,
ai) registered with the proper authorities. IDi, S ~d ai
am the identification, signature function and public key
of vendor i, respectively. ‘l%eregistered information
will serve for the purpose of jurisdiction to resolve
disputes, if any, between vendors and users. For
convenience, we will say a vendor is licensed if he has
acceptable
when
there
are many participants
in a large
commercial group [7].
Besides, if a mutually trusted center does exist, any
software vendor needs to go through a registration process
of this center to become a “licensed” vendor. In order to
preserve the overall security, this mutually trusted center
should be completely destroyed after issuing all secret keys
448
done
this registration,
otherwise,
the vendor
is
IV.
Discussion
unlicensed.
like
to discuss
We would
this
software
authentication
The vendor
b
sends
(IDi,
S, ai} to ~til~tion
method
bm
three different
aspects.
centers
for certificating.
After
verifying
that vendor
i is
1.
security
licensed,
each certitlcation
center
will return back
a
partial certificate
Fmm
the properties
of public-key
cryptosystems,
only
the
vendor
himself
can
either
generate
the
signature
or
<IDi
II
S IIai>dJ
mod
n
Cj
=
modify
a program
without
being
detected.
Therefore,
w
one
else can forge a licensed
vendor’s progmm
and no vendor
can
to
vendor i, where IIdenotes concatenation and c > k
used as an integer
evade
the responsibility
for his released
progmrns.
value
derived
from
the ASCII
sting.
Now vendor
i can compress
all the partial
certificates
From
a vendor’s
viewpoint,
he trusts’’his own
signature
and results
in a single
certifkate
of his signature
system
and nothing
else.
In other
words,
a licensed
vendor
system,
certi,
by computing
does not have
to be responsible
for programs
which
are not
by
himself,
released
even
when
atl
of
the
certification
CeIti =
Cl* CZ* .. .. .
*Ct =
<IDj IIS IIaj>
d
centers
are compromised,
since
one can never
pretend
to be
mod n.
a licensed
vendor
to
sign
programs
without
knowing
the
secret
key bi, which
is only known
to the vendor.
Note
that such cetilcate
can be easily
verified
by
using
the public
key e.
Although
an unlicensed
vendor
may create
a consistent
pair of P’ and signk’(p”)
with
a chosen
signature
system
and
3. Distribution
of software
related
public
and
secret
keys,
he still cannot
pass
the key
certification
process
because
he
won’t
get
the
proper
Now
if a program
P is to be
released
by
vendor
i, it
certificates
from
certification
centers.
By
employing
will consist
of four parts:
multiple
certification
centers
instead
of
only
one,
it
is
impossible
for
any
unlicensed
vendor
to generate
a valid
{IDi, P, signi(p),
certi),
certificate,
even
when
only one cetilcation
center remains
with
confidential
and the other
t-1 ones
are compromised.
From
signi(p)
= S~(h(P))
the
user’s
viewpoint,
the system
is secure
unless
all of the
ccxtillcation
centers
are compromised.
where
signi(p)
is
vendor
i’s signature
of
P,
Sbi
is the
Even
though
all
certification
centers
could
be
signature
function
S using
vendor
i’s swret
key
bi, and h is
compromised,
nevertheless,
users
can still choose
anew
set
a
publicly
known
one-way
hash
function,
which
maps
of certification
centers
with newly
generated
shadows
of the
programs
to
a
smaller
domain
to
speed
up
signature
system’s
secret
key
d before
such
disaster
really
happens.
generation
and verification.
This
work
can
be
done
by
constructing
a simple
circuit
which
accepts
old
dj’s
from
each
certification
center
and
4.
Authentication
of software
outputs
a
new
set
of
shadows
to
the
newly
chosen
When
a user acquires
[IDjP, Sign’, Cert) from
vendori,he can derivevendorisidentification,
cert.iilcation
centers.
signature
2. Flexibility
and publickey throughthesystem’s
publikeye by computing
functionidentifier,
By
separating
key
certification
and
signature
vetilcation
in the authentication
process,
software
vendors
<IDiIs Iai>= certimod n.
can
change
their
signature
systems
for
security
considerations
without
introducing
any
change
in current
Iftheresul
does not contain
IDi and a meaningful
signature
key certification
process.
The only
thing
vendors
need
to do
function
identifier,
the program
P’ should
be discarded.
If it
is to get new certificates
fhm
the certifkatiort
centers.
does,
the user
will obtain
the signature
function,
S, and
the
For
the
same
reason,
users
can
choose
artother
set of
correct
public
key
of
vendor
i, ai.
‘I%is process
is called
certification
centers
if
necessary
without
changing
the
key
certification.
If certi
passes
this
process,
the
user
can
vendors’
current
certificates
as
mentioned
in
the
above
continue
to compute
the
hash
value
of P,
hp)
and
verify
subsection.
the signature
sign’.
If signj’(p”)
has been
verified
( i.e.
h(P’)=Sai(signi’@”))
), program
P
is indeed
from
vendor
i
3. Performance
without
being
modified.
Otherwise,
either
P
or
signi(P’)
modified.
Again, this process is called signature
In
this
proposed
system,
software
authentication
has been
verification.
consists
of
two
processes:
key
certification
and
signature
449
mutually trusted party,
Proc.
of
Eurocrypt
verification.
No
third
party
is
involved
in
these
two
’90, May
21-24, 1990.
processes
and the interaction
with
certification
centers
[8]
happens only when the certificate
is requested
by a new
R.L.
RivesL
A. Shamir,
and L. Addleman,
A Method
V*.
for
Obtaining
DigitaI
Signatures
and
Public
Key
Communication
of ACIU, Vol. 21,
Cryptosystem,
No. 2, Feb.
1978,
pp.
120-126.
For
any
vendor,
before
releasing
any program,
all he
needs to do is to sign this program without having to
recompute his certificate. For users, the time required for
the key certification will
not be long because the system’s
public key can be made as small as possible (e.g. -3).
Again, if vendors’ own signature systems are RSA-based,
their public keys can also be made as small as possible to
reduce the time required for signature verification. Therefore,
the authentication of software in this system is quite
efficient. In fact, software authentication is required only
when a new software is acquired from foreign sources, so
the speed of verification will not become a critical issue.
V.
Conclusion
A software authentication system is proposed in this
paper, in which users can verify the signatures of a program
when fwst acquired from a software vendor. Through such
authentication, suspicious programs can be filtered out and
the risk of virus infections can be reduced. For software
vendors, this system is secure because they can choose their
own signature schemes and keys without having to trust
any third party. For users, this system is secure, since one
can be deceived
with programs
distributed
by unlicensed
vendors unless all certification
centers are compromised.
For
both
software
vendors
and
users,
this
system
is
acceptable
because
it provides
a mechanism
to resolve
disputes, if any, between the two parties.
References
D.E.
Bell
and
L.J.
LaPadula,
Secure
Computer
[1]
System:Unified Exposition and
Multics
Interpretation,
Tech.
Report
MTR-
2997,
Mitre
Corp.,
MITRE
March,
1976.
&dfO1’d,
Mass.,
[2]
for
Secure
K.
J.
Biba,
Integrity
Consideration
Computer
System,
MITRE
Tech.
Report,
MTR-
3153,
June,
1975.
D. D. Clark and C. T.
Wilson, A Comparison of
Commercial and Military Computer Security Policies,
Proc.
[31
IEEE
Symp.
Security
and
Privacy,
1987,
Oakland, CA, April, 1987, pp. 184-194.
Fred
[4]
Cohen,
Computer
Viruses:
Theory
and
Experiments,
Computers
and Security,
IFIP-TCII
Vol 6, No. 1, 1987, pp. 23-35.
YJ. Huang and F. Cohen, Some Weak Points on One
Fast
[a
Cryptographic
Checksum
Algorithm
and
its
Improvement,
TC-11 Computers and Security,
IFIP
vol. 8, No. 1, 1989.
E. Okamoto and H. Masumoto, ID-based
Authentication System for Computer Virus Detection,
Electronics Letters,
[Q
Vol. 26, No. IS,
July,
1990, pp.
1169-1170.
I. Ingemarsson and G. J. Simmons, A protocol to set
up shared secret schemes without the assistance of a
m
450
[ Pobierz całość w formacie PDF ]