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))`

Платформа:

проверяет дельту времени `	now - t	≤ 300 с`, валидирует HMAC, отсеивает повтор по `event_id` (идемпотентность).

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/СENC для сегментов, JWT/HMAC для транзакций, и KMS/HSM с ротацией ключей и PFS. Когда каждый слой выполнен правильно и мониторится в реальном времени, казино получает устойчивый к атакам контур, а игрок — быстроту и честность live-формата без компромиссов по безопасности.