U.S. patent application number 10/236068 was filed with the patent office on 2003-04-10 for texturing system.
Invention is credited to Ashton, Martin, Fenney, Simon.
Application Number | 20030067474 10/236068 |
Document ID | / |
Family ID | 9921483 |
Filed Date | 2003-04-10 |
United States Patent
Application |
20030067474 |
Kind Code |
A1 |
Fenney, Simon ; et
al. |
April 10, 2003 |
Texturing system
Abstract
A texturing system for use in a three-dimensional graphics
system has an input for receiving object data for an object to be
textured. Encrypted texture data is obtained from a store a
decrypted in a decryption unit. The decrypted texture data
generates texture image data for a frame buffer from where it can
be output for display. There is also provides a method for
producing a software application for use in a three-dimensional
graphics system which creates instructions for a software
application and creates static texture data for use in conjunction
with the instructions. The static texture data is encrypted and
provided as encrypted texture data with the software instructions,
A protected software application can be distributed to a target
device from a distribution device by coupling the distribution
device to the target device, transferring target device identifier
data from the target device to the distribution device and using
the target device identifier data in the distribution device to
generate encryption definition data specific to the target device.
The protected software application and encryption definition data
are then transferred to the target device.
Inventors: |
Fenney, Simon;
(Hertfordshire, GB) ; Ashton, Martin;
(Hertfordshire, GB) |
Correspondence
Address: |
FLYNN THIEL BOUTELL & TANIS, P.C.
2026 RAMBLING ROAD
KALAMAZOO
MI
49008-1699
US
|
Family ID: |
9921483 |
Appl. No.: |
10/236068 |
Filed: |
September 3, 2002 |
Current U.S.
Class: |
345/582 |
Current CPC
Class: |
G06F 21/121 20130101;
G06F 21/6209 20130101; G06T 15/04 20130101; G06T 15/005
20130101 |
Class at
Publication: |
345/582 |
International
Class: |
G09G 005/00 |
Foreign Application Data
Date |
Code |
Application Number |
Sep 4, 2001 |
GB |
0121382.6 |
Claims
1. A texturing system for use in a three-dimensional graphics
system, the texturing system comprising: an input for receiving
object data describing an object to be textured; a store for
storing encrypted texture data for applying to an object to be
textured; a decryption unit, coupled to the store, for decrypting
the encrypted texture data; a framebuffer, coupled to the input and
to the decryption unit, for applying decrypted texture data to
object data to generate textured image data; and an output, coupled
to the framebuffer, for outputting textured image data for
display.
2. A texturing system according to claim 1, wherein the input is
configured to receive encryption key identification data
identifying the encryption key used to encrypt the texture data,
the texturing system further comprising a key production unit,
coupled to decryption unit and to the input, for generating the
encryption key from the encryption key identification data, whereby
the decryption unit uses the encryption key to decrypt the
encrypted texture data.
3. A texturing system according to either claim 1 or claim 2,
wherein: the store is configured to store encrypted texture and
checksum data; the decryption unit is configured to decrypt the
encrypted texture and checksum data and separate the data into
texture data and checksum data; and the system further comprises a
protection unit, coupled to the decryption unit, for monitoring the
checksum data and for adapting the output of the texturing system
if the checksum data does not match control checksum data.
4. A method of applying texturing to three-dimensional graphics
data, the method comprising the steps of: storing encrypted texture
data for applying to texture an object; receiving object data
describing an object to be textured using stored texture data;
accessing and decrypting the encrypted texture data; applying the
decrypted texture data to the object data to generate textured
image data; and outputting the textured image data for display.
5. A method according to claim 4, further comprising the steps of:
receiving encryption key identification data identifying the
encryption key used to encrypt the texture data; calculating the
encryption key from the encryption key identification data; and
using the encryption key to decrypt the encrypted texture data.
6. A method of producing a software application for use in a
three-dimensional graphics system, the method comprising the steps
of: (a) creating instructions for a software application; (b)
creating static texture data to be used by a device in conjunction
with the instructions to run the software application; (c)
encrypting the static texture data using an encryption algorithm;
and (d) outputting the encrypted texture data and software
instructions as the software application.
7. A method according to claim 6, comprising the additional steps
of; generating checksum data for the static texture data; combining
the checksum data and the static texture data; and wherein step (c)
is modified to encrypt the combined checksum and static texture
data.
8. A method according to claim 1, wherein the checksum data is
generated from a first plurality of words selected from the
beginning of the texture data.
9. A method of distributing a protected software application from a
distribution device to a target device, the method comprising the
steps of: coupling the distribution device to the target device;
transferring target device identifier data from from the target
device to the distribution device; using the target device
identifier data in the distribution device to generate encryption
definition data specific to the target device; transferring the
protected software application and the encryption definition data
from the distribution device to the target device for subsequent
use by the target device to enable the protected software
application to be run,
10. A method according to claim 9, wherein the encryption
definition data is itself encrypted to form a Sales Key and wherein
the Sales Key is transferred with the protected software
application to the target device.
11. A 3-d graphics device for running software applications
comprising instructions and encrypted texture data, the device
comprising: a CPU for running a software application; a memory,
coupled to the CPU, for storing a software application; a display
for displaying 3-d graphics generated by running a software
application; and a texturing system according to any of claims 1 to
3, the input of the texturing system being coupled to the CPU and
the output being coupled to the display.
12. A 3-d graphics device according to claim 11, wherein the
texturing system is configured to store a device identifier for use
by a distribution device.
13. A distribution device for distributing a protected software
application to a target device, the distribution device comprising:
a receiver for receiving target identifier data from a target
device; a combiner, coupled to the receiver, for generating
encryption definition data from the target identifier data and an
application encryption key; and an output for outputting a
protected software application and the encryption definition data
to a target device for use by the target device to enable the
protected software application to be run.
14. A distribution device according to claim 13, further
comprising: an encrypter, coupled to the combiner and to the
output, for encrypting the encryption definition data to form a
Sales Key, wherein the output outputs the Sales Key and the
software application to a target device for use by the target
device to enable the protected software application to be run.
15. Apparatus substantially as hereinbefore described with
reference to any of FIGS. 2 to 7.
16. A method substantially as hereinbefore described with reference
to any of FIGS. 2 to 7.
Description
[0001] This invention relates to a texturing system for use in a
three-dimensional graphics system. It also relates to a method of
distributing protected software applications.
BACKGROUND OF THE INVENTION
[0002] Computer graphics applications, in particular computer
games, can be very expensive to develop. Unfortunately, they are
also a popular target for software pirates, possibly because of the
number of potential users. In the past, piracy was usually
partially limited by supplying the application on a physical
medium, e.g., either a ROM cartridge or a `difficult to copy` disc,
or by shipping a physical key, e.g. dongle. It is envisaged,
however, that software will increasingly be sold electronically,
e.g. downloaded from the Internet or from a `point of sale`, POS,
terminal in a shop. This lack of a physical medium would thus
potentially make illegal copying a far simpler task unless other
measures are taken.
[0003] The protection of software against piracy has relied on
several techniques in the past. One such technique is the use of a
difficult to replicate physical medium for storage of the software
application. For instance, some computer games console manufactures
have used "Read Only Memory" (ROM) cartridges, or proprietary
variants of common media such as higher density CD ROMs for which
no off-the-shelf duplication tools exist.
[0004] An alternative technique often used for personal computers
is to use standard media, such as floppy disks or CDs, but
deliberately `damage` them in small areas during manufacture using,
say, a laser. The application software then contains instructions
to check that the supplied storage medium contains these errors. An
off-the-shelf floppy drive or CD-Rom `burner` would not be able to
reproduce the error on the medium. Although the checks for the
errors can be hidden within the software to a certain extent, given
sufficient time a determined cracker can locate them and produce a
modified version of the application with the checks removed. This
`cracked` software could then be stored and run using off-the-shelf
media.
[0005] Another method of protecting the contents of the software
from being modified would be to use a `secure` CPU which could
encrypt all transfers to and from external memory. Such processors,
however, are not common and this may not be a viable option for the
manufacturer of a computer graphics device. Furthermore, on its own
this does not prevent copying of the application, only its
modification.
[0006] Some devices, such as ethernet adapters and some computers,
are constructed with an in-built unique identifier. We have
appreciated that this identifier could be used to customise
software so that it runs on only one machine. Again, unless other
steps are taken, this would be open to abuse by modification of the
software that removes the checks.
[0007] The present invention in particular deals with systems and
applications doing 3D computer graphics rendering.
[0008] A typical known environment is illustrated in FIG. 1a. Here
a CPU 1 is connected to memory 2 that would contain the application
code and data structures. The application would typically respond
to user input 3. The description of each 3D image, typically
composed of triangles with parameters for application of image, or
texture, data is generated by the CPU and this object data is sent
to the rendering subsystem 4. This would use texture data stored in
memory 5 to produce image data which would be constructed in a
framebuffer in memory. The finished images would then be sent to
the display system 6. In some systems, memory units 2 and 5 might
actually be the same physical memory.
[0009] The known 3D rendering system4 is now described in more
detail with reference to FIG. 1b. The rendering system 4 consists
of a unit 7 receiving polygon data. These polygon data are sent
either individually or in batches to the rasterization unit 8 which
determines which pixels in the final image are affected by which
polygons and what colours to assign to the pixels. As part of this
process, texture data must be accessed 9. This involves converting
numerous requested texture identifiers and pixel coordinate
positions into colour values and may require accesses to the 3D
rendering system's memory via a memory control system 10. This
memory control system would also handle framebuffer read and write
requests from the rasterization unit 8. Finally, the display
control system 11 would transfer finished images from the memory to
the display device.
[0010] The aim of the invention is to ameliorate the problems
associated with the known distribution techniques. In accordance
with the present invention in a first aspect there is provided a
texturing system according to claim 1. Preferred features of the
texturing system are defined in dependent claims 2 and 3. Requiring
the encrypted static texture data to be decrypted before it can be
applied to the object data provides a means of protecting an
application by making it difficult to copy the texture data in a
way in which it could be used by another device to run the same
application.
[0011] In accordance with a second aspect of the invention, there
is provided a method of applying texturing to three-dimensional
graphics data according to claim 4. Preferred steps in the method
are defined in dependent claim 5.
[0012] In accordance with the present invention in a third aspect,
there is provided a method of producing a software application
according to claim 6. The software application is protected by the
encryption of the static texture data so that only authorised
devices can decrypt the static texture data and run the software
application. Preferred features are defined in dependent claims 7
and 8.
[0013] In accordance with a fourth aspect of the invention, there
is provided a method of distributing a protected software
application from a distribution device to a target device in
accordance with claim 9.
[0014] In accordance with a fifth aspect of the invention, there is
provided a 3-d graphics device according to claim 10.
[0015] We have appreciated that many of the textures used by an
application, especially games applications, will be created at the
time the application is written. For the purposes of this patent,
these will be referred to as static textures. Other textures may be
produced while the application is running and these will be
referred to as dynamic textures.
[0016] The aim of the invention is to make the widespread
duplication of graphics software, in particular games software,
difficult. It does this through a combination of protection
circuitry within the rendering hardware and protection of the
static texture data, rather than rely on obfuscation of the
software, use of a protected CPU, and/or use of a proprietary
storage medium. The invention resides in the realisation that by
encrypting static texture data and controlling decryption of the
texture data associated with a software application, the software
may be protected from unauthorised use The invention concerns a
method of adapting computer graphics hardware with additional
software production steps to inhibit widespread copying of such
applications.
[0017] The system presented relies on the fact that a reasonable
proportion of the computer graphics application, in particular a
computer game, is static texture data which is prepared during the
applications development. To protect the application, the standard
3D rendering hardware system is modified in five main ways.
Firstly, each rendering chip has a unique, or at least very
infrequently repeating, identification code embedded in it.
Secondly, a set of secret keys is built into the silicon of the
rendering chip and made virtually impossible to access. Knowledge
of certain secret keys are then released only to trusted parties.
Thirdly, some number of each application's externally stored
textures are encrypted during development and are only decrypted
within the 3D rendering chip by the texturing system during the
rendering processes. Fourthly, the encrypted static textures are
marked with a secure checksum so that rendering can be made to
terminate if invalid texture data is supplied. Finally, the
software delivery system is also modified so that it can modify or
`tailor` the software for a specific target device on which the
application is to run.
[0018] It should be noted that dynamic textures, i.e., those
generated by software whilst the application is running, are not
encrypted/protected. If a symmetric (i.e. private key only) cipher
were used, this would require storing the key in the application
thus exposing it to a determined software pirate. An alternative
would be to use a public/private key system, however, at present
these are much slower, and so the time to encrypt the texture would
make the technique undesirable in a real time system.
[0019] An embodiment of the invention will now be described in more
detail with reference to the accompanying drawings in which:
[0020] FIG. 1a is a block diagram of a known 3-d graphics rendering
system;
[0021] FIG. 1b is a block diagram showing further detail of the
system of FIG. 1a;
[0022] FIG. 2a is a flow chart showing the steps involved in the
production of a software application using encrypted texture
data;
[0023] FIG. 2b is a flow chart showing the steps involved in
modifying a software application for transfer to a target
device;
[0024] FIG. 2c is a flow chart showing the steps taken by the
target device to allow the modified software application to
run;
[0025] FIG. 3a is a flow chart showing generation of a security
checksum and encryption of the texture data;
[0026] FIG. 3b is a flow chart showing more detail of the steps
involved in the generation of the checksum;
[0027] FIG. 4 is a flow chart showing generation of a Sales
Key;
[0028] FIG. 5 is a block diagram showing a texturing system
according to an embodiment of the invention;
[0029] FIG. 6 is a flow chart showing the steps performed by the
key production unit of the texturing system; and
[0030] FIG. 7 is a diagram showing the steps performed by the
production control unit.
DESCRIPTION OF PREFERRED EMBODIMENTS OF THE INVENTION
[0031] In a preferred embodiment, the protection system would
consist of three main processing phases as illustrated in FIGS. 2a
to 2c. These would be the production (or development) phase 20
which occurs during the authoring of the software, an optional
`point of sale` phase 21 that occurs when the software is purchased
electronically, and the runtime/rendering phase 22 which takes
place when the software is run on the device.
[0032] The production phase further consists of the standard
application development steps 23, and two new steps. The first is
to choose (preferably via random means) an application specific
encryption key 24, which will be referred to as AEK, and a second
step 25 whereby the is majority of the static textures, i.e. those
textures which are simply loaded into the texture memory and not
otherwise modified by application software during the running of
the application, are check-summed and are encrypted by means of the
AEK. In a preferred embodiment, the encryption system would be a
private key system, and for security reasons, the AEK in preferred
embodiments would be at least 64 bits in size.
[0033] The `point of sale` phase 21 applies to the cases where the
application is supplied electronically (i.e. no mass-produced
physical medium is used). The first step, 26 is to request the
target device's unique (or near unique) identifier, DevID. The next
step 27 is to securely combine the DevID, the AEK, and one of
several secret keys embedded inside the rendering chips to produce
a sales key, SAK, which is specific to the pairing of that
application and the target rendering device. The final step 28 is
to download the entire application data, including its textures
encrypted with the AEK, to the target device, along with the SAK,
and an index for the secret key that was used in step 27.
[0034] If the point of sale phase described below is not be used,
for example if the application is to be provided on a physical
medium rather than downloaded, then two options are possible.. In
the first, an inbuilt `set-up` program asks the owner to contact,
for example via a free phone number, a support operator who would
ask the user for the device's serial/identification number and in
return supply a Sales Key. This key would then be inputted by the
owner and saved by the application (typically in removable memory
units) for future execution of the application. Alternatively, a
small subset of the set of embedded secret key identifiers could
have the side effect of `replacing` the internal device identifier,
DevID, with a known constant value thus enabling identical copies
of the mass produced media to run on any device.
[0035] The run-time rendering phase 22 requires that the
application supplies the SAK and the internal secret key to the
rendering hardware 29. The rendering hardware reverses 30 the
combination steps 27 applied in the point of sale phase by using
the internal key, DevID and SAK to retrieve the AEK. During
rendering 31 the protected textures are decrypted on-the-fly using
the AEK. In a preferred embodiment of the run-time rendering phase
22, a number of protected textures are sampled and the checksum
verified.
[0036] A preferred method for the generation of the security
checksum and encryption of the texture data 25 will now be
described with reference to FIG. 3a. Each static texture 40 is
supplied and a per-texture checksum is generated from the first `N`
words 41 of the texture. The choice of `N` is a compromise between
the level of security desired and the time taken to test the
validity of the texture. In a preferred embodiment, this would be
the first 4 words where the word size would be 64 bits, but other
combinations could be chosen. The checksum function could be a
simple operation such as the summation, modulo 2.sup.64, or a
trivial bit-wise XOR, i.e. exclusive OR, of the data words.
[0037] The checksum is concatenated with the entire texture, and
the result is then encrypted 42 and output 43. The encryption step
42 is described in more detail in FIG. 3b. In step 44 blocks of
data corresponding to the width of the block cipher algorithm 45
are issued to the encryption algorithm. An example of a suitable
block cipher algorithm could be one of the current NEST "Advanced
Encryption Standard" candidates, such as "TwoFish", or even the
earlier Triple DES standard.
[0038] The texture is effectively encrypted in `Electronic
CodeBook`, or ECB, mode, using the AEK 46. To improve security in a
preferred embodiment, the input values would `salted` 47 with their
position offsets relative to the base of the texture using an XOR
operation. For example, the J.sup.th block of data from the texture
could be XORed with the binary representation of the number J prior
to encryption. This helps obscure the contents of the texture and
increases the difficulty of code book based attacks. Note that many
more advanced cipher modes, for example cipher block chaining, CBC,
are not suitable for texturing as they do not permit random access
of the pixels within the encrypted textures.
[0039] The production of the sales key 27 is illustrated in FIG. 4.
This is done by taking the Device ID, DevID, 50 and the AEK 46 and
combining them 51 using an easily reversible operation, to produce
encryption definition data as an intermediate result 52. In a
preferred embodiment this combination operation could be an
addition or a bitwise exclusive OR, and the output would be at
least 64 bits. The operation is reversible in the sense that given
the Device ID and the intermediate result, it is simple to derive
the AEK.
[0040] The encryption definition data is then encrypted 53 with a
block cipher using a secret key 54 a copy of which will be embedded
in or derivable within every rendering chip. This secret key is
never publicly revealed but is known to the distribution device or
sales tool. In a preferred embodiment a plurality of secret keys
would be embedded in the event that the current secret key was
compromised. Alternatively, a public key system such as RSA (U.S.
Pat. No. 4,405,829) or a key-exchange system such as
Diffie-Helman's (U.S. Pat. No. 4,200,770) could be used. The public
key is used in the sales tool and the private key would be embedded
within the rendering hardware.
[0041] The encrypted result 55 is used as the sales key, SAK, which
is exported with a copy of the application.
[0042] FIG. 5 illustrates the modifications that are made to the
rendering unit 4 that was originally described in FIG. 1b. The
modified unit contains a Key Production Unit 30 that accepts the
Sales Key, SAX, and the identifier for the internal secret key, and
reverses the steps described in FIG. 4. This produces the internal
copy of the application's encryption key 71. This key is supplied
to the texture decryption unit 72 which decrypts texture pixels
needed by the texture access unit 9. It should be noted that, with
the hardware thus described, if an invalid key were supplied, the
textures on the polygons would appear as random noise.
[0043] In addition, a protection control input unit 73 would
receive a command word or words from the application running on the
CPU 1, when the application starts executing. To prevent behaviour
being compromised by deliberate modification of the application,
these commands will have been encrypted with the internal AEK 71.
The unit 73 decrypts the command and supplies it to the Texture
Validity Check unit 74. Whilst each scene is rendered, this unit
samples some number of the protected textures, via the texture
access unit 9, to test that the stored checksum matches a checksum
computed from the start of the texture data. Actions determined by
the command supplied by 73 can be taken if these matches fail. The
choice of actions would depend on the target market of the device,
but a choice of likely actions could include shutting down the
rendering chip, sending an interrupt to the CPU, and replacing the
`textures` with a flat shaded mode which could be used for
demonstration purposes.
[0044] In a preferred embodiment, there would be a delay,
determined by a clock counter, before an action would be taken by
the validity unit 74. This makes attacks based on repeatedly
guessing a less restrictive encrypted command infeasible due to the
time taken.
[0045] Furthermore, in a preferred embodiment, there is a memory
encryption/decryption unit 75 positioned between the memory
controller 10 and the memory 5. This unit is intended to make
reverse engineering of the original contents of the static textures
more difficult assuming an attack involving re-writing the
application.
[0046] The behaviour of the key production unit 30 will now be
described in reference to FIG. 6. The application supplies the
identifier for the secret key that was used by the sales
application in combination step 27. This accesses a secret key
table or function 81, that returns the actual secret key 82. In a
preferred embodiment, the secret key would be at least 64 bits in
size assuming a symmetric cipher is used. A much larger key would
be needed if a public/private key system were employed. The chosen
secret key 82 is then used to decrypt the sales key 55, which is
also supplied by the application, using the decryption function 83.
This function must be the inverse of encryption step 53. The
intermediate result 84 which is identical to that of intermediate
result 52, is then supplied along with the Device ID 86 to a
separation or `uncombine` operation 85 which is the reverse of
combination operation 51. The result is the internal Application
Encryption Key 71 and is identical to that chosen in step 24 and
subsequently used in 46. The preferred embodiment has a choice of
several secret keys so that, in the event of a security breach in
the point of sale application, there is a fall-back position so
that future releases might not be compromised.
[0047] The system must also protect the instructions issued to the
rendering system from the application with regard to its behaviour
with the checking of valid textures. This is done within the
protection control unit (73), and the operation is now described in
reference to FIG. 7. The application supplies one of several legal
instructions which have been encrypted during the development phase
with the AEK 24, and this is stored in the Encrypted Control Word
Register 90. To inhibit the random guessing of a less restrictive
control word, the register in a preferred embodiment should be at
least 64 bits wide. The contents of the register are then decrypted
91 using the internal copy of the AEK 71. The decrypted results are
then checked to see if they match one of the small set of valid
commands 92. An invalid command will result in a very restrictive
command being sent to the validity check module 74 which, in a
preferred embodiment, would bring the rendering to a halt after a
delay.
[0048] It should be noted that when the circuits are implemented in
silicon that the areas controlling the protection, and in
particular the secret keys, should not be accessible by register
test scan chains. Furthermore, it is important that the secret keys
not be released to the public.
[0049] With respect to the above description, it is to be realised
that equivalent apparatus and methods are deemed readily apparent
to one skilled in the art, and all equivalent apparatus and methods
to those illustrated in the drawings and described in the
specification are intended to be encompassed by the present
invention. Therefore, the foregoing is considered as illustrative
only of the principles of the invention. Further, since numerous
modifications and changes will readily occur to those skilled in
the art, it is not desired to limit the invention to the exact
construction and operation shown and described and accordingly, all
suitable modifications and equivalents may be resorted to, falling
within the scope of the invention.
[0050] It should be noted that the features described by reference
to particular figures and at different points of the description
may be used in combinations other than those particularly described
or shown. All such modifications are encompassed within the scope
of the invention as set forth in the following claims.
[0051] For example, different techniques for encrypting the texture
data, such as the public/private key system, could be employed.
* * * * *