Крипто-казино
Torrent Gear
Як працює шифрування даних в live-іграх
1) Картина рівнів шифрування
У live-казино шифрування працює на чотирьох шарах одночасно:1. Канали: клієнт ↔ медіасервер (WebRTC/DTLS-SRTP), клієнт ↔ CDN (TLS), платформа ↔ провайдер (TLS 1. 3/mTLS).
2. Контент: захист відеосегментів і маніфестів (AES-128/SAMPLE-AES, CENC c FairPlay/Widevine/PlayReady).
3. Транзакції: підпис і шифрування API (JWT/JWS, HMAC-підписи webhook'ів, антиріпів).
4. Зберігання: ключова інфраструктура (KMS/HSM), шифрування «на спокої» (TDE/field-level), токенізація PII.
2) Транспортні канали: TLS 1. 3, mTLS и QUIC
Клієнтські HTTP (S) -запити (лобі, гаманець, HLS/DASH маніфести/сегменти) йдуть по TLS 1. 3 з AEAD-шифрами (AES-GCM або ChaCha20-Poly1305) і PFS (ECDHE).
S2S-інтеграції (платформа ↔ провайдер/агрегатор) захищаються mTLS (взаємна автентифікація за сертифікатами), плюс IP-allowlist і certificate pinning на критичних клієнтах.
HTTP/3 (QUIC) знижує джиттер/латентність доставки маніфестів і сегментів; контроль версій TLS і «обрізка» старих шифросьютів обов'язкові.
Мінімальний набір практик: TLS 1. 3 preferred, TLS 1. 2 тільки для легасі; OCSP-stapling, короткий термін життя сертифікатів, автоматична ротація.
3) WebRTC и DTLS-SRTP: шифрування «живого» відео/аудіо
DTLS-SRTP (або SRTP через DTLS-ключовий обмін) шифрує RTP-медіа. Ключі виводяться з рукостискання DTLS, окремо для кожного потоку (per-SSRC).
Шифри SRTP: AES-CM-128 + HMAC-SHA1 (класика) або SRTP-AES-GCM (автентифіковане шифрування з меншими накладними).
PFS досягається за рахунок ефемерних ключів DTLS (ECDHE). Компрометація довгоживучого ключа не розкриває старі сесії.
E2EE поверх WebRTC (наприклад, SFrame) можлива для приватних кімнат: кадр шифрується на клієнті загальним груповим ключем, SFU бачить тільки «шифр-текст». Ціна: ускладнення кейменеджменту і неможливість серверних накладень/врізок.
4) LL-HLS/DASH и DRM: захист сегментів і маніфестів
Для кешованих трансляцій (LL-HLS/DASH) застосовуються:- AES-128 (CBC) або SAMPLE-AES на рівні сегментів, ключі видає Key Server.
- CENC (Common Encryption) з режимами cbcs/ctr і DRM (FairPlay/Widevine/PlayReady) через ліцензійні сервери.
- Ротація ключів: '#EXT -X-KEY '/KID змінюється кожні N хвилин/сегментів; IV унікальний на сегмент.
- Доступ до ключів захищений tokenized URL (короткий TTL, зв'язка з IP/Device ID/Audience).
- Для LL-режиму важливо: короткий partial segment, prefetch ліцензій, мінімізація «ручних» редиректів (кожен хоп = ризик витоку/затримки).
5) Транзакції та події: підпис, антиріпот, ідемпотентність
5. 1. JWT/JWS для клієнтських і серверних викликів
Ігрові токени і session-JWT підписуються JWS (ES256/RS256), з клеймами:- `iss, aud, sub, iat, nbf, exp (≤ 15 мин), jti, kid`.
- aud жорстко фіксований (кому призначений токен),'nbf/exp'- короткі вікна,'jti'- анти-реплей.
5. 2. Підпис webhook'ів провайдера (HMAC)
Провайдер шле події раундів/виплат на платформу з заголовком, наприклад:- `X-Signature: t=169...; v1=hex(hmac_sha256(secret, t + "." + body))`
5. 3. Грошові операції
'debit/credit/rollback'- ідемпотентні по'transaction _ id', підписані і прив'язані до'round _ id'.
Всі відповіді містять підпис сервера і контрольну суму (наприклад, SHA-256 за нормалізованим JSON).
6) PII і гаманець: шифрування на спокої і мінімізація даних
Токенізація'player _ id'і відділення фінансових ідентифікаторів від PII.
Field-level encryption для чутливих полів (ПІБ, телефон, e-mail): AES-GCM з envelope encryption (data-key шифрується master-key з KMS/HSM).
TDE/disk-encryption на рівні БД і снапшотів; резервні копії теж шифруються.
Політики зберігання: мінімальні терміни, авто-анонімізація, окремі ключі по регіонах (дотримання локальних правил).
Логи і реплеї раундів - в WORM-сховищі (без можливості зміни), ключі доступу тільки в обмеженої ролі.
7) Управління ключами: KMS/HSM, ротація і доступ
KMS/HSM зберігає майстер-ключі; прикладні сервіси отримують data-keys з обмеженим TTL.
Ротація:- TLS-сертифікати - автоматично, 30-90 днів.
- Ключі DRM/контент-ключі - на потік/тимчасове вікно.
- Секрети API - кожні 60-90 днів, негайна інвалідація при інцидентах.
- Політики доступу: принцип найменших привілеїв, прив'язка до сервісних акаунтів/ролей, аудит запитів до KMS.
8) Анти-погрози: що шифрування закриває і чого не закриє
Закриває:- Перехоплення (MITM) і підміна даних на каналі.
- Реплей подій і токенів (при правильному'exp/jti/timestamp').
- Крадіжку сегментів/ключів з CDN без токенів/DRM.
- Компрометацію клієнтського пристрою (malware, розширення).
- Рестрім екрану/камерою - вирішується водяними знаками, поведінковими правилами і юридичними заходами.
- Інсайдерські ризики - мінімізуються сегрегацією доступів, аудитом KMS і WORM-логуванням.
9) Практичні приклади
9. 1. Політика TLS
Дозволено: TLS 1. 3 (TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256).
Допустимо для легасі: TLS 1. 2 c ECDHE + AES-GCM/CHACHA20 (без CBC, без RSA-кей-ексчейнджа).
Заборонено: SSL/TLS ≤ 1. 1, RC4, 3DES, AES-CBC, компресія TLS.
9. 2. Міні-специфікація підпису подій
http
POST /game/events
X-Signature: t=173...; v1=15c2...af
Content-Type: application/json
{
"event_id":"ev-7f3", "type":"round. result", "round_id":"r-2025-10-18-12:30:15Z-001", "payload":{"roulette":{"number":17,"color":"black"}}, "seq":12070
}Сервер: перевіряє вікно часу, HMAC, seq, ідемпотентність по'event _ id'.
9. 3. DRM-ключовий сервер
`POST /drm/license` с device-nonce, `kid`, `session_id`, токеном с `aud=drm`.
Повертає зашифрований контент-ключ, пов'язаний з пристроєм і сесією.
10) Спостережуваність крипти та інциденти
Алерти: сплеск помилок TLS-рукостискань, зростання'invalid _ signature','replay _ detected', запитів до KMS, частка невалідних JWT, осідання OCSP.
Дешборди: версія TLS по трафіку, cipher-suite дистрибуція, частка TURN-relay (WebRTC), latency видачі DRM-ліцензій, час ротації сертифікатів.
Runbook: швидкий відгук сертифіката, перевипуск client-cert для mTLS, аварійна заміна HMAC-секретів, інвалідація всіх короткоживучих токенів ('exp ≤ 5 хв'), переведення на резервний DRM-ендпоінт.
11) Сумісність і продуктивність
Баланс «безпека ↔ затримка»: AEAD-шифри з апаратним прискоренням (AES-NI/ARMv8 Crypto), короткі рукостискання TLS 1. 3, кеш сесій/0-RTT (обережно з повторними запитами!).
Мобільні мережі: кращий ChaCha20-Poly1305 на пристроях без AES-NI.
WebRTC: вибір SRTP-AES-GCM знижує накладні перевірки в порівнянні з AES-CM + HMAC.
12) Чек-листи продакшену
Канали
- TLS 1. 3 скрізь, TLS 1. 2 тільки для легасі; OCSP-stapling, HSTS.
- mTLS для S2S; IP-allowlist; pinning в критичних клієнтах.
- QUIC/HTTP3 включений для маніфестів/сегментів.
Контент
- LL-HLS/DASH з ключовою ротацією; DRM для преміум-контенту.
- Tokenized URLs (TTL ≤ 2-5 хв), прив'язка до aud/IP/Device.
- Сек'юрний key-server з rate-limit і аудитом.
Транзакції
- JWT c'aud/exp/nbf/jti', JWK з'kid'і ротацією.
- Підпис webhook'ів (HMAC), вікно анти-реплей ≤ 5 хв.
- Ідемпотентність'debit/credit/rollback'.
Зберігання
- KMS/HSM, envelope-encryption, роздільні ключі по регіонах.
- Field-level encryption для PII, TDE для БД/бекапів.
- WORM-журнали і суворі ролі доступу.
Операції
- Алерти по TLS/DRM/JWT/KMS; дешборди cipher-suite/версії.
- Процедури екстреної ротації ключів/секретів.
- Пентести і крипто-review перед релізом.
Шифрування в live-іграх - це не одна «галочка» TLS, а узгоджена система: DTLS-SRTP/WebRTC для живого відео, TLS 1. 3/mTLS для API і доставки, DRM/CENC для сегментів, JWT/HMAC для транзакцій, і KMS/HSM з ротацією ключів і PFS. Коли кожен шар виконаний правильно і моніториться в реальному часі, казино отримує стійкий до атак контур, а гравець - швидкість і чесність live-формату без компромісів з безпеки.