ABYSS: A Trusted Architecture
`
`for Software
`
`Protection
`
`Steve R. White
`Liam Comerford
`
`IBM Thomas J. Wataon Research Center
`P.O. Box 704
`Yorktown Heigh~ NY 10!598
`
`Abstract
`
`ABYSS (A Basic Yorktown Security System) is an architecture
`for the trusted execution of application software. It supports a
`uniform security service across the.range of computing systems.
`The use of ABYSS discussed in this paper
`is oriented towards
`solving the software protection problem, especially in the lower
`Both
`current
`and planned
`software
`end of
`the market.
`distribution
`channels
`are supportable
`by the architecture,
`and
`the system is nearly transparent
`to legitimate users. A novel
`use-once authorization mechanism, called a token,
`is introduced
`as a solution to the problem of providing authorizations without
`direct communication.
`Software vendors may use the system to
`obtain
`technicaf
`enforcement
`of
`virtuafly
`any
`terms
`and
`conditions of the sale of their software,
`including such things as
`rentaf software.
`Software may be transferred between systems,
`and backed up to guard against
`loss in case of failure. We
`discuss the problem of protecting software on these systems, and
`offer guidelines to its solution. ABYSS is shown to be a general
`security base, in which many security applications may execute.
`
`source of information
`As computers become a more important
`and serviees in our fives, problems of software and data security
`become increasingly significant.
`The iflicit duplication and use
`of commercial
`software is only one example of these problems,
`but
`it is increasingly worrisome in the low end of the software
`market.
`It constitutes
`theft of the intellectual property of the
`authors,
`in the same way as copyright and patent
`infringement,
`It can be an economic burden as well, since
`and plagiarism.
`many small software
`fii
`rely on sales of a single software
`package
`as their only source of
`income.
`By disrupting
`the
`software marketplace,
`theft
`inhibits the growth of this powerfuf
`technology.
`
`attempts have been
`Since the inception of smalf computers,
`Technical
`made to solve the problem of
`illicit duplication.
`methods have included writing the application software so that
`it
`looks for an unusual, and supposedly uncopyable,
`feature on the
`distribution
`diskette
`[Voe186], and the attachment
`of speciaf
`hardware devices for each application to be used in the system.
`
`These technical methods have not succeeded beeause of two
`complementary
`shortcomings.
`First,
`they are not an effective
`
`are both
`low-end computers
`Today’s
`to duplication.
`barrier
`logically and physically open systems.
`ID fact, most commercial
`computers of any kind are open, at least
`to those with operator
`privileges. The user (or operator)
`is capable of examining every
`memory location,
`and every processor
`cycle, of
`the system.
`Once the behavior of the application is understood,
`it can be
`changed to subvert
`the software protection measures. Similarly,
`distribution media
`are completely
`open to examination
`and
`modification.
`Second, existing technical methods have imposed
`unacceptable
`burdens on the legitimate user. Users are ofterf
`prevented
`from making backup copies of their
`software,
`and
`from installing their software on hard disks or fiie servers.
`
`to abandon
`is
`today
`software market
`in the
`trend
`The
`upon
`legaf
`rely
`solely
`protection methods,
`and
`technical
`This is dtificuk at best
`in the widely distributed and
`protection.
`anonymous marketplace
`often addressed by low end software.
`It is impossible in countries and cultures which have no history
`of intellectual property law [Chur86].
`So, the need for practical
`technicaf protection measures continues, and grows.
`
`A practical software protection system must overcome both of
`the shortcomings outfined above.
`It must be extremely secure,
`and ensure
`that
`the effort
`involved in iflicitly duplicating
`an
`application is at
`least as large as that
`involved in rewriting it
`from scratch.
`It must also be extremely
`convenient
`for
`the
`legitimate user, and flexible enough to support a broad spectrum
`of computing environments
`and software distribution
`systems.
`A variety of authors have explored ideas which go beyond the
`more common diskette-based
`protection schemes,
`in an attempt
`to meet the requirements of increased security and convenience.
`
`system
`secure
`of
`variety
`a
`discusses
`[Kent80]
`Kent
`architectures. He mentions the valuable idea of tamper-resistant
`modules, which provide physicaf security, and uses cryptographic
`techniques
`to protect @applicationsfrom exposure. He does not
`deaf with the full spectrum of software distribution methods in
`use today, nor with the problem of backing up the applications
`onto another system should the first one fail.
`
`a crypto-microprocessor
`presents
`[Best79]-[Best84b]
`Best
`approach,
`in which application software exists in plaintext only
`within
`the
`instruction
`decoder
`of
`the
`processor.
`Best’s
`architecture
`requires the use of a cryptosystem which is not as
`secure
`as
`the modem
`cryptosystems
`often
`used
`for
`communications
`and transactional
`security.
`It limits applications
`
`CH24 16-6/87/0000/0038 SO1.0001987
`
`IEEE
`
`38
`
`Petitioner Apple Inc. - Exhibit 1031, p. 1
`
`

`

`to execution on a single system, and does not deal with the issue
`of backup.
`It also requires a substantial
`restructuring of current
`computing
`systems.
`In some versions
`of
`this
`scheme,
`a
`processor per application is required, which is costly.
`
`security
`Arnold and Winkel [Arno85] deal with cryptographic
`effectively, but
`require
`substantial
`limitations
`on dktribution
`methods,
`the processor, and the execution enviromnent.
`
`[Simm85], present
`and Simmons
`[Purd82],
`Purdy, et al.
`keys
`for
`encrypted
`decryption
`distributing
`protocol
`for
`Their
`distribution method
`requires
`software
`applications.
`to maintain a cryptographic
`facifity, which may be a
`dktributors
`burden in current
`retail store or mail-order distribution.
`They
`also do not deal with the issue of backup.
`
`a
`
`to the one
`a system similar
`describes
`[Evcr85]
`Everett
`presented here.
`Since it requires a pubfic key scheme for key
`dktribution,
`constantly-updated
`fists of authorized
`public keys
`must be maintained
`by software
`vendors.
`Also,
`software
`vendors must maintain cryptographic
`facilhies. No provision is
`made for backup. No scheme is described which would allow
`software,
`installed on one system,
`to be transferred
`to another
`system.
`
`and Pinter
`and Herzberg
`[Herz84],
`and Karmi
`Herzberg
`to the
`one
`system similar
`present
`a protection
`[Herz86],
`presented here, but
`they also require software distributors
`to
`have a cryptographic
`facility.
`They do provide
`a means of
`backing up applications
`in the event of a failure. Their backup
`method relies on communication with the manufacturer when
`backed up applications
`are instafled, and on possession of an
`Tftis may be
`unused processor
`on which to instaff
`them.
`problematic in many cases.
`
`a
`extends Best’s scheme by presenting
`Goldreich [Gold86]
`method for obscuring the pattern
`of memory accesses.
`This
`increases
`the protection
`of Best’s scheme, but at
`the price of
`addhional performance degradation.
`
`Overview of ABYSS
`
`an
`is
`System)
`Security
`(A Basic Yorktown
`ABYSS
`for
`the trusted execution of application software,
`architecture
`and can be used as a uniform security service across the range of
`computing systems. This paper is oriented towards a solution to
`the problem of software protection,
`especially in the lower end
`It addresses
`both security and ease-of-use
`of
`the market.
`Both current
`and planned
`software
`distribution
`concerns.
`methods are supportable. Users may back up applications at any
`time, and install
`them onto any other
`system in the event of
`failure, without
`the intervention of any other party at that
`time.
`A general discussion of ABYSS and software protection can be
`found in [Cina86].
`
`the software vendor with
`provides
`The ABYSS archhecture
`tools to enforce the condhions under which the application may
`be used. Software run under ABYSS executes exactly as it was
`written, and cannot be modified arbitrarily by the user.
`
`The only information which must be kept secret are certain
`encryption and decryption keys. Aside from these, all of the
`
`and implementation may be made
`details of both archkecture
`public without compromising the integrity of the system.
`
`Unprotected Proceaaes
`
`Protected Processes
`
`F@re
`
`1. The Architecture of a Protected Proceswr System
`
`Architecture
`
`of ABYSS
`
`here is shown in
`of the system presented
`The architecture
`are partitionedinto processes which are
`Figure
`1. Applications
`protected,
`and processes which are not.
`Protected
`application
`processes are executed within a secure computing environment
`called a protectedprocessor. The conditions
`under which an
`application may execute are embodied in a logical object called a
`Right-To-Execute.
`These
`condhions
`are
`enforced
`by the
`protected processor. The movement of Rights-To-Execute
`into
`and out of protected processors may require authorization
`from
`externally-supp fied authorization
`processes.
`
`Protected Processors
`
`a minimal, but complete,
`constitutes
`processor
`A protected
`computing system.
`It contains a processor, a real-time clock, a
`random or pseudo-random number
`generator,
`and sufficient
`memory
`to store protected
`parts of applications while they
`execute.
`It
`also contains
`secure memory
`for
`storage
`of
`Rights-To-Execute.
`Thk storage retains its contents even when
`the the system power is off.
`
`and
`physically,
`logicafly,
`a
`is
`processor
`protected
`The
`an
`is logically secure,
`in that
`It
`procedurally
`secure unit.
`application cannot directly access the supervisor process, or the
`protected
`part
`of
`any
`other
`application,
`to
`violate
`their
`protection.
`It
`is physically secure (which is indicated by the
`heavy
`box
`in Figure
`1),
`in
`that
`it
`is
`contained
`in
`a
`tamper-resistant
`package
`[Wein86]
`[Chau84]
`[Pric86].
`It
`is
`procedurally secure in that
`the services which move information,
`and Rights-To-Execute
`in particular,
`into
`and out of
`the
`protected processor cannot be used to subvert
`the protection.
`
`to contain the onfy
`It is possible for the protected processor
`processors
`and memory of the entire computing system.
`Such
`systems consist of a protected processor, and various peripheral
`devices such as secondary storage. Alternatively,
`the protected
`processor may be part of a larger computing system, and interact
`with it through the unprotected processes.
`
`39
`
`Petitioner Apple Inc. - Exhibit 1031, p. 2
`
`

`

`the
`In addition to executing protected application processes,
`protected processor executes a supervisor process. The supervisor
`process
`is responsible
`for ensuring the logical and procedural
`security of the protected
`processor.
`It manages
`the system’s
`communications
`resources,
`to ensure that messages are routed
`correctly
`between
`the protected
`and unprotected
`parts
`of
`applications.
`It executes
`at a higher privilege level
`than the
`application processes, and restricts
`them to isolated protection
`domains [Denn83] This isolation of application processes
`from
`each other,
`and from their unprotected
`parts,
`protects
`an
`application process from attacks originating in other application
`processes, or in the unprotected parts of the computing system.
`
`facility for
`The supervisor process contains a cryptographic
`managing encryption/decryption
`keys. This facifhy decrypts the
`protected
`parts of applications
`as they are loaded into the
`protected processor. We place the cryptographic
`transformation
`between
`primary memory
`(such
`as RAM)
`and secondary
`memory (such as a disk). Best
`[Best79]-[Best84b]
`places this
`transformation
`between
`primary memory and the instruction
`decoder of the processor.
`Placing it closer
`to the instruction
`decoder
`in the memory hierarchy
`forces
`a choice between
`significant performance
`degradation of the application,
`and the
`use of a cryptosystem with significantly less security than, say,
`DES.
`
`between primary and secondary
`Placing the transformation
`memory, on the other hand, matches
`the bandwidth
`of
`the
`cryptographic
`facility to the data transfer
`bandwidth,
`allows
`efficient pipelining of
`the data
`to be decrypted,
`and allows
`decrypted instructions
`to be used numerous times without being
`decrypted each time.
`It also allows the efficient use of message
`or manipulation detection codes on parts of the
`authentication
`application.
`
`Software Partitioning
`
`unprotected
`include
`applications
`in which
`systems
`For
`the
`application
`into
`to partition
`processes,
`it
`is necessary
`parts.
`The
`protected
`part
`is
`protected
`and
`unprotected
`encrypted when it is outside the protected processor,
`and only
`decrypted when it is loaded into the protected processor.
`The
`unprotected part is exposed to view.
`
`protected
`on the
`securely
`executes
`part
`protected
`The
`it cannot be examined or modified by any
`processor,
`in that
`party external
`to the protected processor.
`It cannot be examined
`externally while it
`is available
`for execution
`because of
`the
`logical and physical security of the processor, which inhibit all
`external
`access
`to the plaintext
`of
`the protected
`part.
`The
`encrypted form of the protected part cannot be modified directly
`because of the cryptographic
`techniques used to detect
`if it has
`been tampered with.
`It cannot be modified by rewriting it in a
`different way, because
`the partition
`is chosen
`so that
`the
`protected part
`is difficult
`to reconstruct
`from knowing only the
`unprotected part.
`
`The partition is designed so that both parts of the application
`must be present
`in order to execute the application. Eliminating
`accesses to the protected part from the unprotected
`part results
`
`the
`of
`intertwining
`This
`application.
`in a nonfunctional
`protected and unprotected parts extends the logical protection of
`the protected part to the entire application.
`
`Rights-To-Execute
`
`to execute it. Only
`The software is separated from the right
`authorized users of an application have a Right-To-Execute
`for
`that application.
`Rights-To-Execute
`are created by software
`vendors,
`and are used by the supervisor
`to control
`the entire
`range
`of
`actions
`that
`can
`be
`taken with
`respect
`to the
`application.
`
`A Right-To-Execute
`
`consists of:
`
`.
`
`.
`
`.
`
`l
`
`.
`
`,
`
`An encryption and/or decryption key for software packages.
`This is required to decrypt
`the application before execution.
`
`the Right-To-Execute.
`about
`Identifying information
`can be used to aid the supervisor
`in searching
`applicable Right-To-Execute.
`
`This
`the
`
`for
`
`about how the Right-To-Execute may be used
`Information
`software.
`This allows the software vendor
`to
`by supervisor
`control
`what
`the
`supervisor
`may
`do
`with
`the
`Right-To-Execute.
`For
`instance,
`the software vendor may
`choose not
`to allow the Right-To-Execute
`to be transferred
`to another protected processor once it is installed.
`
`about
`Information
`Right-To-Execute
`its key.
`The
`application
`to
`Right-To-Execute,
`
`the
`supervisor may permit
`how the
`to be used by software decrypted under
`software
`vendor may wish to allow the
`the
`change
`information
`in
`the
`for instance.
`
`the
`supervisor may permit
`how the
`about
`Information
`to be used by non-supervisor
`software
`Right-To-Execute
`which is not decrypted under
`its key.
`It may be useful
`to
`allow other applications
`to report certain information about
`the Right-To-Execute.
`For
`instance,
`a
`utility
`could
`summarize information
`about all Rights-To-Execute
`owned
`by a user.
`
`software
`of
`dkcretion
`the
`at
`information,
`Additional
`decrypted under
`the above key. As will be seen later,
`the
`application may store such things as an expiration date for its
`Right-To-Execute,
`and be assured that
`the application will
`not execute after that date.
`
`Authorization Processes
`
`to proceed.
`services must be authorized
`supervisor
`Various
`For instance,
`the software vendor must authorize the installation
`of the Right-To-Execute
`on a protected processor. Otherwise,
`it
`could be installed
`on any number
`of protected
`processors.
`Clearly, authorization
`processes must be difficult
`to forge,
`to
`prevent
`illicit authorizations.
`Authorization
`processes may be
`carried out
`in a number of ways. Brief descriptions of two of
`these are given here for clarity in subsequent
`sections.
`
`40
`
`Petitioner Apple Inc. - Exhibit 1031, p. 3
`
`

`

`Initial
`‘Uery% II
`
`State
`
`123
`
`. . .
`1111 . ..
`
`n
`loll&@
`
`up
`
`Response +
`
`‘UeryY
`
`Response +
`
`o
`
`Down+4111101
`
`. ..llllwa
`
`After Reading
`
`One Bit
`
`234n
`up @’+1/1111...1l
`110111 . . .
`
`Down
`
`1014- 0
`
`llOFf-
`
`0
`
`Figure 2. How Tokens Work
`
`of it. Once the
`sequence, or independent
`query-response
`protected processor
`receives the token data and decrypts it,
`it can predict
`the correct response to any query.
`
`.
`
`The token data is erased from the token as it is read. Thk
`means that a token can only respond to a single query.
`
`realization of tokens.
`shows a simple conceptual
`Figure 2
`Real
`implementations
`(This is intended to be representational.
`support
`circuitry.)
`It
`require
`a small amount
`of additional
`consists of two shift registers connected to a multiplexer.
`The
`registers are shifted left simultaneously in response to a signal on
`the multiplexer’s query line. Each time they are shifted, one bh
`the up or the down register appears on the output
`from either
`line, depending upon the value of the query bit. At
`the same
`time, nulls are shifted into both registers
`from the right. Thk
`cycle is repeated until the token is completely discharged.
`
`by loading
`vendor
`software
`by the
`is loaded
`token
`The
`random binary strings into both the up and the down registers.
`These constitute
`the token data T, , and should be effectively
`unique for each token j.
`(If an attacker possesses
`two tokens
`known to have identical
`token data,
`the entire token data can be
`revealed by querying only the up register of one token, and only
`The software vendor encrypts
`the down register of the other.)
`this data under a key A, called the application
`key, chosen by the
`software vendor
`for a particular
`application,
`to form E.(T,).’
`The plaintext
`token data is protected
`by making the token
`physically secure against
`tampering.
`
`Smart Cards Smart cards are cards the size of a credit card,
`which contain a microprocessor and memory. They can be
`constructed to perform a subset of the actions of a protected
`processor which deal with movement and storage of
`Rights-To-Execute, but not with application execution. By
`eliminating the memory in which applications reside during
`execution, and the real-time clock, current smart cards can
`contain sufficient cryptographic and storage facilities to
`authorize supervisor services cryptographically, and to store a
`limitednumberof Rights-To-Execute. They can then be used as
`temporary repositories of Rights-To-Execute being transferred
`between protected processors, and for a number of other useful
`services.
`
`Token Cards: Token cards have the same physical appearance
`as smart cards, but contain a less expensive chip called a token.
`The
`token
`is useful
`as
`a one-time-only
`authorization
`of
`supervisor services.
`
`to
`Both smart cards and tokens must be physically secure,
`prevent
`information
`contained
`in them from being revealed.
`Techniques
`for chip-levkl security applicable to smart cards and
`tokens are discussed in [Pric86].
`
`Tokens: Use-Once. For~ery-Resistant
`Authorizations
`
`We introduce a new authorization mechanism, called a token
`The token process
`is capable of participating
`in a
`process.
`query-response
`sequence with a cryptosystem exactly once.
`Even if the query and response
`are carried out over
`insecure
`channels,
`the response can still be obtained in such a way that
`it
`is extremely improbable
`that an eavesdropper
`can forge the
`behavior of a token process
`in a subsequent
`query-response
`sequence. The token process can be carried out by any simple
`computing system.
`It can also be carried out by a small piece of
`called a token, which is significantly less expensive
`hardware,
`than hardware capable of cryptographic services such as DES.
`
`How Tokens Ot)erate
`
`Tokens fulfill the following criteria.
`
`by protected
`randomly
`The queries, which are generated
`is extremely
`processors,
`are sufficiently
`numerous
`that
`it
`improbable
`that
`two queries will be
`the
`same.
`Since
`different queries generate different
`responses,
`the response
`from one query cannot be used as the response to a different
`query.
`
`it is extremely
`The responses are sufficiently numerous that
`improbable that a random guess at a response will be correct.
`
`.
`
`.
`
`l
`
`.
`
`of each other,
`are sufficiently independent
`The responses
`that knowing the response to one query is not significantly
`helpful in predicting the response to another query.
`
`the token is completely
`of
`behavior
`The query-response
`determined by data contained in the token. An encrypted
`form of these data is delivered to the querying protected
`processor.
`This
`can be done
`in conjunction with the
`
`authorization from
`The token can then act as a one-time-only
`the software vendor,
`to a protected processor which possesses
`(The means by which the protected
`the application
`key A.
`processor obtains the application key are discussed later.) To do
`this,
`the protected
`processor
`reads
`in and decrypts E.(T,)
`to
`It then generates a random query Q,
`obtain the token data T,
`which consists of a string of bits as long as either of the token’s
`registers.
`The query is presented
`to the token to obtain the
`
`41
`
`Petitioner Apple Inc. - Exhibit 1031, p. 4
`
`

`

`all of the token data are
`token’s response R. By construction,
`lost when it
`is read, even though only half of
`the data are
`revealed by the response.
`
`the
`of
`its knowledge
`can use
`processor
`protected
`The
`the
`complete token data T, to simulate the token, and predict
`to the query Q. By comparing R to R’, it
`correct
`response R’
`can determine whether or not the token is a vafid authorization,
`prepared by a party which knows A. Since aff of the token data
`is dkcharged when it is read, this can only be done once.
`
`the software
`for
`devices
`as counting
`serve
`thus
`Tokens
`vendor. A vendor who dktributes N tokens is guaranteed that
`there are only N authorizations
`in the hands of users.
`
`secret
`certain
`they contain
`that
`abifity to prove
`In their
`information without
`revealing a significant
`fraction of it, tokens
`resemble
`the interactive
`zero-knowledge
`proofs of
`[Gold85].
`Tokens
`are much simpler,
`though,
`since they only need to
`respond to a single query about
`their information.
`
`Forging a Token
`
`Suppose that an attacker has observed the query and response
`sequence for a token. What
`is the probability that, armed with
`this information,
`the attacker can respond as that
`token would
`have to another query by a protected processor?
`If successful,
`this would constitute a successful forgery of a token process, and
`could produce an ilficit authorization.
`
`respond is generated
`The query to which the attacker must
`randomly, so it wifl not have a statistically significant correlation
`to the observed query. The probabfity
`of respondhtg correctly
`to each bit
`in the query is the probability that
`that bh in the
`query is the same as the one previously observed (in which case
`the attacker knows the correct
`response),
`plus the probability
`that
`it is different,
`times the probability of guessing correctly.
`For a token with n uncorrelated bits in each shift register,
`
`Pforgev =
`
`JkmI,q”ery +
`
`[
`
`(1 - P,ameqwry) Pcomc,gUe$s1“
`
`If there are no statistically significant correlations present,
`
`P,.me,uey = ;
`Pc.nwt guess =
`
`so,
`
`Pf.rgery = (%)”
`
`(1)
`
`(2)
`
`shift
`A token with
`on
`implemented
`p,wga,y < 1.02 x 10-16.
`
`registers
`very
`
`a
`
`n = 128 can
`length
`of
`be
`small
`chip,
`and
`gives
`
`Since it is a protected processor which generatesthe query to
`a token,
`the protected
`processor
`can limit
`the frequency
`of
`queries by controlling the amount of time it takes to generate a
`query. This inldbits a high-speed “guessing”
`attack on tokens.
`The average number of guesses
`required to come up with a
`singfe correct response to a query for a given token is
`
`N=
`
`–
`
`1
`m2( 1 - Pfogery)
`
`(3)
`
`the
`If the time to generate a query is required to be one second,
`average time required to forge a response
`for an n = 128 bit
`token successfully is t.,,,a~e>108 years. Token forgery is covered
`in more detail in [Stro86].
`
`Secure Sessions Between Protected Processors
`
`is
`authorization mechanisms when it
`are useful
`Tokens
`impossible or inconvenient
`to establish a direct communication
`channel between two protected processors. Where it is possible
`to establish a such a channel, protected processors possessing an
`encryption/decryption
`key
`in
`common
`can
`set
`up
`a
`cryptographically
`secure channel between them, mediated by a
`session key. There are a number of standard ways to do thk.
`
`A User’s View of the Svstem
`
`are created, moved,
`The services by which Rights-To-Execute
`used in executing software,
`and backed up, are described in
`detaif
`in the next
`section.
`In this section, we illustrate
`the
`simplicity of the system to those who use it, by showing a user’s
`view of the system.
`
`For concreteness, we take the case in which applications are
`purchased
`through
`a retail
`store,
`as quite a bit of
`low-end
`software is today. The applications are intended to be used on a
`workstation
`which
`has
`an ABYSS
`architecture,
`and
`a
`hypothetical user interface.
`
`Software Pnrchase
`
`to today’s practices.
`Retail purchase can be virtuafly identical
`The user takes a WonderCalc
`package off of the shelf, pays for
`it, and takes it home. No part of the application package need
`be personalized
`to the user’s system, and the user may remain
`anonymous.
`Any application
`package
`in the store may be
`installed on any system, with no prior knowledge of the identity
`of the system necessary.
`
`Software Installation
`
`(hopefully!),
`The application package contains documentation
`a floppy diskette, and a token card. The user inserts the diskette
`into a drive and the token card into a slot used for just
`that
`purpose, and types:
`
`install
`
`wondercalc
`
`to
`the right
`of
`the installation
`The token card authorizes
`processor.
`execute WonderCalc
`in the user’s protected
`The
`token
`is dkcharged,
`but
`the
`diskette
`is unchanged.
`The
`WonderCalc
`software may be copied, put onto a hard disk, etc.
`
`42
`
`Petitioner Apple Inc. - Exhibit 1031, p. 5
`
`

`

`Executing Protected Software
`
`Supervisor Services
`
`From the user’s point of view, there is no change in the way in
`which the application is executed. The user simply types:
`
`wondercalc
`
`and the application executes as usual.
`
`Backup
`
`installed
`all
`of
`copy
`a backup
`create
`user may
`The
`into the
`isinserted
`at anytime. Asmartcard
`Rights-To-Execute
`system (thkisnecessary
`for backup validation,
`slot ontheuser’s
`which will bedkcussed
`later), andthe user types:
`
`backup
`
`backed-up
`containing
`An
`the
`file
`encrypted
`is written out,
`to the user’s hard disk,
`for
`Rights-To-Execute
`instance, or to a floppy dkkette.
`
`backed-up
`the
`fails,
`processor
`protected
`user’s
`the
`If
`protected
`on another
`installed
`may be
`Rights-To-Execute
`processor may reside in another
`processor.
`Thk replacement
`workstation, or it may simply be a module which is replaced in
`the user’s original workstation.
`In either case, the installation is
`accomplished by inserting the smart card into the replacement
`system’s slot, inserting a dkkette containing the encrypted file of
`Rights-To-Execute,
`and typing:
`
`backup
`
`-install
`
`replacement
`on the
`are installed
`The Rights-To-Execute
`is modified with a message to the
`processor,
`and the dkkette
`hardware manufacturer.
`The user sends the failed processor,
`and the dkkette,
`to the hardware manufacturer.
`The user can
`use all of the installed Rights-To-Execute
`as usual.
`
`sends a diskette to the user,
`the manufacturer
`Aftera while,
`retention
`of
`the
`installed
`the permanent
`which authorizes
`The user
`inserts
`the diskette
`into the
`Rights-To-Execute.
`replacement system, and types:
`
`backup
`
`-retain
`
`Transfer
`
`limited to residing
`are not
`Once installed, Rights-To-Execute
`in one system forever. They may be transferred
`at will by the
`user,
`if this is permitted by the software vendor.
`Suppose that
`the
`two
`protected
`processors
`can
`estabfish
`a
`two-way
`communication, over a local area network for instance, and that
`Alice is transferring a Right-To-Execute
`to Bob. Alice inserts
`her smart
`card into her
`system’s
`slot
`(this
`is necessary
`for
`backup validation, which will be dkcussed later), and types:
`
`transfer
`
`–bob wondercalc
`
`services which were
`the supervisor
`section describes
`This
`introduced in the previous section. Each of these services can
`employ
`either
`a
`symmetric
`cryptosystem or
`a public
`key
`cryptosystem.
`In this discussion,
`they are oriented towards a
`symmetric cryptosystem such as DES, since it is the best match
`to both the
`cost
`and performance
`requirements
`of
`today’s
`lower-end computers.
`
`between
`Each service could use tokens, or communication
`protected processors, as authorization mechanisms. Only one of
`these authorization m~chanisms
`is illustrated in each case for
`simplicity. We choose the authorization mechanism that
`is most
`convenient
`for
`illustrating
`each service.
`The
`services
`are
`simplified for clarity. An actual
`implementation would include
`communication
`handshaking,
`verification of the completion of
`each step of the service, and error recovery.
`
`security of the system,
`the procedural
`to guarantee
`In order
`It must ensure that no
`each service must ensure four
`things.
`cryptographic
`keys are exposed
`in plaintext,
`that protected
`software is not exposed in plaintext,
`that protected software only
`executes under
`the terms and condhions chosen by the software
`vendor, and that the protected software has not been modified.
`
`Creating Protected Software
`
`of
`execution
`the
`supports
`architecture
`The ABYSS
`applications which are not protected,
`so it can allow existing
`applications
`to be migrated to systems with protected processors
`with no change. To protect an application,
`the software vendor
`must create a part of the application to be executed securely,
`encrypt
`it, create acorrespondlng
`Right-To-Execute,
`and create
`an authorization
`process
`for
`installing that Right-To-Execute.
`The
`same ABYSS
`processors
`which
`execute
`protected
`applications
`can be used to perform the critical
`steps in this
`process, so no special development
`systems are needed.
`
`yritimt Partitioned Abdications
`
`least part of it
`The application must be written so that at
`resides in the protected processor during execution. Depending
`upon implementation
`details,
`this may be the entire application,
`or it maybe
`a small fraction of it. The section Secure Software
`discusses
`the
`problem of
`partitioning
`an
`Partitioning
`application into protected and unprotected parts.
`
`EncrvDtirm the Protected Part of the ADDfiCatiOtt
`
`Once the part P of the application to be protected is complete,
`chosen by the
`is encrypted
`under
`an application
`key A,
`it
`software vendor,
`to form E#’).
`The application key may be
`unique
`to each application,
`or even to each copy of each
`application.
`This key need not be revealed to anyone else, and
`the encryption can be done outside of the protected processor,
`if
`desired, by the software vendor.
`
`The Right-To-Execute
`removed from Alice’s.
`
`is
`
`installed
`
`in Bob’s
`
`system,
`
`and
`
`Two goals must be met by this encryption.
`avoid the exposure of the piaintext application.
`
`First,
`Second,
`
`it must
`it must
`
`43
`
`Petitioner Apple Inc. - Exhibit 1031, p. 6
`
`

`

`from being
`application
`the
`of
`part
`the protected
`prevent
`modified, even randomly, and executed. This isinsupport
`of the
`requirement
`that
`the protected
`processor
`execute
`applications
`exactly as
`they were written.
`If
`the application
`could be
`modified in a known way,
`it could be instructed
`to reveal
`its
`Even if
`the application
`could be
`entire plaintext
`content.
`is
`it
`still
`possible
`that
`the
`random
`modified
`randomly,
`modifications,
`executing in the protected
`processor, wiff cause
`the revelation of important
`information about
`the protected part.
`The second goal can be met by using message authentication
`or
`manipulation
`detection
`codes
`[Juen83] when encrypting
`the
`protected
`part of
`the application,
`and having the protected
`processor use them to authenticate
`the application before it is
`executed.
`
`Creating a Right-To-Execute
`
`necessary
`the
`all of
`containing
`file RTE.,
`A plaintext
`information for the Right-To-Execute
`for the application, can be
`created by the software vendor.
`It contains the application key
`A, and associated information about how it can be used.
`
`key S, which is
`a supervisor
`under
`This file is encrypted
`possessed by the protected processor on which the application
`This.encryption
`can be
`will be installed,
`to create -EJRT.EJ.
`done by a protected
`processor,
`as a service to the software
`vendor.
`It can be done without
`revealing the supervisor key S,
`since the encryption can be done secureIy inside the protected
`processor.
`For simplicity at this point, consider
`the supervisor
`key S to be common to afl protected processors made by a given
`manufacturer. Alternatives will be discussed later.
`
`Creating an Authorization Process
`
`an authorization
`now create
`vendor must
`softwa