Skip to main content

GAT: authenticating gaming machine software for GLI

When an electronic gaming machine (EGM) reaches a casino floor, the regulator needs one simple guarantee: the software running on that machine is exactly what the lab certified. Not an older version, not a “small” patch, not a file changed by hand. That is what GAT is for.

This article covers what GAT is, what actually gets authenticated, and the architecture decision that helped me most when taking an EGM platform through GLI certification for the USA and Canada.

What GAT is

GAT (Game Authentication Terminal) is a protocol defined by GLI that lets an external verifier (the lab, the regulator or an on-site inspector) ask the machine to compute signatures of its software and return them. The verifier compares those signatures against the reference values of the certified version. If they match, the machine runs approved software. If not, something changed.

The key idea is that the machine does not say “I am version 1.4.2”. It computes a hash over the real bytes of its components, usually with a seed provided by the verifier so the answer cannot be precomputed or copied from another machine.

What gets authenticated: controlled components

Not all EGM software is authenticated. What matters are the controlled components (GLI calls them critical control program components): the code that decides game outcomes, handles money or reports to the casino system.

On the platform we certified, what certification asked to compare were the controlled components that do not change between games: the main executable and the platform pieces every game shares. For each game, the lab compared hashes and versions of those components against the already approved ones.

That has a huge practical consequence: if the hash of the main executable is identical to the previous certification, the lab knows without reviewing anything else that the platform was not touched. Review focuses on what is actually new, the game.

Split platform from game

That comparison only works if the architecture allows it. What I recommend:

  • Stable platform, games on top. The main executable, SAS communication, peripheral handling (printer, bill validator), NVRAM and audit live in components that do not change when a new game ships. Game logic and assets go separately.
  • Explicit versions per component. Every controlled component has its version and hash documented. When a game is submitted, the list of components and hashes is part of the package.
  • Reproducible builds. The same source must produce the same bytes. If the build embeds dates, build machine paths or random values, the hash changes even when the code does not, and you have to explain why to the lab.
  • Nothing mutable inside what is authenticated. Logs, operator configuration, NVRAM and temporary files stay outside controlled components. If a file changes at runtime and is inside the hash, the machine fails authentication on its own.
  • Hardened operating system. A read-only system (locked-down Windows IoT in our case) keeps authenticated files from changing after install.

GAT and SAS are not the same

SAS also has signature verification: the casino management system can ask the machine for a seeded CRC of its program. It is useful for continuous monitoring from the floor. GAT is meant for the lab and the regulator, with the formal list of components and signatures behind the certification. A serious EGM implements both.

Common mistakes

  • Hashing an entire folder that includes files the game writes.
  • Changing the main executable “just for one game”, which forces recertifying the whole platform.
  • Not documenting which files make up each controlled component, and finding out during lab review.
  • Builds that cannot be reproduced months later, when the regulator asks to verify an old version.

Need help with GAT or GLI?

We are a Mexico City team, in US and Canadian time zones, working with manufacturers and game studios on SAS integration, peripherals and GLI certification. See what we do in SAS and EGM consulting or reach out directly.