GAT: cómo autenticar el software de una máquina de juego para GLI
Cuando una máquina electrónica de juego (EGM) llega al piso de un casino, el regulador necesita una garantía simple: el software que corre en esa máquina es exactamente el que el laboratorio certificó. Ni una versión anterior, ni un parche “pequeño”, ni un archivo cambiado a mano. Para eso existe GAT.
En este artículo explico qué es GAT, qué se autentica realmente y la decisión de arquitectura que más me ayudó al llevar una plataforma de EGM a certificación GLI para USA y Canadá.
Qué es GAT
GAT (Game Authentication Terminal) es un protocolo definido por GLI para que un verificador externo (el laboratorio, el regulador o un inspector en el casino) le pida a la máquina que calcule firmas de su software y las devuelva. El verificador compara esas firmas contra los valores de referencia de la versión certificada. Si coinciden, la máquina corre software aprobado. Si no, algo cambió.
La idea clave es que la máquina no dice “soy la versión 1.4.2”. Calcula un hash sobre los bytes reales de sus componentes, normalmente con una semilla que proporciona el verificador para que la respuesta no se pueda precalcular ni copiar de otra máquina.
Qué se autentica: los componentes controlados
No todo el software de una EGM se autentica. Lo que importa son los componentes controlados (GLI los llama componentes críticos del programa de control): el código que decide el resultado del juego, maneja dinero o reporta al sistema del casino.
En la plataforma que certificamos, lo que la certificación pedía comparar eran los componentes controlados que no cambian entre juegos: el ejecutable principal (el main) y las piezas de la plataforma que comparten todos los juegos. Para cada juego, el laboratorio comparaba hashes y versiones de esos componentes contra los ya aprobados.
Eso tiene una consecuencia práctica enorme: si el hash del main es idéntico al de la certificación anterior, el laboratorio sabe sin revisar nada más que la plataforma no se tocó. La revisión se concentra en lo que sí es nuevo, el juego.
Separar plataforma y juego
Esa comparación solo funciona si la arquitectura la permite. Lo que recomiendo:
- Plataforma estable, juegos encima. El main, la comunicación SAS, el manejo de periféricos (impresora, validador de billetes), NVRAM y auditoría viven en componentes que no cambian cuando sale un juego nuevo. La lógica y los recursos del juego van aparte.
- Versiones explícitas por componente. Cada componente controlado tiene su versión y su hash documentados. Cuando un juego se envía a certificar, la lista de componentes y hashes es parte del paquete.
- Builds reproducibles. El mismo código fuente tiene que producir los mismos bytes. Si el build incrusta fechas, rutas de la máquina de compilación o números aleatorios, el hash cambia aunque el código no, y eso obliga a explicar al laboratorio por qué.
- Nada mutable dentro de lo autenticado. Logs, configuración del operador, NVRAM y archivos temporales van fuera de los componentes controlados. Si un archivo cambia en tiempo de ejecución y está dentro del hash, la máquina falla la autenticación sola.
- Sistema operativo endurecido. Un sistema de solo lectura (en nuestro caso Windows IoT bloqueado) evita que lo autenticado cambie después de instalar.
GAT y SAS no son lo mismo
SAS también tiene verificación de firma: el sistema de gestión del casino puede pedir a la máquina un CRC de su programa con una semilla. Es útil para monitoreo continuo desde el piso. GAT está pensado para el laboratorio y el regulador, con la lista formal de componentes y firmas que respaldan la certificación. Una EGM seria implementa ambos.
Errores comunes
- Calcular el hash sobre una carpeta completa que incluye archivos que el juego escribe.
- Cambiar el main “solo para un juego”, lo que obliga a recertificar la plataforma completa.
- No documentar qué archivos forman cada componente controlado, y descubrirlo en la revisión del laboratorio.
- Builds que no se pueden reproducir meses después, cuando el regulador pide verificar una versión vieja.
¿Necesitas ayuda con GAT o GLI?
Somos un equipo en Ciudad de México que trabaja con fabricantes y estudios de juegos en la integración de SAS, periféricos y certificación GLI. Puedes ver lo que hacemos en desarrollo SAS y periféricos EGM o escribirnos directamente.