RNG-сертификация и тесты честности

1) Зачем нужна RNG-сертификация

• подтверждают криптографическую случайность и отсутствие смещений;
• доказывают соответствие юридическим стандартам (лицензии, технические регламенты);
• укрепляют доверие игроков и платежных/регуляторных партнеров.

2) Типология RNG и требования

TRNG (аппаратные): шум диодов/джиттер/физические процессы → высокая энтропия, обязательна пост-обработка (вытягиватели, например, Von Neumann, XOR-folding).
CSPRNG (криптостойкие): детерминированы, но непредсказуемы при секретном seed: CTR_DRBG/HMAC_DRBG (NIST 800-90A), Fortuna и др.

• ≥128 бит энтропии в начальном seed, документированная policies reseed.
• Разделение источников энтропии (системные, аппаратные, внешние) и их мониторинг.
• Устойчивость к предсказанию, backtracking и state compromise.
• Изоляция RNG в sandbox/TEE/HSM; отсутствие «админских рычагов» влияния на результат.

3) Нормативные рамки и лаборатории

• GLI-11 / GLI-19 (требования к играм/онлайн-системам),
• ISO/IEC 17025 (аккредитация лабораторий),
• отчеты eCOGRA, iTech Labs, BMM Testlabs, GLI, QUINEL, SIQ, Trisigma.

Регуляторы (примерно): UKGC, MGA, AGCO, NJ DGE и др. требуют: валидный сертификат RNG, пакеты тестов RTP/волатильности, контроль версий бинаров и неизменяемые журналы.

4) Что именно тестируют при сертификации

1. Статистическая случайность: батареи тестов (см. §5).
2. Интеграция RNG ↔ игра: корректный вызов, отсутствие утечек через время/латентность, защита от повторного использования значений.
3. Математика игры: симуляции 10^7–10^8+ спинов/раундов на соответствие Design RTP и профилю волатильности.
4. Целостность поставки: хэши бинаров/скриптов, сигнатуры, контроль сборок.
5. Операционные политики: seeding, reseed, key-rotation, мониторинг энтропии.

5) Статистические батареи (ядро проверки)

• NIST SP 800-22: Monobit, Runs, Approximate Entropy, FFT, Cumulative Sums и др.
• Diehard/Dieharder: Birthday Spacings, Overlapping 5-Permutation, Rank Tests.
• TestU01 (SmallCrush/Crush/BigCrush): строгий индустриальный стандарт.
• Дополнительно: Serial correlation, Poker, Chi-square, KS-тест.

• p-values в допустимом интервале (обычно 0.01–0.99), провалы → расследование/ретест.
• Размеры выборок: не менее 10^6–10^7 выводов на тест; для BigCrush — больше.
• Репликация на разных seed/платформах, контроль зависимости от времени.

6) RTP/волатильность: симуляции и допуски

Design RTP (задекларированный) vs Observed RTP (из симуляций/продакшна).
Допуски: обычно ±0.5–1.0 п.п. на больших объемах (уточняется условиями сертификации).
Проверка профиля волатильности (стандартное отклонение профита/спред по кластерам исходов).
В отчете: доверительные интервалы, объем симуляций, генерация исходов строго через сертифицированный RNG-вызов.

7) Архитектура «Fair Play by Design»

Изоляция и целостность

RNG в TEE/контейнере; доступ к состоянию закрыт; вызовы подписываются.
Immutable/WORM-журналы исходов, подписи таймстемпов, контроль целостности (Merkle-цепи).

Прозрачность

Проведенные игры: хэш результата ± возможность пост-верификации.
Provably Fair (опционально): схема server-seed/client-seed/nonce для P2P/крипто-сценариев, с публичной проверкой.

Интеграция

API-прокси с анти-tamper (HMAC/TLS-pinning), лимиты, защита от повторов.
Раздельные ключи подписи для среды dev/stage/prod; строго запрещены prod-ключи в тестах.

8) Энтропия, seeding и reseed (политики)

Источники: TRNG (если есть), ОС (e.g., /dev/urandom), сетевые/тайминговые шумы (с осторожностью).
Seed ≥128–256 бит, лог событий «seeded/reseeded» с причинами (например, старт/таймер/низкая энтропия).
Reseed по счетчику вызовов/таймеру/алерту энтропии; гарантировано не ухудшает поток (mix-in с крипто-перемешиванием).
Детекторы деградации: мониторинг p-value на скользящем окне, алерт при аномалиях.

seed  = KDF(TRNG()          OS_entropy()          boot_salt)
state = DRBG.instantiate(seed)
every T or N calls:
mix = KDF(OS_entropy()          health_check())
state = DRBG.reseed(state, mix)
output = DRBG.generate(state, k)
log(WORM, timestamp, reseed_reason, counters)

9) Управление версиями и выпуском игр

Каждая версия RNG/игры имеет идентификатор и хэш; CI/CD формирует SBOM и пакет доказательств (хэши, подписи).
Canary/Blue-Green релизы в проде запрещены для математических параметров; только «атомные» обновления после лабораторной валидации.
Любая смена RTP/модели → повторная сертификация и уведомление регулятора.
Хранение предыдущих версий и отчетов в WORM-хранилище ≥ требуемого срока.

10) Роль оператора vs студии/провайдера

Студия/провайдер: проектирует RNG/математику, проходит сертификацию, публикует сертификаты/отчеты.
Оператор: контролирует целостность интеграции, версионирование, аудит логов и согласованность RTP в каталоге игр, обеспечивает доступ регулятора к отчетам.

11) UX-прозрачность и доверие

На странице игры: RTP, дата сертификации/лаборатория, номер сертификата/хэша билда.
Раздел «Честная игра»: простые объяснения RNG, RTP, ссылки на публичные сертификаты (если политика допускает публикацию).
Уведомления при изменении RTP/версии (release notes внутрь каталога).

12) Метрики и комплаенс SLO

13) RACI (роли и ответственность)

14) Чек-листы

Перед отправкой в лабораторию

• Документация RNG: схема, источники энтропии, политики reseed.
• Математика игры: Design RTP/волатильность, таблицы выплат.
• Собранный билд с хэшами/подписями; SBOM.
• Прогоны внутренних батарей (NIST/Dieharder/TestU01) на контрольных выборках.
• WORM-журналы включены; артефакты архива созданы.

Перед релизом

• Получен сертификат (GLI/eCOGRA/иное), сверены версии и хэши.
• RTP/сертификат отображаются в каталоге игры (политика UX).
• Настроен мониторинг RTP-дрейфа и health-checks RNG.
• Зафиксирован план отката и заморозки спорных игр.

Ежегодно/по изменению

• Ресертификация или Addendum при изменениях.
• Ретест BigCrush/NIST на свежем железе/ОС.
• Аудит цепочки поставки (supply chain) и ключей подписи.

15) Инциденты и расследования (playbook)

Сигналы: жалоба игрока, аномальный RTP-дрейф, провалы health-checks, рассинхрон хэшей.

1. Freeze игры/пула, снимок логов/состояний RNG.

2. Внутренние тесты: 10^6–10^7 исходов, быстрые батареи NIST/Dieharder.

3. Проверка seed/reseed-журналов, энтропии, ТЕЕ/подписей.

4. Эскалация в лабораторию/регулятор; временная приостановка выплат по спорным раундам при необходимости.

5. Пост-морем: корневая причина, фиксы, ретесты, коммуникации, обновление политики.

16) Дорожная карта внедрения (6 шагов)

1. Политики и дизайн: выбрать DRBG/TRNG, описать seeding/reseed, определить Design RTP/волатильность.
2. Реализация и изоляция: RNG в TEE/контейнере, подписи вызовов, WORM-логи.
3. Внутренние тесты: NIST/Dieharder/TestU01 на больших выборках, регрессии.
4. Сертификация: подача в GLI/eCOGRA/iTech/BMM; сборка пакета доказательств.
5. Продакшн-мониторинг: RTP-дрейф, health-checks RNG, алерты, панель комплаенса.
6. Ресертификация и улучшения: ежегодный цикл, анализ инцидентов, апгрейд крипто-практик.

17) Частые ошибки и как их избежать

Нет политик seeding/reseed → документируйте и логируйте каждое событие.
Смешение prod/dev ключей → строгая сегрегация, ротация, запрет для dev на prod-артефакты.
Опора только на «теоретический RTP» → требуются симуляции и прод-мониторинг.
Отсутствие WORM → нечем доказать честность задним числом.
Скрытый RTP/сертификаты → снижает доверие и рискует лицензией.
Патч без ресертификации → нарушение условий, высокий регуляторный риск.

Итог

RNG-сертификация — это не разовая «бумага», а непрерывный процесс: строгая криптография и энтропия, богатые статистические тесты, доказуемая интеграция с игрой, неизменяемый аудит и прозрачный UX. Выстроив «Fair Play by Design», вы превратите честность в конкурентное преимущество и фундамент долгосрочной устойчивости продукта.