Torrent Gear

How data encryption works in live games

1) Picture of encryption levels

In live casinos, encryption works on four layers at the same time:

1. Channels: client ↔ media server (WebRTC/DTLS-SRTP), client ↔ CDN (TLS), platform ↔ provider (TLS 1. 3/mTLS).

2. Content: protection of video segments and manifests (AES-128/SAMPLE-AES, CENC with FairPlay/Widevine/PlayReady).

3. Transactions: API signature and encryption (JWT/JWS, HMAC signatures of webhooks, anti-replicas).

4. Storage: key infrastructure (KMS/HSM), encryption "at rest" (TDE/field-level), PII tokenization.

2) Transport channels: TLS 1. 3, mTLS и QUIC

Client HTTP (S) requests (lobi, wallet, HLS/DASH manifests/segments) go through TLS 1. 3 with AEAD ciphers (AES-GCM or ChaCha20-Poly1305) and PFS (ECDHE).

S2S integrations (platform ↔ provider/aggregator) are protected by mTLS (mutual authentication by certificates), plus IP-allowlist and certificate pinning on critical clients.

HTTP/3 (QUIC) reduces the jitter/latency of manifest and segment delivery; TLS version control and "cropping" of old cipher computers are required.

Minimum set of practices: TLS 1. 3 preferred, TLS 1. 2 for legasi only; OCSP-stapling, short certificate lifespan, automatic rotation.

3) WebRTC and DTLS-SRTP: live video/audio encryption

DTLS-SRTP (or SRTP via DTLS key exchange) encrypts RTP media. The keys are derived from the DTLS handshake, per-SSRC.

SRTP ciphers: AES-CM-128 + HMAC-SHA1 (classic) or SRTP-AES-GCM (authenticated encryption with less overhead).

PFS is achieved through DTLS ephemeral keys (ECDHE). Compromising a long-lived key does not reveal old sessions.

E2EE over WebRTC (for example, SFrame) is possible for private rooms: the frame is encrypted on the client with a common group key, SFU sees only the "cipher text." Price: complication of keymanagement and the impossibility of server overlays/tie-ins.

4) LL-HLS/DASH and DRM: segment and manifest protection

For cached translations (LL-HLS/DASH), the following applies:

AES-128 (CBC) or SAMPLE-AES at the segment level, keys are issued by the Key Server.
CENC (Common Encryption) with cbcs/ctr and DRM (FairPlay/Widevine/PlayReady) modes through licensed servers.
Key rotation: '# EXT-X-KEY '/KID changes every N minutes/segments; IV is unique per segment.
Key access is protected by tokenized URL (short TTL, bundle with IP/Device ID/Audience).
For LL mode, it is important: a short partial segment, prefetch licenses, minimizing "manual" redirects (each hop = risk of leakage/delay).

5) Transactions and events: signature, anti-replay, idempotence

5. 1. JWT/JWS for client and server calls

Game tokens and session-JWT are signed by JWS (ES256/RS256), with stamps:

`iss, aud, sub, iat, nbf, exp (≤ 15 мин), jti, kid`.
aud is rigidly fixed (to whom the token is intended), 'nbf/exp' - short windows, 'jti' - anti-replay.

5. 2. Provider webhook signature (HMAC)

The provider sends round/payout events to the platform with a header, for example:

`X-Signature: t=169...; v1=hex(hmac_sha256(secret, t + "." + body))`

Platform:

checks time delta'	now - t	≤ 300 s', validates HMAC, eliminates repetition by'event _ id' (idempotency).

5. 3. Cash transactions

'debit/credit/rollback '- idempotent on' transaction _ id ', signed and bound to' round _ id '.

All responses contain the server signature and checksum (for example, normalized JSON SHA-256).

6) PII and wallet: encryption at rest and data minimization

Tokenization of 'player _ id' and separation of financial identifiers from PII.

Field-level encryption for sensitive fields (full name, phone, e-mail): AES-GCM with envelope encryption (data-key is encrypted by master-key from KMS/HSM).

TDE/disk-encryption at the database and snapshot level; backups are also encrypted.

Storage policies: minimum terms, auto-anonymization, individual keys by region (compliance with local rules).

Logs and replays of rounds - in WORM storage (without the possibility of changing), access keys only for a limited role.

7) Key management: KMS/HSM, rotation and access

KMS/HSM stores master keys; application services receive data-keys with limited TTL.

Rotation:

TLS certificates - automatically, 30-90 days.
DRM keys/content keys - per stream/time window.
API secrets - every 60-90 days, immediate disability in incidents.
Access policies: principle of least privileges, binding to service accounts/roles, auditing requests to KMS.

8) Anti-threats: what encryption closes and what it won't close

Closes:

Intercept (MITM) and channel spoofing.
Replay events and tokens (with the correct 'exp/jti/timestamp').
Theft of segments/keys with CDN without tokens/DRM.

Does not completely close:

Compromise of the client device (malware, extensions).
Screen restart/camera - solved by watermarks, behavioral rules and legal measures.
Insider risks - minimized by access segregation, KMS audit and WORM logging.

9) Practical examples

9. 1. TLS policy

Allowed: TLS 1. 3 (TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256).

Legal: TLS 1. 2 with ECDHE + AES-GCM/CHACHA20 (without CBC, without RSA-key-excess).

SSL/TLS ≤ 1 is not allowed. 1, RC4, 3DES, AES-CBC, TLS compression.

9. 2. Mini Event Signature Specification

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
}

Server: checks the time window, HMAC, seq, idempotency by 'event _ id'.

9. 3. DRM Key Server

`POST /drm/license` с device-nonce, `kid`, `session_id`, токеном с `aud=drm`.

Returns the encrypted content key associated with the device and session.

10) Crypt observability and incidents

Alerts: surge in TLS handshake errors, growth of 'invalid _ signature', 'replay _ detected', requests to KMS, share of invalid JWTs, OCSP drawdowns.

Dashboards: traffic TLS version, cipher-suite distribution, TURN-relay (WebRTC) share, latency for issuing DRM licenses, certificate rotation time.

Runbook: quick certificate revocation, reissue of client-cert for mTLS, emergency replacement of HMAC secrets, disability of all short-lived tokens ('exp ≤ 5 min'), transfer to a backup DRM endpoint.

11) Compatibility and performance

Security ↔ latency balance: AEAD ciphers with hardware acceleration (AES-NI/ARMv8 Crypto), short handshakes TLS 1. 3, session cache/0-RTT (careful with repeated requests!).

Mobile networks: preferred ChaCha20-Poly1305 on devices without AES-NI.

WebRTC: Choosing SRTP-AES-GCM reduces overhead checks compared to AES-CM + HMAC.

12) Production checklists

Channels

TLS 1. 3 everywhere, TLS 1. 2 for legasi only; OCSP-stapling, HSTS.
mTLS for S2S; IP-allowlist; pinning in critical clients.
QUIC/HTTP3 enabled for manifests/segments.

Content

LL-HLS/DASH with key rotation; DRM for premium content.
Tokenized URLs (TTL ≤ 2-5 min), binding to aud/IP/Device.
Secret key-server with rate-limit and audit.

Transactions

JWT c'aud/exp/nbf/jti ', JWK with' kid'and rotation.
Webhook signature (HMAC), anti-replay window ≤ 5 min.
IDempotency 'debit/credit/rollback'.

Storage

KMS/HSM, envelope-encryption, separate keys by region.
Field-level encryption for PII, TDE for DB/backups.
WORM logs and strong access roles.

Operations

Alerts by TLS/DRM/JWT/KMS; dashboards cipher-suite/version.
Emergency key/secret rotation procedures.
Pentests and crypto-review before release.

Encryption in live games is not one TLS checkmark, but a consistent system: DTLS-SRTP/WebRTC for live video, TLS 1. 3/mTLS for API and delivery, DRM/CENC for segments, JWT/HMAC for transactions, and KMS/HSM with key rotation and PFS. When each layer is done correctly and monitored in real time, the casino gets an attack-resistant outline, and the player gets the speed and honesty of the live format without security compromises.