9장. 콘텐츠 보호 — 암호화와 DRM

9.1 왜 스트리밍은 암호화가 필요한가

HLS는 HTTP 기반이다.

이건 큰 장점이지만, 보안 측면에서는 약점이기도 하다.

• segment 파일은 일반 HTTP 응답
• URL만 알면 누구나 다운로드 가능
• 다운로드 후 영상 추출이 너무 쉽다

OTT 서비스, 유료 콘텐츠, 라이선스가 있는 영상은 이 상태로 두면 안 된다.

누구나 받을 수 있지만, 받은 사람이 재생할 수는 없게 만들자.

이게 스트리밍 암호화의 목적이다.

두 가지 레이어

HLS의 보호는 크게 두 가지 레이어로 나뉜다.

암호화는 자물쇠, DRM은 그 자물쇠의 키 관리 체계라고 보면 된다.

9.2 EXT-X-KEY 태그 분석

HLS는 m3u8 안에 암호화 방식과 키 위치를 명시한다.

#EXT-X-KEY:METHOD=AES-128,
  URI="https://example.com/keys/key1.bin",
  IV=0x9c7d8f8e1b6a4c5d2e8f9a0b1c3d4e5f

주요 속성:

METHOD 값들

SAMPLE-AES는 fMP4 + CMAF 환경에서 SAMPLE-AES-CTR로 발전한다.

키 교체

EXT-X-KEY는 m3u8 중간에 다시 등장할 수 있다.

#EXT-X-KEY:METHOD=AES-128,URI="key1.bin"
seg100.ts
seg101.ts
seg102.ts

#EXT-X-KEY:METHOD=AES-128,URI="key2.bin"
seg103.ts
seg104.ts

이렇게 하면 주기적으로 키를 바꾸는 rotation이 가능하다. 하나의 키가 노출돼도 피해를 제한할 수 있다.

9.3 AES-128 (segment 단위 암호화)

가장 단순한 방식.

각 segment 파일 전체를 AES-128로 암호화한다.

seg100.ts (평문)
   ↓ AES-128 + IV
seg100.ts (암호문, 같은 이름)

플레이어 동작:

1. m3u8 다운로드
2. EXT-X-KEY에서 키 URI 확인
3. 키 다운로드 (HTTPS)
4. segment 다운로드
5. 키 + IV로 복호화
6. 디코딩 → 재생

장점

• 구현이 매우 단순
• 모든 HLS 플레이어가 지원
• CDN 캐싱 가능 (암호문 그대로 캐싱)

단점

• 키만 얻으면 전체 영상 복호화 가능
• 키 배포 자체의 보안이 약함 (URI 노출 시 누구나 다운로드)
• 실제 상용 서비스에는 불충분

AES-128은 개인 콘텐츠나 가벼운 보호 용도다.

상용 OTT는 DRM 기반을 쓴다.

9.4 SAMPLE-AES (샘플 단위 암호화)

좀 더 정교한 방식.

모든 데이터를 암호화하는 것이 아니라, 미디어 샘플(프레임)만 부분 암호화한다.

암호화 대상:

• 비디오 프레임의 일부 영역
• 오디오 샘플

암호화하지 않는 부분:

• 컨테이너 헤더
• 메타데이터
• 일부 NAL 유닛

왜 부분만 암호화하는가

① 하드웨어 디코더와의 호환성

전체를 암호화하면 하드웨어 디코더가 데이터를 식별할 수 없다.

샘플 단위 암호화는 컨테이너는 평문으로 두고 실제 미디어 비트만 잠그는 방식.

② 성능

전체 암호화는 CPU 부담이 크다. 일부만 암호화하면 보호 효과는 비슷하면서 처리 비용 감소.

CMAF에서의 발전: cbcs

7장에서 본 Common Encryption (CENC)를 다시 떠올려보자.

CMAF + LL-HLS 환경에서는 주로 cbcs 모드를 사용한다.

cbcs = AES-CBC + sample 단위 + 패턴 암호화

특징:

• sample 단위 (SAMPLE-AES 계열)
• 패턴 적용 가능 (예: 10블록 중 1블록만 암호화)
• 하드웨어 디코더 친화적

이게 현재 HLS + DRM의 표준이다.

9.5 DRM 시스템

DRM(Digital Rights Management)은 키를 안전하게 배포하고 재생 환경을 통제하는 시스템이다.

AES-128에서 키 URI 노출이 문제였다면, DRM은 그 키를 보호된 채널로 전달한다.

1. 플레이어가 콘텐츠를 요청
2. 라이선스 서버에 인증 요청
3. 라이선스 서버: 권한 확인
4. 디바이스의 CDM(Content Decryption Module)에
   암호화된 키를 전달
5. CDM이 OS/HW 보호 영역에서 복호화

키가 JavaScript나 메모리에 노출되지 않는다.

주요 DRM 세 가지

상용 서비스는 보통 세 가지를 모두 지원한다. 플랫폼별로 다른 DRM이 강제되기 때문이다.

FairPlay

Apple 생태계의 DRM.

• iOS, tvOS, macOS Safari에서 사용
• HLS와 결합 (fairplay keyformat)
• cbcs 암호화 모드만 지원

#EXT-X-KEY:METHOD=SAMPLE-AES,
  URI="skd://license-server.com/getkey?asset=xyz",
  KEYFORMAT="com.apple.streamingkeydelivery",
  KEYFORMATVERSIONS="1"

skd://는 FairPlay 전용 스킴이다.

Widevine

Google이 만든 DRM.

• 세 가지 보안 레벨 (L1, L2, L3)
  • L1: 하드웨어 보호 (4K 가능)
  • L2: 하드웨어 + 일부 SW
  • L3: 소프트웨어만 (저화질 한정)
• Chrome, Firefox, Android
• cenc 또는 cbcs 지원

EME (Encrypted Media Extensions) API로 호출된다.

PlayReady

Microsoft의 DRM.

• Edge, Windows, Xbox
• 일부 스마트 TV
• cenc 또는 cbcs 지원

기업/방송 환경에서 많이 쓰인다.

멀티 DRM 구조

상용 서비스의 일반적 흐름:

원본 영상
  ↓
CMAF + cbcs 암호화 (한 벌)
  ↓
Manifest (HLS / DASH)
  ↓
플레이어 환경 감지
  ├─ Safari/iOS  → FairPlay 라이선스
  ├─ Chrome/Android → Widevine 라이선스
  └─ Edge/Windows → PlayReady 라이선스

영상 파일은 한 벌이고, 라이선스만 DRM별로 발급된다.

이게 가능한 이유는

세 DRM 모두 cbcs 모드를 지원하기 때문이다.

이 표준화가 없었다면 DRM마다 영상을 다시 인코딩해야 했다.

9.6 CENC로 가는 흐름

지금까지의 흐름을 정리하면 이렇다.

[HLS v1]
  AES-128 segment 암호화
  ↓
[HLS v4]
  SAMPLE-AES 도입
  하드웨어 친화적
  ↓
[CMAF + CENC]
  cbcs 표준화
  HLS + DASH 호환
  ↓
[멀티 DRM]
  한 파일 / 세 라이선스

스트리밍 보호는 암호화 형식 → 표준화 → DRM 통합의 순서로 진화했다.

이 흐름의 끝에서

• 인프라는 공유
• 보호는 각 플랫폼 DRM

이라는 형태가 자리잡았다.

실무에서 자주 보는 조합

9장 한 줄 정리

스트리밍 보호는 “파일을 잠그는 일“이 아니라 “키를 누구에게, 어떻게 줄 것인가“의 문제다.