AU7888400A - Gaming security system - Google Patents

Gaming security system Download PDF

Info

Publication number
AU7888400A
AU7888400A AU78884/00A AU7888400A AU7888400A AU 7888400 A AU7888400 A AU 7888400A AU 78884/00 A AU78884/00 A AU 78884/00A AU 7888400 A AU7888400 A AU 7888400A AU 7888400 A AU7888400 A AU 7888400A
Authority
AU
Australia
Prior art keywords
memory
program
platform
boot program
logic circuit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
AU78884/00A
Other versions
AU778171B2 (en
Inventor
Robert Linley Muir
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Aristocrat Technologies Australia Pty Ltd
Original Assignee
Aristocrat Technologies Australia Pty Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from AUPQ3216A external-priority patent/AUPQ321699A0/en
Application filed by Aristocrat Technologies Australia Pty Ltd filed Critical Aristocrat Technologies Australia Pty Ltd
Priority to AU78884/00A priority Critical patent/AU778171B2/en
Publication of AU7888400A publication Critical patent/AU7888400A/en
Application granted granted Critical
Publication of AU778171B2 publication Critical patent/AU778171B2/en
Anticipated expiration legal-status Critical
Expired legal-status Critical Current

Links

Landscapes

  • Storage Device Security (AREA)

Description

VV UI/L4Ul YL1/ALUU/U11YJ 1 GAMING SECURITY SYSTEM Field of Invention The present invention relates generally to gaming machines and in particular, the invention provides an improved method of detecting tampering in software such that the need for other expensive security 5 measures may be reduced. Background of the Invention Methods have been put forward for the authentication of gaming software using cryptographic digital signatures. Such methods check that each software module to be loaded has been signed by the authorized signer 10 before. It will not load a module without a valid signature. The security if the machine can be traced back to the boot software which resides in EPROM or flash memory. The boot software will load no unauthorized code, which in turn will load no unauthorized code, as this is a requirement for code to authorized in the first place. However, these methods have the disadvantage 15 that the machine can be tampered with by modifying the boot code to remove the signature checks. In gaming the term multigame refers to a game machine in which more than one game is selectable without changing the hardware or software, usually by the player, but also by the operator. In a multigame machine the 20 software is preferably separated into separate physical parts (e.g. EPROM) or files. A system program provides supporting functions and the operating system while the game program provides that code which is different between games. A Multigame machine is then typically comprised of System program and multiple independent game programs. This flexibility 25 introduces the possibility of unauthorized copying and use of games. It is relatively easy for an operator to copy game EPROMS and use them in machines for which they are not authorized. In non-gaming applications non-volatile re-writable memory, typically Flash, is becoming very widely used for its high capacity and ease of field 30 upgrades. In the past, upgrading the boot program of a gaming machine has not been feasible for security reasons. Regulators have been concerned that illegal code could be downloaded to the gaming machine. Regulators also generally require that code inside a gaming machine be verifiable, however if the boot code were changed it would only be possible to verify the data by 35 removing the chip and reading it in a special purpose chip reader. The W" UI/1, UIL ruL/AUUU/Ull!, 2 program cannot be self verifying as tampered code could fake the correct response. This is very inconvenient in system design and customer use. Summary of the Invention According to a first aspect, the present invention consists in a boot 5 program security system associated with a platform for software execution, wherein the security system verifies an executable boot program to be executed on the platform and which contains basic components of a platform operating system which perform a security validation of other software components and authorizes their execution on the platform, the platform 10 including processor means for executing the executable boot program, boot program memory means in which the executable boot program is stored, and address bus means and data bus means which provide communication between the processor means and the boot program memory means, the security system including boot checking memory means, comparison means, 15 and software monitoring means to monitor addresses expressed on the address bus means by the processor means, the software monitoring means being responsive to addresses on the address bus corresponding to locations in which a secure portion of the executable boot program is stored, to read data expressed on the data bus means by the boot program memory means 20 and representing words of the executable boot program being verified, providing the data read from the data bus to the comparison means for comparison with corresponding data in the boot checking code memory means and if the data does not match, producing a signal to indicate an abnormal condition. 25 According to a second aspect, the present invention consists in a boot program security system associated with a platform for software execution, wherein the security system overrides code fetches when a secure portion of a boot program is being executed on the platform., the boot program containing basic components of a platform operating system which perform a security 30 validation of other software components and authorizes their execution on the platform, the platform including processor means for executing the programs, memory means in which the executable programs are stored and address bus means and data bus means which provide communication between the processor means and the memory means, the security system 35 including secure boot program memory means, and software monitoring means to monitor addresses expressed on the address bus means by the wj UIhLAUlh Li/AUUUlU11L 3 processor means, the software monitoring means being responsive to addresses on the address bus corresponding to address locations allocated to the secure portion of boot program to read the corresponding locations of the secure boot program memory means and to pass the data read from the secure 5 boot program memory means to the processor means for execution. According to a third aspect, the present invention consists in a boot program security system associated with a platform for software execution, wherein the security system verifies an executable boot program to be executed on the platform and which contains basic components of a platform 10 operating system which perform a security validation of other software components and authorizes their execution on the platform, the platform including processor means for executing the executable boot program, boot program memory means in which the executable boot program is stored, and address bus means and data bus means which provide communication 15 between the processor means and the boot program memory means, the security system including boot checking memory means, comparison means, and software reading means to read data from the boot program memory means corresponding to a secure portion of the executable boot program and providing the data read from the boot program memory means to the 20 comparison means for comparison with corresponding data in the boot checking code memory means and, if the data does not match, producing a signal to indicate an abnormal condition. According to a fourth aspect, the present invention consists in a security override device for overriding a secure program stored in a secure 25 program memory and verified prior to or during execution, including override program storage means holding a program which will be executed in place of the secure program during selected periods, verification detection means to detect completion of a verification process performed on the secure program and multiplexing means to multiplex the override program storage means 30 with the secure program means, whereby the override program storage means is mapped in and out of memory space to selectively execute the override program. According to a fifth aspect, the present invention consists in a method of verifying an executable boot program associated with a platform for 35 software execution, the boot program being for execution on the platform and containing basic components of a platform operating system which perform a WU UI/L4UI L Yt 1/AUUU/UII1YL 4 security validation of other software components and authorizes their execution on the platform, the platform including processor means for executing the executable boot program, boot program memory means in which the executable boot program is stored, and address bus means and data 5 bus means which provide communication between the processor means and the boot program memory means, a verification system including boot checking memory means, comparison means, and software monitoring means and the method including the steps of, the software monitoring means monitoring addresses expressed on the 10 address bus means by the processor means, the software monitoring means being responsive to addresses on the address bus corresponding to locations in which a secure portion of the executable boot program is stored, to read data expressed on the data bus means by the boot program memory means and representing words of the 15 executable boot program being verified, and providing the data read from the data bus to the comparison means, the comparison means comparing the data read from the data bus with corresponding data in the boot checking code memory means, and if the data does not match, the comparison means producing a signal to 20 indicate an abnormal condition. According to a sixth aspect, the present invention consists in a method of running a boot program on a platform for software execution in a secure manner by overriding code fetches when a secured portion of the boot program is being executed on the platform, the boot program containing basic 25 components of a platform operating system which perform a security validation of other software components and authorizes their execution on the platform, the platform including processor means for executing the programs, memory means in which the executable programs are stored and address bus means and data bus means which provide communication 30 between the processor means and the memory means, and a security system including secure boot program memory means, and software monitoring means to monitor addresses expressed on the address bus means by the processor means, the method comprising the steps of, monitoring addresses on the address bus and detecting addresses 35 corresponding to address locations allocated to the secure portion of boot program, VV" UIAIArL YL1/A.)UUU/UIIYL 5 reading the corresponding locations of the secure boot program memory means, and passing the data read from the secure boot program memory means to the processor means for execution. 5 According to a seventh aspect, the present invention consists in a method of verifying an executable boot program associated with a platform for software execution, the boot program being for execution on the platform and containing basic components of a platform operating system which perform a security validation of other software components and authorizes 10 their execution on the platform, the platform including processor means for executing the executable boot program, boot program memory means in which the executable boot program is stored, and address bus means and data bus means which provide communication between the processor means and the boot program memory means, and a security system including boot 15 checking memory means, comparison means, and software reading means, the method comprising the steps of, reading data from the boot program memory means corresponding to a secure portion of the executable boot program, providing the data read from the boot program memory means to the 20 comparison means, comparing the data read from the boot program memory means with corresponding data in the boot checking code memory means, and if the data does not match, producing a signal to indicate an abnormal condition. 25 According to a eighth aspect, the present invention consists in a method of overriding a secure program stored in a secure program memory and verified prior to or during execution, including the steps of storing an override program in an override program storage means, the override program being a program which will be executed in place of the secure program 30 during selected periods, detecting completion of a verification process performed on the secure program and multiplexing the override program storage means with the secure program means, whereby while the verification of the secure program is not in progress the override program storage means is mapped in and out of the memory space to selectively execute the override 35 program.
nL v v11UUUlU117 6 Preferably a logic circuit is provided in which the boot checking code memory means, the comparison means, and the software monitoring means are implemented. The logic circuit may be a hard wired circuit but is more preferably an Application Specific Integrated Circuit (ASIC) a Field 5 Programmable Gate Array (FPGA) or the like. However, the logic circuit ispreferably not a user programmable device, the boot checking code memory means comprises a ROM which is included in the logic circuit (supplies the data to the CPU). When an abnormal condition is indicated, the operation of the platform 10 will be altered to prevent fraudulent operation or use of unauthorized software. This may be achieved by altering the function of otherwise unrelated parts of the logic circuit. It may also involve the logic circuit causing a reset of the processor means or preventing software access to sensitive functions of the platform. Preferably however, program segments 15 relating to non-sensitive functions to continue to run, whereby information may be given to a user about the abnormal condition. When the platform is a gaming console, the sensitive functions comprise game operation, metering of console parameters such as hardware meters, credit input and credit output. Preferably also, when an abnormal condition is indicated, the platform will 20 be prevented from operating until the condition is acknowledged by an operator and corrected. To facilitate correction of an abnormal condition, data indicative of the abnormal condition is preferably stored in non-volatile memory and for greater security again, non-erasable memory may be used. 25 Preferably, additional security for the secure boot routine is provided by performing a software security check of an entire boot memory in which the boot routine is held. This is preferably performed using a digital signature checking program, however it is also possible to implement security of the boot routine by using a hash code checking program, or another similar 30 software security technique, to checkan entire boot memory in which the boot routine is held and implementing signature checks in the executable code of the secure routine. Other programs may also be checked by signature or hash code before they are run, such that new game programs may be loaded onto the platform and validated without changing the secure program. 35 Thesignature or hash checking routines are preferably contained in the part of the boot code which is checked by ther logic circuit.
WU U1/L4UAL PL1/AUUU/U11YL 7 In one form of the invention the logic circuit is removably connected to the platform for external verification of the secure program. In this case the logic circuit includes connection means to allow the removable connection to the platform. This enables the software to be checked by a third party such 5 as an agent of a licencing authority. In one embodiment the logic circuit acts as an In-Circuit Emulator (ICE) for the processor means when it is attached to the platform and data stored in the boot program memory means are read via the ICE. In another embodiment the logic circuit incorporates logic which dumps the system memory contents to an external port. This may be 10 achieved by asserting a pin on the logic circuit during power up, which causes the logic circuit to hold the processor means in a reset state, while it reads the memory contents and transmits it via a serial port to a personal computer. The logic circuit may also be designed to respond to requests from a serial port of the platform to dump memory contents to the serial port. 15 According to a ninth aspect, the present invention consists in a method of verifying a game program in a gaming machine arranged to play a plurality of games where each game is implemented in a separate game program, wherein the gaming machine is provided with an interface for connection of a secure authorization device which is used to authorize a game program to 20 run, the method comprising the steps of the gaming machine sending an authorization request message to the secure authorization device identifying the game requiring authorization, if the secure authorization device contains a game identification for the game requiring authorization it responds with a message authorizing the 25 game, if the secure authorization device does not contain a game identification for the game requiring authorization it does not respond or responds with a negative message, the gaming machine verifies that the message received from the secure 30 authorization device are from a valid device, the gaming machine only permits the game to be played if it receives with a message authorizing the game from the secure authorization device and it verifies that the secure authorization device is valid. In particular, a smartcard may be used as the secure authorization 35 device, and may use digital signatures to sign a game authorization message. Preferably the gaming machine holds a signature public key for the secure WO 01/24012 PCT/AU00/01192 8 authorization device and can check the signed game authorization message and the validity of the secure authorization device simultaneously. Preferably also each game is authorized for a limited period only, and the secure authorization device will only authorize a game if the period has not 5 expired. It is also desidable that a previously authorized game should cease to operate if the secure authorization device is removed from the gaming machine to prevent one authorisation device from being used on a plurality of machines to authorise simultaneously operating games. Brief Description of the Drawings 10 Embodiments of the invention will now be described by way of example with reference to the accompanying drawings in which: Figure 1 illustrates a hardware configuration for monitoring data and address buses to check a boot program; and Figure 2 illustrates a memory map of a CPU memory showing the 15 security measures applied to different memory segments. Detailed Description of the Preferred Embodiments One method of providing boot program security is to perform a digital signature check of the entire boot EPROM. The disadvantage of this approach is complexity of hardware, so, in preferred embodiments of the invention, it 20 is proposed to only use hash & put signature checks in the software. Using this approach, the hardware design is greatly simplified. Legal Authorization Cryptographic digital signatures are a technical solution to the problem of unauthorized code modification. If this method is compromised it 25 becomes possible for unauthorized software to be used in the machine. The cryptographic methods may also be suplemented by a further method uses a message embed into the authorized software and which makes a legal statement about that software and it ownership or authorization. Such a statement might include a text message such as 30 "This Software Is Authorized By Aristocrat Leisure Industries" or "@ Aristocrat Leisure Industries" The authentication hardware or software requires that the message be embedded in the program/data it is authenticating. If the message is not 35 present in the appropriate place the authentication test fails and the data/program is not used. Unlike digital signatures this method is technically WO 01/24012 Y 1/AUUU/U1IYL 9 easy to cheat, by embedding the message, but provides legal recourse to the manufacturer if it is detected. Digital signatures are technically difficult by potentially legally weak. The two methods may be combined to provide both legal and technical security. 5 Referring to Figure 1, after the secure boot routines held in the EPROM 13 have been verified as discussed below, these routines can be used to load programs from a mass storage system 31 such as a hard disk drive 33 and controller / interface 32. Other mass storage systems can also be used such as a CD or DVD ROM drive, a floppy disk drive or ZIP T M drive. The program will 10 be loaded from the mass storage device into RAM by a loader program which is preferably held in EPROM 13, but could also be held a ROM associated with a logic circuit such as the ROM 17 of the Application Specific Integrated Circuit (ASIC) 12 illustrated in Figure 1. In alternative embodiments, the ASIC 12 may be replaced by a Field Programmable Gate 15 Array (FPGA). As the program is read from the mass storage device 31, the loaded code is scanned for a predetermined text string embedded in the code such as "© Aristocrat Leisure Industries". 20 The scanning may either be performed in software by a routine in the loader program, or alternatively the ASIC 12 my be programmed to scan the data flowing over the buses 11 and locate the text string. In another embodiment, a hard wired scanning circuit can be connected to the busses 11 to scan for 25 the string. This method of verification may be used in stead of a hashed code or encrypted signature but in the preferred embodiment is used as well as an encrypted signature or hashed code verification method. Once the loaded program has been verified, the embedded text string will be displayed on a display device 34 such as the video display screen of a 30 gaming machine on which the program is running, such that visual confirmation of the validation is provided. This display function is performed by the loaded program thereby also enabling detection of fraudulent use of software on other manufacturers hardware. The loaded program also performs internal consistency checks to prevent alteration or 35 deletion of the text string. Boot Security V UI/'*ulk Y I/ALUUU/U11IVZ 10 These methods improve on the existing art, by allowing the verification of programs and data in boot memory and which is not possible to tamper with by simply changing the program memory. An advantage of these security systems is that non-volatile re-writable 5 memory can be used to hold the boot program. Even if tampered code were somehow loaded into memory the security mechanisms would prevent it being executed. An advantage of Application Specific Integrated Circuit (ASIC) monitored memory and hash checked memory security mechanisms is that 10 relatively simple logic is required in the ASIC and the rest of the security mechanism is in software. If the entire mechanism were placed in the ASIC it would be far more complex, costly, less flexible and take longer to design. Boot memory contains the software that is first executed by the CPU when it exits the reset state. 15 Monitored memory (or hash checked memory) may also be used to store those parts of the software that access critical security functions. For example the ASIC may contain logic which can enable or disable access to cash payment mechanisms or auditing information. By putting the enabling switch in monitored memory it becomes possible to check the security and 20 authentication of the machine software before enabling or disabling these features. ASIC Monitored Memory The boot program is checked by monitoring the CPU address and data buses 11, as shown in Figure 1. The ASIC 12 which monitors the buses 11 25 contains a copy (in internal ROM) of the data in a portion 14 of the boot EPROM 13. When each word of data is fetched from EPROM 13 by the CPU 15 a compare function 16 of the ASIC 12 first checks the address to see if it is within that area duplicated in the internal ROM 17, and if it is it then checks the data word that the CPU 15 is reading from the EPROM 13 against the 30 appropriate word in the internal ROM 17. If the data is the same then the CPU 15 is using the correct data from EPROM 13, but if it is different then there is either an accidental error or deliberate tampering. In this event the ASIC 12 takes appropriate action which may include resetting the board and/or stopping other operations of the ASIC 12 internally.
VV " lilulk YkL 1/AUUU/U11I!L 11 In the preferred implementation the CPU address and data bus 11 are multiplexed together to reduce the number of pins used. Non-multiplexed buses may also be used. The ASIC 12 may also contain logic to ensure that all memory locations 5 in the monitored memory are checked. If all locations within the monitored area are not checked when an inappropriate access is made outside the monitored area the check fails and the board locks up. An inappropriate access is an instruction fetch or write cycle. Read cycles are allowed, to enable the software in the monitored region to check other parts of memory. 10 Two implementations of this are: The address bus 11 is monitored and a register is used to store a scanned address value location. Whenever the address from the CPU matches the value in this register the register is incremented. The memory check is complete when the address register reaches the end of the monitored 15 memory. A signature of address accesses may be implemented. Each address is combined in some form with the previous addresses to generate a fixed pattern. If the sequence of addresses is not the same as the original stored pattern then the check fails. For example each address may be combined 20 using a CRC algorithm with the previous address's although preferably a more secure algorithm would be used. Other implementations of monitored memory are possible: * Instead of checking the program as it is executed the ASIC disables the EPROM and substitutes data to the CPU from its internal ROM. The ASIC 25 thus acts as a memory device. * The ASIC reads the contents of the monitored EPROM area before the CPU exits the reset state and generates a cryptographic hash of the data. Only if this hash matches a predefined value is the test passed. * Instead of checking the data as it is read from EPROM the ASIC reads the 30 EPROM contents and verifies it before allowing the CPU out of the reset state. * In a variation of the above two implementations, the ASIC allows the CPU to fetch the first word of a program after exiting reset, but inserts into this read cycle the verification reads from EPROM. It is more difficult to 35 tamper with this method as the cycles are not separated clearly.
WU 01/24012 PCT/AUUU/U1192 12 To provide further protection the monitored boot area may be read and monitored at a later time after the test has passed and game software is running. This provides protection against some forms of tampering where tampered memory is substituted for the original memory after the test passes. 5 This scheme is most effective with as much functionality of the board as possible implemented in the ASIC. One method of tampering is to replace the entire ASIC, but if significant other functionality is included it becomes a serious technical problem to redesign the ASIC. Additionally the more critical the ASIC is to the functioning of the board then the more difficult it is 10 to get the board working again if the monitoring circuit disables the operation of the ASIC internally. If the monitored memory test fails, the board and ASIC are typically reset. Alternately program execution is allowed to continue but certain features of the ASIC are disabled preventing the board be used in its full 15 capacity. This allows the software to display appropriate errors messages (especially in the case of accidental memory errors), but effectively stops tampering having any real consequence. In the case of gaming machines, certain critical functions will also be inhibited such as software access to hardware meters 41, and inhibiting input and output of credit or the like, 20 such as by way of the credit card reader 42 or ticket reader/writer 43. Hashed Checked Memory The internal ROM of the ASIC is expected to be small compared to the size of the boot EPROM to reduce cost, although it could be the same size. Alternately, and as described above, the cryptographic hash check may be 25 embedded in the ASIC. The size of the EPROM to be securely checked can be increased to the total size of the memory in the system without increasing the size of the ASIC internal ROM by embedding a checking program in the area of EPROM that is checked by the ASIC. The checking program generates a cryptographic hash 30 over the entire memory area to be checked (which may include the area monitored by the ASIC) and compares it to a pre-computed value. If it matches then the entire region is assumed to be unmodified. The method relies on it being difficult to tamper with the data which is included in the hashed area while retaining the same hash value and that the ASIC monitors 35 the program which generates and checks the hash.
WU U1/Z4UIZ FiI'/AUUU/UII12 13 The advantage of this method is that the hash checking program is relatively small, and can be expected to be smaller than a comparable signature checking program. Therefore the size of the ROM in the ASIC can be reduced in size with this method. 5 A non-cryptographic checking algorithm may be used instead of the hash function, but algorithms such as checksum or CRC are relatively easy to tamper with and are not preferred. The data to be checked, either directly by the ASIC or included in the hash-checked region, may include program or data. The data may include 10 text messages such as "© Aristocrat Leisure Industries" or "This software is authorized by Aristocrat Leisure Industries". Signature Checked Memory Once the initial part of the boot memory has been authorized it can then securely check the rest of the memory in the system. 15 The monitored memory area may use a hash mechanism to check more memory as described in the previous section or it may implement a digital signature check. The advantage with a digital signature check is in minimizing the amount of boot code that can never be changed without changing the ASIC. The advantage of a hash check is that a hash is simpler 20 and there requires less program space for monitored memory than digital signature software. Digital signatures are also used to authorize all other modules of software and data in the system, including System software and games. Each authorized EPROM or file has an associated digital signature which is 25 checked. If invalid signatures are found the data will not be used and appropriate action will be taken, such as the machine locking up and displaying a message. Figure 2 shows a schematic of a memory map in which a first section of the memory space 21 is checked by the ASIC 12, a second part of the memory 30 space 22 is checked by a hashed code and a third part of the memory space 23 is checked by digital signature. The memory space checked by the checking software may include or exclude the area in which the checking software resides. In the example illustrated in Figure 2 the signature checked memory space23 does not encompass the memory space 21 35 containing the checking software (i.e. the space monitored by the ASIC) but the hash checked memory space 22 does encompass the memory space 21.
VV" VII&-uiz.r%_ 1/A UUU/UiIIYA 14 Continuous Authorization Continuous monitoring of the authenticity of software provides extra security. The memory contents are periodically rechecked to ensure that changes have not occurred. 5 Continuous monitoring requires a method of getting the CPU to start executing software within the monitored (or alternately hash checked, although this is not as secure) memory area. Once the CPU starts executing software within this secure area it can again perform authorization checks of the system as required. A watchdog type monitor is implemented in the 10 ASIC which must be accessed periodically from software executing within the secured memory area otherwise the ASIC will force the system to shutdown. This transfer to secure area may be simply by software jumping to an address periodically or caused by an interrupt from the ASIC. * The ASIC must be able to detect that software is executing from the 15 monitored area. The method used depends on the processor implementation. * For processors which support identification of external bus cycles an instruction fetch from a predefined address is used. * For processors without identification of bus cycles and also without 20 internal cache memory a sequence of memory accesses is detected that may only be generated by software executing within the monitored area. * For CPU without bus cycle identification and also with cache it may not be possible to guarantee detection of monitored area software execution. Tampering could take place by execution of software within the cache so 25 that external cycles appeared to be the correct software accesses. An alternate method of guaranteeing execution within monitored memory is to periodically reset the CPU. In this implementation the CPU is able to be reset separately from the rest of the system. Prior to being reset, the CPU saves it's operational state in memory for restoration after the 30 authentication checks have been completed. After the ASIC has reset the CPU then the CPU must be executing from monitored memory. A flag in the ASIC indicates the cause of the reset so the CPU knows whether to execute cold start reset code or continuous monitoring code. While the CPU is in the reset state the ASIC checks the state of the relevant pins to ensure that the 35 CPU actually has been reset. In the preferred implementation the ASIC contains a timer which is initialized after each reset and which locks up the 15 board when it reaches a predefined count. The timer would require that the CPU be reset every five minutes for example. Periodically and at least less than every 5 minutes the system software saves the system state and instructs the ASIC to reset the CPU and also timer. The system software can choose a 5 point in it's operation where a slight delay while the CPU resets is not noticeable. Alternately the ASIC generates an interrupt periodically which the system software responds to by saving the CPU state and then the CPU resets. These authentication checks are as described in the rest of the 10 document. The authentication check can be divided into a number of these execution periods to divide the CPU loading over time. In this case the check software may need to store information between the periods (such as the last memory location checked). Although this data may be stored in RAM, it is accessible by any software running on the machine and could be tampered 15 with. Preferably the ASIC implements some RAM only accessible from by software running within the monitored memory area. One possible method of tampering is to find start execution of code within the monitored area, which was not intended as a start address for the routine and which has side effects unintended by the system programmers. 20 This side effect would access the flag in the ASIC without running the security check. On method of preventing this is to implement a address signature check as described for "ASIC Monitored Memory". A significant section of code must be executed correctly for the signature to be correct and it must be from the correct address. Many other methods are possible. 25 One method of tampering with the system is to allow the correct boot code to be executed after reset and during authentication, then at an appropriate point map into the program memory a new section of code (e.g. in hardware swap EPROMS with a multiplexer circuit). This memory automatically mapped in an out of memory space depending on where 30 program execution is being performed. The authentication check reads the original data and passes, but when control is passed elsewhere a different program is executed. To prevent this attack, at a random time the ASIC reads from the CPU data bus the instruction fetched from memory, and stores it in a register together with the address from which it was read. When the periodic 35 authentication check is performed it reads these registers and compares them with the data it reads from the same location. If the data is different then VT , vz~z r... II- UUUIUI~Yh 16 tampering has taken place. This test will eventually, at a random time, detect tampering. To speed up this test more than one data location may be sampled. Because it may take some time before tampering is detected it is preferable that when tampering is detected this information is stored so that 5 the machine cannot be used until this condition is acknowledged by the operator and fixed. It should be stored in non-volatile memory, and preferably non-erasable memory. True random number generation is not usually feasible in an ASIC and instead pseudo-random numbers are typically used instead. The pseudo 10 random number may be randomized further by combining it with some external information, such as the contents of the data or address bus. An alternate method is to use DMA or bus mastering by the ASIC to automatically read the contents of memory and verify the data. This method is most suitable for the boot code, as the complexity of the design for more 15 equivalent functionality to that easily achieved in secure software to very high - although it is possible. External Memory Verification In the gaming market regulators often require that the contents of programmed memory be externally verifiable. This traditionally has been via 20 reading the programmed chip in a commercial device programmer, however it is preferable if this can be performed without removing the device from the board - especially if it has been assembled in such a was that make this difficult (e.g. surface mount assembly). There are several methods of allowing the memory contents to be read: 25 * An CPU In-circuit emulator is attached to the board and the device memory contents read via the emulator. An automated verification package may be constructed which automatically drives the emulator to read and compare memory images without providing the full functionality or complexity of an In-Circuit Emulator. 30 * The ASIC incorporates logic which dumps the system memory contents to an external port. In one implementation, when requested by asserting a pin on the ASIC during power up, it holds the board in reset, reads the memory contents and transmits it via a serial port to a PC. * The software responds to requests from the machine serial port to dump 35 memory contents to the serial port. Given the authentication built into the machine the data is trusted to be correct. However it is preferable that the VVJ u.tibult. rL I/ALUU/UII y 17 software to perform this function is as secure from any form of tampering as possible, and so is either in monitored memory or hash checked memory. Code which changes often is less secure as there is more chance that the security procedure may be compromised. 5 Software Development Software development requires that engineers be able to run any code they wish on the gaming machine. It is not desirable to allow software engineers to sign their code with the real product keys, as security would be quickly compromised. 10 Several methods of allowing software development are possible: * Another version of the gaming machine CPU board exists without security. It is only used for internal development and never into the field. * Developers sign their software with a different key to that used for finished software. The authorization software in the machine detects this 15 developer key and either displays a message to the player, gaming machine operator, service technician, etc, or disables some key features of the product. * Where a special non-secure version of the CPU board exists without security care must be taken that it is not feasible to convert the secure 20 version into the non-secure version. Methods to accomplish this are: * Two versions of the ASIC are produced, with and without security. Only a limited number a made without security and distribution of these is carefully controlled. If they are manufactured in a different physical IC package they may be visibly different or require different 25 PCB designs. * The ASIC has a pin which disables the security features. For production parts the ASIC is shipped with this pin internally unconnected in the ASIC package, so that security is enabled. As a security screening mechanism it is possible to detect if security is 30 enabled, either via software or ATE board test. * The security of the ASIC is enabled by an external feature of the board that is difficult to tamper with. For example if the ASIC is in a BGA package, several pins must be connected to disable security. When the PCB is manufactured without these tracks it would be very difficult to 35 modify the board to reconnect the pins.
WO 01/24012 PCT/AU00/01192 18 * An FPGA without the security feature is substituted for the ASIC. The FPGA requires an external configuration EPROM. On boards with the ASIC the connections to the configuration EPROM may be removed either by design of the PCB or scratching or drilling some of the 5 connections on the board. It becomes technically difficult to modify a board with ASIC to have a FPGA and also it is very noticeably different. Methods of Tampering The security of ASIC monitoring of memory relies on the difficulty of 10 modifying the ASIC. This is exceptionally difficult compared to the 'normal' method of tampering with the EPROM. Several methods of attack are possible: * Modifying the ASIC to impair security. The checking logic may be changed or removed. A new ASIC may be designed without the checking 15 circuit or with a checking circuit that does not operate in the correct manner. The data in the ASIC ROM used for monitoring comparison may be modified. * The board may be modified to cause the ASIC to monitor the correct data while the CPU is executing different data. In the worst case this need 20 only happen for as little as one read cycle to cause the monitoring to fail. Multigame The Multigame authorization system allows games to be used only on the system for which they are authorized. The System program confirms the authorization of the game before it is allowed to be used. 25 Preferably game authorization comprises one or more of the following steps: * The header section of the game memory is checked to confirm that it is an appropriate game (e.g. not another system EPROM incorrectly used, has valid version numbers, etc). 30 * The game header is checked for the legal authorization message. * The game header checksum or CRC is checked to ensure memory integrity. * If the games are digitally signed, then the digital signature(s) are validated. 35 * The authorization of the game to run on this particular gaming machine is checked.
VT % Vi1/&-thVx r. 11AUUUIU11L 19 If the authorization fails the gaming machine may either continue without allowing that game to be used, stop and ask the operator to remove the game from the machine, or run that game only in demonstration mode. Preferably each gaming machine contains a unique identification 5 number which the CPU can read and use as part of the authorization code. This can be implemented using a Dallas Semiconductor serial identification chip (e.g. DS2401). Games may be signed with DEMO key which runs in the game in a limited mode and displays an appropriate message on the screen. The 10 limited mode may prevent the machine accepting or paying out money or updating critical auditing information. EEPROM Authorization An authorization message is created using by applying a digital signature to a message composed of the unique Game Identifier, a unique 15 Gaming Machine identifier and any usage restrictions that may be required (e.g. date restriction on game operation). The signature is generated in an secure environment and sent to the gaming machine where it is stored in non-volatile memory for later use. The secure environment may be: 20 * Within a smartcard. A service technician or operator may authorize the game to run on the machine by connecting the smartcard to the machine where the game is installed. To limit accidental or deliberate fraud the smartcard preferably contains a limit on the number of games that can be authorized. The smartcard may be inserted into a special purpose 25 interface on the gaming machine, a general purpose interface such as is used for player marketing cards or via a PC and communication interface (e.g. RS232 or Ethernet) with a smartcard reader. * The gaming machine supplier may generate the authorization key and supply it to the service technician/operator for entry into the gaming 30 machine. * The authorizations may be encoded into removable EEPROM chip which is supplied to the operator with the new games. Smartcard Authorization The gaming machine has a smartcard interface which is used to 35 authorize a game to run. The games are authorized for a limited period and the smartcard must be always be present in the machine. When the V7 UvAi'UAl r 1.. IALUUUlUIYL 20 smartcard is removed the machine detects this within a reasonable period of time and stops the games running. This prevents a single smartcard be used to authorize games on multiple machines. The advantage of the smartcard is this application is that it will not be 5 possible to make a copy and that it can contain restrictions on game usage. To authorize a game, the gaming machine sends an authorization request message to the smartcard containing the game ID. The smartcard responds with a message either allowing the game or not and the smartcard is also verified as being allowed to authorize games. Preferably the smartcard 10 uses digital signatures to sign a game authorization message. The gaming machine contains the signature public key and can therefore both check the message and the smartcard. It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the invention as shown in the 15 specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

Claims (152)

1. A boot program security system associated with a platform for software execution, wherein the security system verifies an executable boot program to be executed on the platform and which contains basic components of a platform 5 operating system which perform a security validation of other software components and authorizes their execution on the platform, the platform including processor means for executing the executable boot program. boot program memory means in which the executable boot program is stored, and address bus means and data bus means which provide communication between the processor 10 means and the boot program memory means, the security system including boot checking memory means, comparison means, and software monitoring means to monitor addresses expressed on the address bus means by the processor means, the software monitoring means being responsive to addresses on the address bus corresponding to locations in which a secure portion of the executable boot program 15 is stored, to read data expressed on the data bus means by the boot program memory means and representing words of the executable boot program being verified, providing the data read from the data bus to the comparison means for comparison with corresponding data in the boot checking code memory means and if the data does not match, producing a signal to indicate an abnormal condition. 20
2. The system of claim 1 wherein the boot checking code memory means, the comparison means, and the software monitoring means are implemented in a logic circuit.
3. The system of claim 2 wherein the logic circuit is an Application Specific Integrated Circuit (ASIC). 25
4. The system of claim 2 wherein the special purpose integrated circuit, is a Field Programmable Gate Array (FPGA).
5. The system of claim 2, 3, or 4 wherein the boot checking code memory means comprises a ROM which is included in the logic circuit.
6. The system as claimed in any one of claims 2 to 5 wherein, when an 30 abnormal condition is indicated, the function of otherwise unrelated parts of the logic circuit are altered.
7. The system as claimed in any one of claims 2 to 5 wherein, when an abnormal condition is indicated, the logic circuit resets the processor means.
8. The system as claimed in any one of claims 2 to 5 wherein, when an 35 abnormal condition is indicated, the logic circuit prevents software access to sensitive functions of the platform. VVkj ULIA. IUAL r% 1 ilkUUUlU117 22
9. The system as claimed in claim 8 wherein, when an abnormal condition is indicated, the logic circuit permits program segments relating to non-sensitive functions to continue to run, whereby information may be given to a user about the abnormal condition. 5
10. The system as claimed in claim 8 wherein the platform is a gaming console and the sensitive functions comprise game operation, metering of console parameters, credit input and credit output.
11. The system as claimed in any one of claims 1 to 10 wherein, the secure portion of the executable boot program checked by the logic circuit contains a 10 checking program which performs a software security check of a first further block of memory and if the security check fails the boot program prevents program code or data in the security checked block of memory from being used by the platform.
12. The system as claimed in claim 11 wherein the software security check 15 is performed using a secure hash checking program.
13. The system as claimed in claim 11 or 12 wherein, the block of memory checked by the software security check contains a digital signature checking program which performs a digital signature check of a second further block of memory and if the digital signature check fails the boot program prevents 20 program code or data in the digital signature checked second block of memory from being used by the platform.
14. The system as claimed in claim 11 wherein the software security check is performed using a digital signature checking program.
15. The system as claimed in claim 11, 12, 13 or 14 wherein the first 25 further block of memory checked by the checking program includes a part of the boot program memory in which the secure portion of the executable boot program is stored.
16. The system as claimed in claim 11, 12, 13 or 14 wherein the first further block of memory checked by the checking program does not include a 30 part of the boot program memory in which the secure portion of the executable boot program is stored.
17. The system as claimed in any one of claims 1 to 16 wherein, the logic circuit periodically reads from the data bus means data representing an instruction fetched from the boot program memory means, and stores it in a 35 register together with the address from which it was read and subsequently compares the data in the register with the corresponding data read during the WO 01/24012 PCT/AU00/01192 23 verification process and if the data does not match an abnormal condition is indicated.
18. The system of claim 17 wherein, when an abnormal condition is indicated, the platform is prevented from operating until the condition is 5 acknowledged by an operator and corrected.
19. The system of claim 17 or 18 wherein, when an abnormal condition is indicated, data indicative of the abnormal condition is stored in non-volatile memory.
20. The system of claim 19 wherein, when an abnormal condition is 10 indicated, data indicative of the abnormal condition is stored in non-erasable memory.
21. The system as claimed in any one of claims 1 to 20 wherein, the logic circuit includes connection means to allow removable connection to the platform for external verification of the secure program. 15
22. The system as claimed in claims 21 wherein the logic circuit acts as an In-Circuit Emulator (ICE) for the processor means when it is attached to the platform and data stored in the boot program memory means are read via the ICE.
23. The system as claimed in claims 21 wherein the logic circuit 20 incorporates logic which dumps the system memory contents to an external port.
24. The system as claimed in claims 21 wherein, the logic circuit, when requested by asserting a pin on the logic circuit during power up, holds the processor means in a reset state, reads the memory contents and transmits it 25 via a serial port to a personal computer.
25. The system as claimed in claims 21 wherein, the logic circuit responds to requests from a serial port of the platform to dump memory contents to the serial port.
26. A boot program security system associated with a platform for software 30 execution, wherein the security system overrides code fetches when a secure portion of a boot program is being executed on the platform, the boot program containing basic components of a platform operating system which perform a security validation of other software components and authorizes their execution on the platform, the platform including processor means for 35 executing the programs, memory means in which the executable programs are stored and address bus means and data bus means which provide WO 01/24012 PCT/AU00/01192 24 communication between the processor means and the memory means, the security system including secure boot program memory means, and software monitoring means to monitor addresses expressed on the address bus means by the processor means, the software monitoring means being responsive to 5 addresses on the address bus corresponding to address locations allocated to the secure portion of boot program to read the corresponding locations of the secure boot program memory means and to pass the data read from the secure boot program memory means to the processor means for execution.
27. The system of claim 26 wherein the secure boot program memory 10 means, and software monitoring means are implemented in a logic circuit.
28. The system of claim 26 wherein the logic circuit is an Application Specific Integrated Circuit (ASIC).
29. The system of claim 27 wherein the special purpose integrated circuit, is a Field Programmable Gate Array (FPGA). 15
30. The system of claim 27, or 28, or 29 wherein the secure boot program memory means comprises a ROM which is included in the logic circuit.
31. The system as claimed in any one of claims 27 to 30 wherein, when an abnormal condition is indicated, the function of otherwise unrelated parts of the logic circuit are altered. 20
32. The system as claimed in any one of claims 27 to 30 wherein, when an abnormal condition is indicated, the logic circuit resets the processor means.
33. The system as claimed in any one of claims 28 to 30 wherein, when an abnormal condition is indicated, the logic circuit prevents software access to sensitive functions of the platform. 25
34. The system as claimed in claim 33 wherein, when an abnormal condition is indicated, the logic circuit permits program segments relating to non sensitive functions to continue to run, whereby information may be given to a user about the abnormal condition.
35. The system as claimed in claim 33 wherein the platform is a gaming 30 console and the sensitive functions comprise game operation, metering of console parameters, credit input and credit output.
36. The system as claimed in any one of claims 26 to 35 wherein, the secure portion of the executable boot program stored in the secure boot program memory means contains a checking program which performs a software security check 35 of a first further block of memory and if the security check fails the boot WU UII/A4UI r1 I/AUUUlUIIYL 25 program prevents program code or data in the security checked block of memory from being used by the platform.
37. The system as claimed in claim 36 wherein the software security check is performed using a secure hash checking program. 5
38. The system as claimed in claim 36 or 37 wherein, the block of memory checked by the software security check contains a digital signature checking program which performs a digital signature check of a second further block of memory and if the digital signature check fails the boot program prevents program code or data in the digital signature checked second block of 10 memory from being used by the platform.
39. The system as claimed in claim 36 wherein the software security check is performed using a digital signature checking program.
40. The system as claimed in claim 36, 37. 38. or 39 wherein the first further block of memory checked by the checking program includes the secure boot 15 program memory means in which the secure portion of the executable boot program is stored.
41. The system as claimed in claim 36, 37, 38, or 39 wherein the first further block of memory checked by the checking program does not include the secure boot program memory means in which the secure portion of the 20 executable boot program is stored.
42. The system as claimed in any one of claims 26 to 41 wherein, the logic circuit periodically reads from the data bus means data representing an instruction fetched from the secure boot program memory means, and stores it in a register together with the address from which it was read and 25 subsequently compares the data in the register with the corresponding data in the secure boot program memory means and if the data does not match an abnormal condition is indicated.
43. The system of claim 42 wherein, when an abnormal condition is indicated, the platform is prevented from operating until the condition is 30 acknowledged by an operator and corrected.
44. The system of claim 42 or 43 wherein, when an abnormal condition is indicated, data indicative of the abnormal condition is stored in non-volatile memory.
45. The system of claim 44 abnormal condition is stored in non-erasable 35 memory. VV" Ual TUnkwAr 1T.1/ALJUUU11YL 26
46. A boot program security system associated with a platform for software execution, wherein the security system verifies an executable boot program to be executed on the platform and which contains basic components of a platform operating system which perform a security validation of other 5 software components and authorizes their execution on the platform, the platform including processor means for executing the executable boot program, boot program memory means in which the executable boot program is stored, and address bus means and data bus means which provide communication between the processor means and the boot program memory 10 means, the security system including boot checking memory means, comparison means, and software reading means to read data from the boot program memory means corresponding to a secure portion of the executable boot program and providing the data read from the boot program memory means to the comparison means for comparison with corresponding data in 15 the boot checking code memory means and, if the data does not match, producing a signal to indicate an abnormal condition.
47. the system of claim 46 wherein the logic circuit compares the memory while the processor means is in a reset state.
48. the system of claim 46 wherein the logic circuit compares the memory 20 while the processor means is in a halt state.
49. The system of claim 46, 47, or 48 wherein the boot checking code memory means, the comparison means, and the software reading means are implemented in a logic circuit.
50. The system of claim 49 wherein the logic circuit is an Application 25 Specific Integrated Circuit (ASIC).
51. The system of claim 49 wherein the special purpose integrated circuit, is a Field Programmable Gate Array (FPGA).
52. The system of claim 49, or 52 wherein the boot checking code memory means comprises a ROM which is included in the logic circuit. 30
53. The system as claimed in any one of claims 49 to 52 wherein, when an abnormal condition is indicated, the function of otherwise unrelated parts of the logic circuit are altered.
54. The system as claimed in any one of claims 49 to 52 wherein, when an abnormal condition is indicated, the logic circuit resets the processor means. 35
55. The system as claimed in any one of claims 49to 54 wherein, when an abnormal condition is indicated, the logic circuit prevents software access to WO 01/24012 PCT/AU00/01192 27 sensitive functions of the platform.
56. The system as claimed in claim 55 wherein, when an abnormal condition is indicated, the logic circuit permits program segments relating to non sensitive functions to continue to run, whereby information may be given to a 5 user about the abnormal condition.
57. The system as claimed in claim 56 wherein the platform is a gaming console and the sensitive functions comprise game operation, metering of console parameters, credit input and credit output.
58. The system as claimed in any one of claims 46 to 57 wherein, the secure 10 portion of the executable boot program checked by the logic circuit contains a checking program which performs a software security check of a first further block of memory and if the security check fails the boot program prevents program code or data in the security checked block of memory from being used by the platform. 15
59. The system as claimed in claim 58 wherein the software security check is performed using a secure hash checking program.
60. The system as claimed in claim 58 or 59 wherein, the block of memory checked by the software security check contains a digital signature checking program which performs a digital signature check of a second further block of 20 memory and if the digital signature check fails the boot program prevents program code or data in the digital signature checked second block of memory from being used by the platform.
61. The system as claimed in claim 58 wherein the software security check is performed using a digital signature checking program. 25
62. The system as claimed in claim 58, 59, 60, or 61 wherein the first further block of memory checked by the checking program includes a part of the boot program memory in which the secure portion of the executable boot program is stored.
63. The system as claimed in claim 58, 59, 60, or 61 wherein the first 30 further block of memory checked by the checking program does not include a part of the boot program memory in which the secure portion of the executable boot program is stored.
64. The system as claimed in any one of claims 46 to 63 wherein, the logic circuit periodically reads from the data bus means data representing an 35 instruction fetched from the boot program memory means, and stores it in a register together with the address from which it was read and subsequently VVj UV1.u I rIi/AUUU/UII Y, 28 compares the data in the register with the corresponding data read during the verification process and if the data does not match an abnormal condition is indicated.
65. The system of claim 64 wherein, when an abnormal condition is 5 indicated, the platform is prevented from operating until the condition is acknowledged by an operator and corrected.
66. The system of claim 64 or 65 wherein, when an abnormal condition is indicated, data indicative of the abnormal condition is stored in non-volatile memory. 10
67. The system of claim 66 wherein, when an abnormal condition is indicated, data indicative of the abnormal condition is stored in non-erasable memory.
68. The system as claimed in any one of claims 46 to 67 wherein, the logic circuit includes connection means to allow removable connection to the platform for 15 external verification of the secure program.
69. The system as claimed in claims 68 wherein the logic circuit acts as an In-Circuit Emulator (ICE) for the processor means when it is attached to the platform and data stored in the boot program memory means are read via the ICE. 20
70. The system as claimed in claims 68 wherein the logic circuit incorporates logic which dumps the system memory contents to an external port.
71. The system as claimed in claims 69 wherein, the logic circuit, when requested by asserting a pin on the logic circuit during power up, holds the 25 processor means in a reset state, reads the memory contents and transmits it via a serial port to a personal computer.
72. The system as claimed in claims 69 wherein, the logic circuit responds to requests from a serial port of the platform to dump memory contents to the serial port. 30
73. A security override device for overriding a secure program stored in a secure program memory and verified prior to or during execution, including override program storage means holding a program which will be executed in place of the secure program during selected periods, verification detection means to detect completion of a verification process performed on the secure 35 program and multiplexing means to multiplex the override program storage means with the secure program means, whereby the override program storage TV',% UId149Vk1 r% 1/1AUUUIU1IYh 29 means is mapped in and out of memory space to selectively execute the override program.
74. A method of verifying an executable boot program associated with a platform for software execution, the boot program being for execution on the 5 platform and containing basic components of a platform operating system which perform a security validation of other software components and authorizes their execution on the platform, the platform including processor means for executing the executable boot program, boot program memory means in which the executable boot program is stored, and address bus 10 means and data bus means which provide communication between the processor means and the boot program memory means, a verification system including boot checking memory means, comparison means, and software monitoring means and the method including the steps of, the software monitoring means monitoring addresses expressed on the 15 address bus means by the processor means, the software monitoring means being responsive to addresses on the address bus corresponding to locations in which a secure portion of the executable boot program is stored, to read data expressed on the data bus means by the boot program memory means and representing words of the 20 executable boot program being verified, and providing the data read from the data bus to the comparison means, the comparison means comparing the data read from the data bus with corresponding data in the boot checking code memory means, and if the data does not match, the comparison means producing a signal to 25 indicate an abnormal condition.
75. The method of claim 74 wherein the boot checking code memory means, the comparison means, and the software monitoring means are implemented in a logic circuit.
76. The method of claim 75 wherein the logic circuit is an Application 30 Specific Integrated Circuit (ASIC).
77. The method of claim 75 wherein the special purpose integrated circuit, is a Field Programmable Gate Array (FPGA).
78. The method of claim 75, 76, 77 wherein the boot checking code memory means comprises a ROM which is included in the logic circuit (supplies the data 35 to the CPU). VVWU UIhI4U L YrL.k I/AUUUIUIYL 30
79. The method as claimed in any one of claims 75 to 78 wherein, when an abnormal condition is indicated, the function of otherwise unrelated parts of the logic circuit are altered.
80. The method as claimed in any one of claims 75 to 78 wherein, when an 5 abnormal condition is indicated, the logic circuit resets the processor means.
81. The method as claimed in any one of claims 75 to 78 wherein, when an abnormal condition is indicated, the logic circuit prevents software access to sensitive functions of the platform.
82. The method as claimed in claim 81 wherein, when an abnormal condition 10 is indicated, the logic circuit permits program segments relating to non sensitive functions to continue to run, whereby information may be given to a user about the abnormal condition.
83. The method as claimed in claim 81 wherein the platform is a gaming console and the sensitive functions comprise game operation, metering of 15 console parameters, credit input and credit output.
84. The method as claimed in any one of claims 74 to 83 wherein, the secure portion of the executable boot program checked by the logic circuit contains a checking program which performs a software security check of a first further block of memory and if the security check fails the boot program prevents 20 program code or data in the security checked block of memory from being used by the platform.
85. The method as claimed in claim 84 wherein the software security check is performed using a secure hash checking program.
86. The method as claimed in claim 84 or 85 wherein, the block of memory 25 checked by the software security check contains a digital signature checking program which performs a digital signature check of a second further block of memory and if the digital signature check fails the boot program prevents program code or data in the digital signature checked second block of memory from being used by the platform. 30
87. The method as claimed in claim 84 wherein the software security check is performed using a digital signature checking program.
88. The method as claimed in claim 84, 85, 86, or 87 wherein the first further block of memory checked by the checking program includes a part of the boot program memory in which the secure portion of the executable boot 35 program is stored. Vv v vu7 vIhk r' AULL)UUIU117L 31
89. The method as claimed in claim 84, 85, 86, or 87 wherein the first further block of memory checked by the checking program does not include a part of the boot program memory in which the secure portion of the executable boot program is stored. 5
90. The method as claimed in any one of claims 74 to 89 wherein, the logic circuit periodically reads from the data bus means data representing an instruction fetched from the boot program memory means, and stores it in a register together with the address from which it was read and subsequently compares the data in the register with the corresponding data read during the 10 verification process and if the data does not match an abnormal condition is indicated.
91. The method of claim 90 wherein, when an abnormal condition is indicated, the platform is prevented from operating until the condition is acknowledged by an operator and corrected. 15
92. The method of claim 90 or 91 wherein, when an abnormal condition is indicated, data indicative of the abnormal condition is stored in non-volatile memory.
93. The method of claim 92 wherein, when an abnormal condition is indicated, data indicative of the abnormal condition is stored in non-erasable 20 memory.
94. The method as claimed in any one of claims 74 to 93 wherein, the logic circuit includes connection means to allow removable connection to the platform for external verification of the secure program.
95. The method as claimed in claims 94 wherein the logic circuit acts as an 25 In-Circuit Emulator (ICE) for the processor means when it is attached to the platform and data stored in the boot program memory means are read via the ICE.
96. The method as claimed in claims 94 wherein the logic circuit incorporates logic which dumps the system memory contents to an external 30 port.
97. The method as claimed in claims 94 wherein, the logic circuit, when requested by asserting a pin on the logic circuit during power up, holds the processor means in a reset state, reads the memory contents and transmits it via a serial port to a personal computer. 32
98. The method as claimed in claims 94 wherein, the logic circuit responds to requests from a serial port of the platform to dump memory contents to the serial port.
99. A method of running a boot program on a platform for software 5 execution in a secure manner by overriding code fetches when a secured portion of the boot program is being executed on the platform, the boot program containing basic components of a platform operating system which perform a security validation of other software components and authorizes their execution on the platform, the platform including processor means for 10 executing the programs, memory means in which the executable programs are stored and address bus means and data bus means which provide communication between the processor means and the memory means, and a security system including secure boot program memory means, and software monitoring means to monitor addresses expressed on the address bus means 15 by the processor means, the method comprising the steps of, monitoring addresses on the address bus and detecting addresses corresponding to address locations allocated to the secure portion of boot program, reading the corresponding locations of the secure boot program 20 memory means, and passing the data read from the secure boot program memory means to the processor means for execution.
100. The method of claim 99 wherein the secure boot program memory means, and software monitoring means are implemented in a logic circuit. 25
101. The method of claim 99 wherein the logic circuit is an Application Specific Integrated Circuit (ASIC).
102. The method of claim 100 wherein the special purpose integrated circuit, is a Field Programmable Gate Array (FPGA).
103. The method of claim 100, 101, or 102 wherein the secure boot program 30 memory means comprises a ROM which is included in the logic circuit.
104. The method as claimed in any one of claims 100 to 103 wherein, when an abnormal condition is indicated, the function of otherwise unrelated parts of the logic circuit are altered.
105. The method as claimed in any one of claims 100 to 103 wherein, when an 35 abnormal condition is indicated, the logic circuit resets the processor means. WO 01/24012 PCT/AU00/01192 33
106. The method as claimed in any one of claims 100 to 103 wherein, when an abnormal condition is indicated, the logic circuit prevents software access to sensitive functions of the platform.
107. The method as claimed in claim 106 wherein, when an abnormal condition 5 is indicated, the logic circuit permits program segments relating to non sensitive functions to continue to run, whereby information may be given to a user about the abnormal condition.
108. The method as claimed in claim 106 wherein the platform is a gaming console and the sensitive functions comprise game operation, metering of 10 console parameters, credit input and credit output.
109. The method as claimed in any one of claims 99 to 108 wherein, the secure portion of the executable boot program stored in the secure boot program memory means contains a checking program which performs a software security check of a first further block of memory and if the security check fails the boot 15 program prevents program code or data in the security checked block of memory from being used by the platform.
110. The method as claimed in claim 109 wherein the software security check is performed using a secure hash checking program.
111. The method as claimed in claim 109 or 110 wherein, the block of 20 memory checked by the software security check contains a digital signature checking program which performs a digital signature check of a second further block of memory and if the digital signature check fails the boot program prevents program code or data in the digital signature checked second block of memory from being used by the platform. 25
112. The method as claimed in claim 109 wherein the software security check is performed using a digital signature checking program.
113. The method as claimed in claim 109, 110, 111, or 112 wherein the first further block of memory checked by the checking program includes the secure boot program memory means in which the secure portion of the executable boot 30 program is stored.
114. The method as claimed in claim 109, 110, 111, or 112 wherein the first further block of memory checked by the checking program does not include the secure boot program memory means in which the secure portion of the executable boot program is stored. 35
115. The method as claimed in any one of claims 99 to 114 wherein, the logic circuit periodically reads from the data bus means data representing an instruction WO 01/24012 PCT/AU00/01192 34 fetched from the secure boot program memory means, and stores it in a register together with the address from which it was read and subsequently compares the data in the register with the corresponding data in the secure boot program memory means and if the data does not match an abnormal condition is indicated. 5
116. The method of claim 115 wherein, when an abnormal condition is indicated, the platform is prevented from operating until the condition is acknowledged by an operator and corrected.
117. The method of claim 115 or 116 wherein, when an abnormal condition is indicated, data indicative of the abnormal condition is stored in non 10 volatile memory.
118. The method of claim 117 wherein, when an abnormal condition is indicated, data indicative of the abnormal condition is stored in non-erasable memory.
119. A method of verifying an executable boot program associated with a 15 platform for software execution, the boot program being for execution on the platform and containing basic components of a platform operating system which perform a security validation of other software components and authorizes their execution on the platform, the platform including processor means for executing the executable boot program, boot program memory 20 means in which the executable boot program is stored, and address bus means and data bus means which provide communication between the processor means and the boot program memory means, and a security system including boot checking memory means, comparison means, and software reading means, the method comprising the steps of, 25 reading data from the boot program memory means corresponding to a secure portion of the executable boot program, providing the data read from the boot program memory means to the comparison means, comparing the data read from the boot program memory means with 30 corresponding data in the boot checking code memory means, and if the data does not match, producing a signal to indicate an abnormal condition.
120. the method of claim 119 wherein the logic circuit compares the memory while the processor means is in a reset state. 35 121. the method of claim 119 wherein the logic circuit compares the memory while the processor means is in a halt state.
WU U1L4U1L rtL 1/AUUU/U11VL 35
122. The method of claim 119, 120, 121 wherein the boot checking code memory means, the comparison means, and the software reading means are implemented in a logic circuit.
123. The method of claim 122 wherein the logic circuit is an Application 5 Specific Integrated Circuit (ASIC).
124. The method of claim 122 wherein the special purpose integrated circuit, is a Field Programmable Gate Array (FPGA).
125. The method of claim 122, 123, 124 wherein the boot checking code memory means comprises a ROM which is included in the logic circuit. 10
126. The method as claimed in any one of claims 122 to 125 wherein, when an abnormal condition is indicated, the function of otherwise unrelated parts of the logic circuit are altered.
127. The method as claimed in any one of claims 122 to 125 wherein, when an abnormal condition is indicated, the logic circuit resets the processor means. 15
128. The method as claimed in any one of claims 122 to 125 wherein, when an abnormal condition is indicated, the logic circuit prevents software access to sensitive functions of the platform.
129. The method as claimed in claim 128 wherein, when an abnormal condition is indicated, the logic circuit permits program segments relating to non 20 sensitive functions to continue to run, whereby information may be given to a user about the abnormal condition.
130. The method as claimed in claim 128wherein the platform is a gaming console and the sensitive functions comprise game operation, metering of console parameters, credit input and credit output. 25
131. The method as claimed in any one of claims 119 to 130 wherein, the secure portion of the executable boot program checked by the logic circuit contains a checking program which performs a software security check of a first further block of memory and if the security check fails the boot program prevents program code or data in the security checked block of memory from being 30 used by the platform.
132. The method as claimed in claim 131 wherein the software security check is performed using a secure hash checking program.
133. The method as claimed in claim 131 or 132 wherein, the block of memory checked by the software security check contains a digital signature 35 checking program which performs a digital signature check of a second further block of memory and if the digital signature check fails the boot VVU v/lh14ul YL 1/AUUU/UIIMYL 36 program prevents program code or data in the digital signature checked second block of memory from being used by the platform.
134. The method as claimed in claim 131 wherein the software security check is performed using a digital signature checking program. 5
135. The system as claimed in claim 131, 132, 133, or 134 wherein the first further block of memory checked by the checking program includes a part of the boot program memory in which the secure portion of the executable boot program is stored.
136. The method as claimed in claim 131, 132, 133, or 134 wherein the first 10 further block of memory checked by the checking program does not include a part of the boot program memory in which the secure portion of the executable boot program is stored.
137. The method as claimed in any one of claims 119 to 136 wherein, the logic circuit periodically reads from the data bus means data representing an 15 instruction fetched from the boot program memory means, and stores it in a register together with the address from which it was read and subsequently compares the data in the register with the corresponding data read during the verification process and if the data does not match an abnormal condition is indicated. 20
138. The method of claim 137 wherein, when an abnormal condition is indicated, the platform is prevented from operating until the condition is acknowledged by an operator and corrected.
139. The method of claim 137 or 138 wherein, when an abnormal condition is indicated, data indicative of the abnormal condition is stored in non 25 volatile memory.
140. The method of claim 139 wherein, when an abnormal condition is indicated, data indicative of the abnormal condition is stored in non-erasable memory.
141. The method as claimed in any one of claims 119 to 140 wherein, the logic 30 circuit includes connection means to allow removable connection to the platform for external verification of the secure program.
142. The method as claimed in claims 141 wherein the logic circuit acts as an In-Circuit Emulator (ICE) for the processor means when it is attached to the platform and data stored in the boot program memory means are read via 35 the ICE. VVLJ U/UIL rL I/ UUUIUIIYL 37
143. The method as claimed in claims 141 wherein the logic circuit incorporates logic which dumps the system memory contents to an external port.
144. The method as claimed in claims 141 wherein, the logic circuit, when 5 requested by asserting a pin on the logic circuit during power up, holds the processor means in a reset state, reads the memory contents and transmits it via a serial port to a personal computer.
145. The method as claimed in claims 141 wherein, the logic circuit responds to requests from a serial port of the platform to dump memory contents to the serial 10 port.
146. A method of overriding a secure program stored in a secure program memory and verified prior to or during execution, including the steps of storing an override program in an override program storage means, the override program being a program which will be executed in place of the 15 secure program during selected periods, detecting completion of a verification process performed on the secure program and multiplexing the override program storage means with the secure program means, whereby while the verification of the secure program is not in progress the override program storage means is mapped in and out of the memory space to selectively 20 execute the override program.
147. A method of verifying a game program in a gaming machine arranged to play a plurality of games where each game is implemented in a separate game program, wherein the gaming machine is provided with an interface for connection of a secure authorization device which is used to authorize a 25 game program to run, the method comprising the steps of the gaming machine sending an authorization request message to the secure authorization device identifying the game requiring authorization, if the secure authorization device contains a game identification for the game requiring authorization it responds with a message authorizing the 30 game, if the secure authorization device does not contain a game identification for the game requiring authorization it does not respond or responds with a negative message, the gaming machine verifies that the message received from the secure 35 authorization device are from a valid device, VVwU U1LL.,U 1 I/AUUU/UIIVZ 38 the gaming machine only permits the game to be played if it receives with a message authorizing the game from the secure authorization device and it verifies that the secure authorization device is valid.
148. The method of claim 147, wherein the secure authorization device is a 5 smartcard.
149. The method of claim 147 or 148, wherein the secure authorization device uses digital signatures to sign a game authorization message.
150. The method of claim 147, 148, or 149, wherein the gaming machine holds a signature public key for the secure authorization device and can 10 check the signed game authorization message and the validity of the secure authorization device.
151. The method of claim 147, 148, 149, or 150, wherein each game is authorized for a limited period and the secure authorization device will only authorize a game if the period has not expired. 15
152. The method of claim 147, 148, 149, 150, or 151, wherein a previously authorized game will cease to operate if the secure authorization device is removed from the gaming machine.
AU78884/00A 1999-09-30 2000-09-29 Gaming security system Expired AU778171B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU78884/00A AU778171B2 (en) 1999-09-30 2000-09-29 Gaming security system

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
AUPQ3216A AUPQ321699A0 (en) 1999-09-30 1999-09-30 Gaming security system
AUPQ3216 1999-09-30
PCT/AU2000/001192 WO2001024012A1 (en) 1999-09-30 2000-09-29 Gaming security system
AU78884/00A AU778171B2 (en) 1999-09-30 2000-09-29 Gaming security system

Publications (2)

Publication Number Publication Date
AU7888400A true AU7888400A (en) 2001-04-30
AU778171B2 AU778171B2 (en) 2004-11-18

Family

ID=25639056

Family Applications (1)

Application Number Title Priority Date Filing Date
AU78884/00A Expired AU778171B2 (en) 1999-09-30 2000-09-29 Gaming security system

Country Status (1)

Country Link
AU (1) AU778171B2 (en)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5643086A (en) * 1995-06-29 1997-07-01 Silicon Gaming, Inc. Electronic casino gaming apparatus with improved play capacity, authentication and security
US5802592A (en) * 1996-05-31 1998-09-01 International Business Machines Corporation System and method for protecting integrity of alterable ROM using digital signatures
GB9626241D0 (en) * 1996-12-18 1997-02-05 Ncr Int Inc Secure data processing method and system

Also Published As

Publication number Publication date
AU778171B2 (en) 2004-11-18

Similar Documents

Publication Publication Date Title
US9026802B2 (en) Gaming security system
US7827397B2 (en) Gaming machine having a secure boot chain and method of use
AU2009202726B2 (en) BIOS protection device
USRE39368E1 (en) Electronic casino gaming system with improved play capacity, authentication and security
US8827802B2 (en) Electronic gaming machine including a smartcard for protection, and method of use
CA2844557C (en) Multi-tiered static chain of trust
US7320642B2 (en) Security of gaming software
US20110202752A1 (en) Semiconductor device including encryption section, semiconductor device including external interface, and content reproduction method
AU2009202742B2 (en) Gaming security system
Levinthal et al. The Silicon Gaming Odyssey Slot Machine
AU778171B2 (en) Gaming security system
AU2013205523A1 (en) Electronic casino gaming system with improved play capacity, authentication and security
AU2017204350B2 (en) An electronic gaming machine
AU2011218679A1 (en) Gaming security system
AU2012245181B2 (en) Bios protection device
AU2012202166A1 (en) An electronic gaming machine

Legal Events

Date Code Title Description
MK14 Patent ceased section 143(a) (annual fees not paid) or expired