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 в ТЕЄ/контейнері; доступ до стану закритий; виклики підписуються.
Immutable/WORM-журнали результатів, підписи таймстемпів, контроль цілісності (Merkle-ланцюги).

Прозорість

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

Інтеграція

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 в ТЕЄ/контейнері, підписи викликів, 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», ви перетворите чесність в конкурентну перевагу і фундамент довгострокової стійкості продукту.