6. Integrity of Critical Software and Critical Game Data
Authentication of Critical Software
6.1.1 A mechanism shall be built into the ELS to verify the integrity of the Critical Software that is deployed to production, including before changes are implemented as well as on an ongoing basis, to ensure approved software is being used with no unauthorized changes.
6.1.2 At a minimum, the ELS must be successfully authenticated:
- Immediately prior to startup;
- Automatically at regular intervals during operation;
- Before Lottery Draw for jackpot prizes; and
- On demand by the Operator, or AGCO.
6.1.3 The authentication method must be based on good industry practices to ensure security and integrity. An example of an authentication method is calculation of software SHA-1 values which are compared against a protected master list of signatures (i.e. encrypted SHA-1 values).
6.1.4 If the self-authentication fails, the software that fails authentication must enter an error condition, safely stop operation and notify the Operator. The AGCO must be immediately notified of the failure, including the details of the failed authentication.
6.1.5 The results of each authentication must be recorded in an unalterable report which is available to the AGCO. This report must include a pass/fail condition with details on which software did not pass the authentication.
6.1.6 Modifiable files such as configuration settings do not need to be included in any of these software verifications required by 6.1.1 and 6.1.2. However, the configurations that are critical must only be settable in a way that does not compromise Game integrity.
Self-Authentication of Critical Software in Volatile Memory
6.1.7 Critical Software components, excluding graphics and sound components, must be fully authenticated at the time of loading into electrically erasable or volatile memory (prior to execution), and at minimum, following any Lottery Terminal and Self-Service Terminal resets and power up. Impacted functions must be disabled if an invalid component is detected.
Remote Authentication of Lottery POS Critical Software
6.1.8 Backend System must initiate independent authentication on all Lottery Terminal and Self-Service Terminal Critical Software upon initial establishment of a connection with the system. When a threshold of unsuccessful authentication attempts is reached, the Lottery Terminal or Self-Service Terminal must be disabled.
Critical Game Data Integrity
6.1.9 The ELS must accurately maintain the integrity of Critical Game Data to ensure the Lottery Game operates as expected and is auditable.
6.1.10 The ELS must employ methods to detect corruption and unauthorized alteration to its Critical Game Data to prevent integrity issues from occurring.
6.1.11 Detection of corrupted or unauthorized alteration of Critical Game Data that cannot be recovered must cause Lottery Ticket sales at impacted Lottery Terminals and Self-Service Terminals to be halted immediately, and must cause the POS to enter into an error condition and not resume Lottery Ticket sales until the condition has been addressed.
6.1.12 The integrity of Critical Game Data at the Lottery Terminal and Self-Service Terminal must be maintained by methodology that enables failure detection, backup and recovery of Critical Game Data.
6.1.13 It must be possible to extract Critical Game Data at the Lottery Terminal and Self-Service Terminal through Restricted Technical Procedures without contaminating the data in the original storage media.
6.1.14 Clearing of Critical Game Data must only be performed through a Restricted Technical Procedure.
6.1.15 Lottery Terminal and Self-Service Terminal applications must preserve the integrity of any Critical Game Data stored in Critical Memory by a methodology that enables failure detection and recovery of Critical Game Data. If recovery is not possible, the impacted ELS functions must enter an error condition, safely stop operation, and alert the Operator of the failure.