DRM در نرم‌افزارهای موبایل: مبانی، شمات حفاظت و اصل کار

DRM چیست؟

DRM — مجموعه‌ای از روش‌های رمزگرافی و نرم‌افزاری است که دسترسی به محتوای رقومی را کنترل می‌کنند. بر خلاف رمزگذاری ساده، DRM شامل یک سیستم مجازنامه است: محتوا رمزگذاری می‌شود و برای مشاهدهٔ آن کلیدی لازم است که فقط پس از بررسی حقوق کاربر صادر می‌شود.

وظیفه اصلی DRM جلوگیری از دزدی اینترنتی و ایجاد محدودیت‌های منطقه‌ای است. بدون DRM، صاحبان محتوا (استودیوهای فیلم، شرکت‌های صدایی) محتوای خود را به پلتفرم‌های پخش مجاز نمی‌کنند. به گزارش Motion Picture Association (2025)، استفاده از DRM پخش غیرقانونی فیلم‌ها را در پخش اینترنتی در مقایسه با دوره ریپ‌های DVD تا 62% کاهش داده است.

در توسعه نرم‌افزار موبایل، DRM در سطح پخش‌کننده رسانه جایگزین می‌شود: توسعه‌دهنده از ExoPlayer (Android)، AVPlayer (iOS) یا Shaka Player (Web) استفاده می‌کند که رمزگشایی داخلی جریان رمزگذاری‌شده را پشتیبانی می‌کنند. توسعه‌دهنده نیازی به پیاده‌سازی رمزگرافی ندارد — کافی است SDK را برای مجازنامه ادغام کند.

DRM و CENC (رمزگذاری مشترک)

استاندارد CENC (Common Encryption — ISO/IEC 23001-7) امکان استفاده از یک فایل رسانه‌ای رمزگذاری‌شده را برای تمامی سیستم‌های DRM فراهم می‌کند. محتوا یک بار رمزگذاری می‌شود و کلیدها از طریق سرورهای مجاز مختلف پخش می‌شوند. این برای سرویس‌های چندپلتفرمی حیاتی است: Netflix فیلم را یک بار رمزگذاری می‌کند و آن را بدون تبدیل کد به Android (Widevine)، iOS (FairPlay) و Windows (PlayReady) ارائه می‌دهد.

CENC از رمزگذاری CBC با کلیدهای مختلف برای جریان‌های صوتی و ویدئویی استفاده می‌کند. هر کلید در مانیفست MPD (MPEG-DASH) یا M3U8 (HLS) به صورت رمزگذاری‌شده ذخیره می‌شود. شناسه محتوا (KID) جریان رمزگذاری‌شده را به مجاز در سرور متصل می‌کند — بدون مجاز معتبر، کلید رمزگشایی نمی‌شود.

DRM در نرم‌افزارهای موبایل چگونه کار می‌کند

فرآیند پخش DRM از چهار مرحله تشکیل شده است: بارگیری مانیفست، دریافت مجاز، رمزگشایی محتوا و نمایش. هر مرحله توسط جزئ مختلفی از سیستم — پخش‌کننده رسانه، ماژول CDM و سرور مجاز انجام می‌شود.

• بارگیری مانیفست — پخش‌کننده MPD (DASH) یا M3U8 (HLS) را با فراداتایی درباره بخش‌های رمزگذاری‌شده، شمات رمزگذاری و URL سرور مجاز دریافت می‌کند.
• درخواست مجاز — پخش‌کننده شناسه محتوا (KID) را به Content Decryption Module (CDM) ارسال می‌کند که درخواستی را به سرور مجاز تشکیل می‌دهد.
• دریافت کلید — سرور حقوق کاربر (اشتراک، منطقه، دستگاه) را بررسی می‌کند و کلیدی را که با کلید عمومی دستگاه رمزگذاری شده است، بازمی‌گرداند.
• رمزگشایی جریان — CDM کلید را با کلید خصوصی دستگاه رمزگشایی می‌کند و آن را به پخش‌کننده برای رمزگشایی بلافاصله بخش‌های ویدئویی ارسال می‌کند.

Content Decryption Module (CDM)

CDM — یک ماژول نرم‌افزاری یا سخت‌افزاری محافظت‌شده است که رمزگشایی محتوا را انجام می‌دهد. در Android، CDM در سطح API MediaDrm پیاده‌سازی شده است، در iOS — در AVFoundation از طریق AVContentKeySession جایگزین شده است. CDM هرگز کلید را در معرض دید نرم‌افزار قرار نمی‌دهد — تمامی عملیات رمزگرافی در یک محیط ایمن (TEE — Trusted Execution Environment) انجام می‌شود.

در دستگاه‌های با پشتیبانی سخت‌افزاری (Secure Level 1)، CDM در داخل TEE کار می‌کند — کلید هرگز وارد حافظه اصلی دستگاه نمی‌شود. این یک ضرورت استودیوها برای پخش محتوا در 4K HDR است. در دستگاه‌های بدون TEE، کلیدها به صورت نرم‌افزاری رمزگشایی می‌شوند (L3)، که حفاظت را کاهش می‌دهد و حداکثر کیفیت را به 540p محدود می‌کند.

شمات اصلی DRM

در پلتفرم‌های موبایل، سه سیستم DRM دومینه دارند. هر یک برای اکوسیستم خود انحصاری است، اما CENC را پشتیبانی می‌کند که امکان استفاده از محتوای رمزگذاری‌شده واحد در تمامی پلتفرم‌ها را فراهم می‌کند.

انتخاب DRM برای سرویس چندپلتفرمی

برای یک سرویس پخش که در تمامی پلتفرم‌ها کار می‌کند، پشتیبانی از هر سه DRM ضروری است. راه‌حل عملی — استفاده از CDN با پشتیبانی multi-DRM (Muvi, Vualto, Axinom) که به طور خودکار درخواست‌های مجاز را به سرور مناسب بر اساس دستگاه کاربر هدایت می‌کنند. به گزارش Streaming Learning Center (2025)، 78% سرویس‌های پخش از رویکرد Multi-DRM استفاده می‌کنند.

استاندارد MPEG-DASH با CENC معماری را ساده می‌کند: محتوا یک بار با یک کلید مشترک رمزگذاری می‌شود و سیستم DRM در سمت مشتری انتخاب می‌شود. سرور مجاز درخواستی با شناسه دستگاه دریافت می‌کند و کلیدی را که برای CDM مشخص رمزگذاری شده است، بازمی‌گرداند. هیچ تفاوتی در محتوا برای پلتفرم‌های مختلف وجود ندارد — تنها سرور مجاز متفاوت است.

Widevine: سطوح و ویژگی‌ها

Widevine — سیستم DRM گوگل است که به عنوان استاندارد ده فاکتو در Android شناخته می‌شود. آن سه سطح امنیتی را پشتیبانی می‌کند که تعیین می‌کنند رمزگشایی محتوا کجا و چگونه انجام می‌شود. سطح امنیتی به قابلیت‌های سخت‌افزاری دستگاه بستگی دارد و حداکثر وضوح محتوا را تعیین می‌کند.

سطوح امنیتی Widevine

Widevine L1 (سخت‌افزاری) — بالاترین سطح حفاظت. تمامی عملیات رمزگرافی در داخل Trusted Execution Environment (TEE) انجام می‌شود. کلید هرگز ناحیه ایمن را ترک نمی‌کند. دستگاه‌های با L1 می‌توانند محتوای تا 4K HDR را پخش کنند. گواهینامه Google ضروری است — رویه‌ای که دستگاه‌های پرچمدار آن را طی می‌کنند.

Widevine L3 (نرم‌افزاری) — رمزگشایی در حافظه اصلی دستگاه انجام می‌شود. کلید ممکن است توسط یک مهاجم ماهر استخراج شود. وضوح برای محتوای پریمیوم به 540p (960x540) محدود است. همه دستگاه‌های Android حتی اگر برای L1 گواهی نشده‌اند، L3 را پشتیبانی می‌کنند.

Widevine L2 — سطح میانه نادری که رمزگشایی در TEE انجام می‌شود، اما رندرینگ در مسیر حفاظت‌نشده است. در بعضی Smart TVها استفاده می‌شود. در دستگاه‌های موبایل تقریباً وجود ندارد.

چگونه سطح Widevine را در دستگاه تعیین کنیم

import android.media.MediaDrm
import android.media.UUID

fun checkWidevineLevel(): String {
    val widevineUuid = UUID.fromString("edef8ba9-79d6-4ace-a3c8-27dcd51d21ed")
    val mediaDrm = MediaDrm(widevineUuid)

    val securityLevel = mediaDrm.getPropertyString(
        MediaDrm.PROPERTY_SECURITY_LEVEL
    )

    return when (securityLevel) {
        "L1" -> "Widevine L1 — حفاظت سخت‌افزاری"
        "L3" -> "Widevine L3 — حفاظت نرم‌افزاری"
        else -> "Widevine $securityLevel"
    }
}

روش از CDM ویژگی securityLevel را از طریق UUID Widevine درخواست می‌کند. مقدار بازگشتی — رشته L1، L2 یا L3 — سطح حفاظت فعلی دستگاه را نشان می‌دهد. این اطلاعات برای سرویس‌های پخش حیاتی است: اگر دستگاه تنها L3 داشته باشد، محتوای 4K قابل نمایش نیست.

Apple FairPlay: معماری و اصل کار

FairPlay — سیستم DRM اپل است که در تمامی پلتفرم‌های اکوسیستم جایگزین شده است: iOS، iPadOS، macOS، tvOS و watchOS. بر خلاف Widevine، FairPlay سطوح امنیتی ندارد — حفاظت توسط دستگاه تعیین می‌شود. در iOS با Secure Enclave، FairPlay سطح حفاظتی قابل مقایسه با Widevine L1 ارائه می‌دهد.

FairPlay تنها با پروتکل HLS (HTTP Live Streaming) کار می‌کند. محتوا در سگمنت‌های .ts (MPEG-TS) یا قطعات .m4s (fMP4) بسته‌بندی می‌شود. مانیفست M3U8 شامل برچسب #EXT-X-KEY با URI سرور مجاز (KSM — Key Server Module) و IV ابتدایی است. در شروع پخش، AVPlayer مانیفست را می‌خواند و از طریق AVContentKeySession کلید را درخواست می‌کند.

ادغام FairPlay Streaming

import AVFoundation

let contentKeySession = AVContentKeySession(keySystem: fairPlayStreaming)
let player = AVPlayer(playerItem: playerItem)
contentKeySession.setDelegate(self, queue: delegateQueue)

func contentKeySession(
    _ session: AVContentKeySession,
    didProvide keyRequest: AVContentKeyRequest
) {
    let assetId = keyRequest.identifier as! String
    sendLicenseRequest(assetId) { licenseData in
        keyRequest.processContentKeyResponse(
            AVContentKeyResponse(fairPlayStreamingKeyResponseData: licenseData)
        )
    }
}

دلگات AVContentKeySession درخواست کلید را با شناسه محتوا (assetId) دریافت می‌کند. نرم‌افزار این ID را به سرور مجاز خود (KSM) ارسال می‌کند که کلید رمزگذاری‌شده را بازمی‌گرداند. فراخوانی processContentKeyResponse کلید را برای رمزگشایی به CDM منتقل می‌کند. اگر مجاز نامعتبر باشد (منقضی شده، پرداخت نشده)، سرور خطای 403 را بازمی‌گرداند و AVPlayer پخش را آغاز نمی‌کند.

Persistent Key Loading برای محتوای آفلاین

FairPlay از persistent keys — ذخیره مجاز در دستگاه برای مشاهده آفلاین پشتیبانی می‌کند. پس از دریافت کلید، نرم‌افزار processContentKeyResponse را با علم allowsPersistableKey فراخوان می‌کند. کلید در Keychain ذخیره می‌شود و در مشاهده مجدد بدون مراجعه به سرور قابل استفاده است. اما مدت اعتبار مجاز آفلاین محدود است — معمولاً 7–30 روز، پس از آن تجدید نظر لازم است.

مجازهای آفلاین در انبار ایمن iOS — Keychain ذخیره می‌شوند. در صورت تلاش برای نفوذ (jalibreak، استخراج دامپ)، Secure Enclave کلیدها را نابود می‌کند. به گزارش Apple (2025)، فناوری persistent keys در Apple TV+، Netflix و Disney+ برای دانلود محتوا در iPad قبل از سفر استفاده می‌شود.

Microsoft PlayReady برای حفاظت جهانی

PlayReady — DRM از Microsoft است که در Windows، Xbox و Windows Phone منسوخ استفاده می‌شود. هرچند در دستگاه‌های موبایل PlayReady کمتر از Widevine و FairPlay رایج است، اما برای راه‌حل‌های جهانی پخش که در تمامی پلتفرم‌های Microsoft کار می‌کنند، مهم است. PlayReady هم حفاظت نرم‌افزاری و هم سخت‌افزاری را از طریق TPM پشتیبانی می‌کند.

PlayReady از معماری SL (Security Level) استفاده می‌کند: SL2000 (نرم‌افزاری، مشابه Widevine L3)، SL3000 (سخت‌افزاری، مشابه L1). در Xbox Series X، PlayReady SL3000 از طریق TEE+TPM کار می‌کند — کلیدها تنها در محیط ایمن استخراج می‌شوند. این امکان پخش 4K Blu-ray را در کنسول بدون خطر کپی فراهم می‌کند.

به گزارش Microsoft Docs (2026)، PlayReady از CENC پشتیبانی می‌کند و می‌تواند از طریق Media Source Extensions (MSE) در مرورگرهای Edge با MPEG-DASH کار کند. برای نرم‌افزارهای موبایل در Android و iOS، PlayReady از طریق SDK موجود است، اما به ندرت استفاده می‌شود — اساساً برای نرم‌افزارهای شرکتی و سرویس‌های رسانه‌ای Microsoft.

PlayReady Native SDK برای Android

Microsoft PlayReady Native SDK را برای Android و iOS ارائه می‌دهد. ادغام از طریق ExoPlayer با افزونه PlayReady انجام می‌شود: توسعه‌دهنده PlayReadyRenderer را اضافه می‌کند که در زنجیره کدگشایی جایگزین می‌شود. ExoPlayer به طور خودکار بسته به اینکه کدام DRM در مانیفست MPD مشخص شده است، بین Widevine و PlayReady تغییر می‌کند.

هرچند PlayReady در نرم‌افزارهای موبایل به ندرت یافت می‌شود، پشتیبانی از آن برای سرویس‌هایی که در اکوسیستم Microsoft قرار دارند — مثل پلتفرم‌های آموزشی شرکتی در SharePoint و Stream — اجباری است. به گزارش Microsoft (2025)، PlayReady در 23% راه‌حل‌های رسانه‌ای شرکتی در مقابل 62% Widevine استفاده می‌شود.

ادغام DRM در نرم‌افزار موبایل

ادغام DRM در نرم‌افزار موبایل نیازی به نوشتن کد رمزگرافی ندارد — توسعه‌دهنده با پخش‌کننده‌ای کار می‌کند که DRM را از قبل پشتیبانی می‌کند. بیایید ادغام را در Android از طریق ExoPlayer با افزونه DRM بررسی کنیم.

راه‌اندازی ExoPlayer با پشتیبانی Widevine

val drmSessionManager = DefaultDrmSessionManager.Builder()
    .setUuidAndExoMediaDrmProvider(
        C.WIDEVINE_UUID,
        FrameworkMediaDrm.DEFAULT_PROVIDER
    )
    .setMultiSession(true)
    .build(mediaDrmCallback)

val mediaItem = MediaItem.Builder()
    .setUri(mpdUrl)
    .setDrmConfiguration(
        MediaItem.DrmConfiguration.Builder(C.WIDEVINE_UUID)
            .setLicenseUri(licenseUrl)
            .setLicenseRequestHeaders(headers)
            .build()
    )
    .build()

exoPlayer.setMediaItem(mediaItem)
exoPlayer.prepare()

DefaultDrmSessionManager جلسه DRM را مدیریت می‌کند: جلسه MediaDrm ایجاد می‌کند، درخواست‌های مجاز را پردازش می‌کند و کلیدها را به دکودر منتقل می‌کند. پارامتر setMultiSession(true) امکان رمزگشایی همزمان چند جریان (صوت + ویدئو) را در جلسات مختلف فراهم می‌کند. MediaDrmCallback درخواست HTTP را به سرور مجاز ایجاد می‌کند — معمولاً POST با بدنه درخواست در فرمت SignedRequest.

MediaDrmCallback برای درخواست مجاز

val mediaDrmCallback = DefaultDrmSessionManager.MediaDrmCallback {
    url, requestBody ->

    val response = OkHttpClient().newCall(
        Request.Builder()
            .url(url)
            .post(RequestBody.create(requestBody, MediaType.parse("application/octet-stream")))
            .addHeader("Authorization", "Bearer ")
            .build()
    ).execute()

    val responseBytes = response.body?.bytes()
        ?: throw DrmSessionException(Exception("Empty license response"))

    responseBytes
}

Callback یک درخواست POST را با UUID Widevine در بدنه به سرور مجاز ارسال می‌کند. سرور احراز هویت کاربر (توکن در هدر) را بررسی می‌کند و کلید رمزگذاری‌شده را بازمی‌گرداند. اگر کاربر اشتراک فعالی نداشته باشد، سرور 403 Forbidden را بازمی‌گرداند — ExoPlayer یک خطای DRM تولید می‌کند که باید از طریق onPlayerError مدیریت شود.

مدیریت خطاهای DRM

خطاهای DRM زمانی رخ می‌دهند که مجاز نامعتبر باشد، منقضی شده باشد یا دستگاه از سطح حفاظت مورد نیاز پشتیبانی نکند. ExoPlayer خطا را از طریق Player.Listener.onPlayerError با کد TYPE_DRM_LICENSE_EXPIRED، TYPE_DRM_UNSUPPORTED یا TYPE_SOURCE منتقل می‌کند. توصیه می‌شود پیامی آگاه‌کننده به کاربر نشان داده شود: «محتوا برای این دستگاه در دسترس نیست» یا «برای مشاهده اشتراک را تمدید کنید».

بر اساس تحلیل سرویس‌های پخش (2025)، تا 8% شروع‌های ناموفق پخش مربوط به خطاهای DRM است. از آنها، 60% مجازهای منقضی شده، 25% ناسازگاری دستگاه و 15% خطاهای شبکه در درخواست کلید هستند. تلاش مجدد خودکار پس از 5 ثانیه 40% موارد خطاهای شبکه را حل می‌کند.