DRM sa Mga Mobile App: Mga Batayan, Scheme ng Proteksyon, at Prinsipyo ng Paggana

Ano ang DRM?

DRM — ay isang koleksyon ng mga cryptographic at software na pamamaraan na kumokontrol sa pag-access sa digital na nilalaman. Hindi tulad ng simpleng pag-encrypt, ang DRM ay may kasamang sistema ng paglilisensya: ang nilalaman ay naka-encrypt, at para matingnan ito ay kinakailangan ang isang susi na ibinibigay lamang pagkatapos ng pagsusuri ng mga karapatan ng gumagamit.

Ang pangunahing gawain ng DRM ay pigilan ang pandarambong at tiyakin ang pagsunod sa mga paghihigpit sa rehiyon. Kung walang DRM, ang mga may-ari ng nilalaman (mga studio ng pelikula, record label) ay hindi naglilisensya ng kanilang nilalaman sa mga streaming platform. Ayon sa Motion Picture Association (2025), ang paggamit ng DRM ay nagbawas ng iligal na pamamahagi ng mga pelikula sa streaming ng 62% kumpara sa panahon ng DVD rip.

Sa pag-develop ng mobile, ang DRM ay naka-embed sa antas ng media player: ginagamit ng developer ang ExoPlayer (Android), AVPlayer (iOS), o Shaka Player (Web), na sumusuporta sa built-in na decryption ng naka-encrypt na stream. Hindi kailangang magpatupad ng cryptography ang developer — sapat na upang isama ang SDK para sa paglilisensya.

DRM at CENC (Common Encryption)

Ang pamantayang CENC (Common Encryption — ISO/IEC 23001-7) ay nagpapahintulot sa paggamit ng isang naka-encrypt na media file para sa lahat ng DRM system. Ang nilalaman ay naka-encrypt nang isang beses, at ang mga susi ay ipinamamahagi sa pamamagitan ng iba't ibang server ng lisensya. Ito ay kritikal para sa mga multi-platform na serbisyo: Ni-encrypt ng Netflix ang pelikula nang isang beses at inihahatid ito sa Android (Widevine), iOS (FairPlay), at Windows (PlayReady) nang walang recoding.

Gumagamit ang CENC ng CBC encryption na may iba't ibang susi para sa mga audio at video track. Ang bawat susi ay nakaimbak sa naka-encrypt na anyo sa manifest na MPD (MPEG-DASH) o M3U8 (HLS). Ang identifier ng nilalaman (KID) ay nag-uugnay sa naka-encrypt na stream sa lisensya sa server — kung walang balidong lisensya, ang susi ay hindi na-decrypt.

Paano gumagana ang DRM sa mga mobile app

Ang proseso ng pag-playback ng DRM ay binubuo ng apat na yugto: pag-load ng manifest, pagkuha ng lisensya, pag-decrypt ng nilalaman, at pagpapakita. Ang bawat yugto ay isinasagawa ng iba't ibang bahagi ng system — ang media player, CDM module, at server ng lisensya.

• Pag-load ng manifest — ang player ay tumatanggap ng MPD (DASH) o M3U8 (HLS) na may metadata tungkol sa mga naka-encrypt na segment, encryption scheme, at URL ng server ng lisensya.
• Kahilingan ng lisensya — ang player ay nagpapasa ng identifier ng nilalaman (KID) sa Content Decryption Module (CDM), na bumubuo ng kahilingan sa server ng lisensya.
• Pagkuha ng susi — sinusuri ng server ang mga karapatan ng gumagamit (subscription, rehiyon, device) at ibinabalik ang susi na naka-encrypt gamit ang pampublikong susi ng device.
• Pag-decrypt ng stream — ina-decrypt ng CDM ang susi gamit ang pribadong susi ng device at ipinapasa ito sa player para sa real-time na decryption ng mga video segment.

Content Decryption Module (CDM)

Ang CDM — ay isang secure na software o hardware module na nagsasagawa ng decryption ng nilalaman. Sa Android, ang CDM ay ipinatupad sa antas ng MediaDrm API, sa iOS — naka-embed sa AVFoundation sa pamamagitan ng AVContentKeySession. Hindi kailanman ibinubunyag ng CDM ang susi sa app — lahat ng cryptographic na operasyon ay isinasagawa sa loob ng isang secure na kapaligiran (TEE — Trusted Execution Environment).

Sa mga device na may suporta sa hardware (Secure Level 1), gumagana ang CDM sa loob ng TEE — ang susi ay hindi kailanman pumapasok sa pangunahing memorya ng device. Ito ay isang kinakailangan ng mga studio para sa pag-playback ng nilalaman sa 4K HDR. Sa mga device na walang TEE, ang mga susi ay na-decrypt ng software (L3), na nagbabawas ng proteksyon at naglilimita sa maximum na kalidad sa 540p.

Mga pangunahing scheme ng DRM

Sa mga mobile platform, tatlong DRM system ang nangingibabaw. Ang bawat isa ay eksklusibo para sa sarili nitong ecosystem, ngunit sumusuporta sa CENC, na nagpapahintulot sa paggamit ng isang naka-encrypt na nilalaman sa lahat ng platform.

Pagpili ng DRM para sa multi-platform na serbisyo

Para sa isang streaming service na gumagana sa lahat ng platform, kinakailangan ang suporta para sa lahat ng tatlong DRM. Isang praktikal na solusyon — gumamit ng CDN na may suporta sa multi-DRM (Muvi, Vualto, Axinom), na awtomatikong nagruruta ng mga kahilingan sa lisensya sa naaangkop na server batay sa device ng gumagamit. Ayon sa Streaming Learning Center (2025), 78% ng mga streaming service ay gumagamit ng Multi-DRM approach.

Ang pamantayang MPEG-DASH na may CENC ay nagpapasimple ng arkitektura: ang nilalaman ay naka-encrypt nang isang beses gamit ang isang shared key, at ang DRM system ay pinili sa client side. Ang server ng lisensya ay tumatanggap ng kahilingan na may identifier ng device at ibinabalik ang susi na naka-encrypt para sa partikular na CDM. Walang pagkakaiba sa nilalaman para sa iba't ibang platform — ibang server ng lisensya lamang.

Widevine: mga antas at tampok

Widevine — DRM system ng Google, na siyang de facto na pamantayan sa Android. Sinusuportahan nito ang tatlong antas ng seguridad na tumutukoy kung saan at paano isinasagawa ang decryption ng nilalaman. Ang antas ng seguridad ay depende sa mga kakayahan ng hardware ng device at tinutukoy ang maximum na resolution ng nilalaman.

Mga antas ng seguridad ng Widevine

Widevine L1 (hardware) — ang pinakasecure na antas. Lahat ng cryptographic na operasyon ay isinasagawa sa loob ng Trusted Execution Environment (TEE). Ang susi ay hindi kailanman umaalis sa secure na lugar. Ang mga device na may L1 ay maaaring mag-playback ng nilalaman hanggang 4K HDR. Kinakailangan ang sertipikasyon ng Google — isang pamamaraan na pinagdadaanan ng mga flagship device.

Widevine L3 (software) — ang decryption ay nagaganap sa pangunahing memorya ng device. Ang susi ay maaaring makuha ng isang technically adept na attacker. Ang resolution ay limitado sa 540p (960x540) para sa premium na nilalaman. Lahat ng device na may Android ay sumusuporta sa L3, kahit na hindi sertipikado para sa L1.

Widevine L2 — isang bihirang intermediate na antas, kung saan ang decryption ay ginagawa sa TEE, ngunit ang rendering ay sa pamamagitan ng isang hindi protektadong path. Ginagamit sa ilang Smart TV. Sa mga mobile device ay halos hindi matatagpuan.

Paano matukoy ang antas ng Widevine sa isang device

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 — proteksyon ng hardware"
        "L3" -> "Widevine L3 — proteksyon ng software"
        else -> "Widevine $securityLevel"
    }
}

Ang pamamaraan ay humihiling mula sa CDM ng property na securityLevel sa pamamagitan ng Widevine UUID. Ang ibinalik na halaga — isang string na L1, L2, o L3 — ay nagpapahiwatig ng kasalukuyang antas ng proteksyon ng device. Ang impormasyong ito ay kritikal para sa mga streaming service: kung ang device ay may L3 lamang, ang 4K na nilalaman ay hindi maaaring ipakita.

Apple FairPlay: arkitektura at prinsipyo ng paggana

FairPlay — DRM system ng Apple, na naka-embed sa lahat ng platform ng ecosystem: iOS, iPadOS, macOS, tvOS, at watchOS. Hindi tulad ng Widevine, ang FairPlay ay walang mga antas ng seguridad — ang proteksyon ay tinutukoy ng device. Sa iOS na may Secure Enclave, ang FairPlay ay nagbibigay ng antas ng proteksyon na maihahambing sa Widevine L1.

Ang FairPlay ay gumagana nang eksklusibo sa HLS (HTTP Live Streaming) protocol. Ang nilalaman ay nakabalot sa .ts (MPEG-TS) na mga segment o .m4s (fMP4) na mga fragment. Ang M3U8 manifest ay naglalaman ng #EXT-X-KEY tag na may URI ng server ng lisensya (KSM — Key Server Module) at IV initialization. Sa pagsisimula ng pag-playback, binabasa ng AVPlayer ang manifest at sa pamamagitan ng AVContentKeySession ay humihiling ng susi.

Integrasyon ng 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)
        )
    }
}

Ang delegado ng AVContentKeySession ay tumatanggap ng kahilingan ng susi na may identifier ng nilalaman (assetId). Ipinapadala ng app ang ID na ito sa sarili nitong server ng lisensya (KSM), na nagbabalik ng naka-encrypt na susi. Ang tawag na processContentKeyResponse ay nagpapasa ng susi sa CDM para sa decryption. Kung ang lisensya ay hindi balido (expired, hindi nabayaran), ang server ay nagbabalik ng error 403, at ang AVPlayer ay hindi nagsisimula ng pag-playback.

Persistent Key Loading para sa offline na nilalaman

Sinusuportahan ng FairPlay ang persistent keys — pag-save ng lisensya sa device para sa offline na pagtingin. Pagkatapos makuha ang susi, tinatawag ng app ang processContentKeyResponse na may flag na allowsPersistableKey. Ang susi ay nai-save sa Keychain at maaaring magamit nang hindi kumukonsulta sa server sa paulit-ulit na panonood. Gayunpaman, ang panahon ng bisa ng offline na lisensya ay limitado — karaniwang 7–30 araw, pagkatapos nito ay kinakailangan ang pag-renew.

Ang mga offline na lisensya ay naka-imbak sa secure na imbakan ng iOS — Keychain. Sa pagtatangka ng pag-hack (jalibreak, pagkuha ng memory dump), sinisira ng Secure Enclave ang mga susi. Ayon sa Apple (2025), ang persistent keys technology ay ginagamit sa Apple TV+, Netflix, at Disney+ para sa pag-download ng nilalaman sa iPad bago maglakbay.

Microsoft PlayReady para sa unibersal na proteksyon

PlayReady — DRM mula sa Microsoft, na ginagamit sa Windows, Xbox, at hindi na ginagamit na Windows Phone. Kahit na ang PlayReady sa mga mobile device ay mas bihira kaysa Widevine at FairPlay, ito ay mahalaga para sa mga unibersal na streaming solution na gumagana sa lahat ng Microsoft platform. Sinusuportahan ng PlayReady ang parehong software at hardware na proteksyon sa pamamagitan ng TPM.

Gumagamit ang PlayReady ng SL (Security Level) na arkitektura: SL2000 (software, analog ng Widevine L3), SL3000 (hardware, analog ng L1). Sa Xbox Series X, ang PlayReady SL3000 ay gumagana sa pamamagitan ng TEE+TPM — ang mga susi ay nakuha lamang sa isang secure na kapaligiran. Ito ay nagpapahintulot sa 4K Blu-ray playback sa console nang walang panganib ng pagkopya.

Ayon sa Microsoft Docs (2026), sinusuportahan ng PlayReady ang CENC at maaaring gumana sa MPEG-DASH sa pamamagitan ng Media Source Extensions (MSE) sa Edge browser. Para sa mga mobile app sa Android at iOS, ang PlayReady ay available sa pamamagitan ng SDK, ngunit bihirang gamitin — pangunahin para sa mga corporate application at Microsoft media services.

PlayReady Native SDK para sa Android

Nagbibigay ang Microsoft ng PlayReady Native SDK para sa Android at iOS. Ang integrasyon ay sa pamamagitan ng ExoPlayer na may PlayReady extension: idinadagdag ng developer ang PlayReadyRenderer, na naka-embed sa decoding chain. Awtomatikong lumilipat ang ExoPlayer sa pagitan ng Widevine at PlayReady depende sa kung aling DRM ang tinukoy sa MPD manifest.

Kahit na ang PlayReady ay bihirang matagpuan sa mga mobile app, ang suporta nito ay sapilitan para sa mga serbisyo na bahagi ng Microsoft ecosystem — halimbawa, mga corporate training platform sa SharePoint at Stream. Ayon sa Microsoft (2025), ang PlayReady ay ginagamit sa 23% ng mga corporate media solution kumpara sa 62% para sa Widevine.

Pagsasama ng DRM sa mobile app

Ang pagsasama ng DRM sa isang mobile app ay hindi nangangailangan ng pagsulat ng cryptographic code — ang developer ay gumagana sa isang player na sumusuporta sa DRM sa simula pa lang. Tingnan natin ang integrasyon sa Android sa pamamagitan ng ExoPlayer na may DRM extension.

Pag-configure ng ExoPlayer na may suporta sa 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 ay namamahala sa DRM session: lumilikha ng MediaDrm session, nagpoproseso ng mga kahilingan sa lisensya, at nagpapasa ng mga susi sa decoder. Ang parameter na setMultiSession(true) ay nagpapahintulot ng sabay-sabay na decryption ng maraming stream (audio + video) sa iba't ibang session. Ang MediaDrmCallback ay nagpapatupad ng HTTP request sa server ng lisensya — karaniwang POST na may body ng kahilingan sa SignedRequest format.

MediaDrmCallback para sa kahilingan ng lisensya

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
}

Ang callback ay nagpapadala ng POST request sa server ng lisensya na may Widevine UUID sa body. Sinusuri ng server ang authentication ng gumagamit (token sa header) at ibinabalik ang naka-encrypt na susi. Kung ang gumagamit ay walang aktibong subscription, ang server ay nagbabalik ng 403 Forbidden — ang ExoPlayer ay bumubuo ng DRM error na dapat pangasiwaan sa pamamagitan ng onPlayerError.

Pangangasiwa ng mga error sa DRM

Ang mga error sa DRM ay nangyayari kapag ang lisensya ay hindi balido, expired, o ang device ay hindi sumusuporta sa kinakailangang antas ng proteksyon. Ipinapasa ng ExoPlayer ang error sa pamamagitan ng Player.Listener.onPlayerError na may code na TYPE_DRM_LICENSE_EXPIRED, TYPE_DRM_UNSUPPORTED, o TYPE_SOURCE. Inirerekomenda na magpakita ng nagbibigay-kaalaman na mensahe sa gumagamit: „Hindi available ang nilalaman para sa device na ito” o „I-renew ang subscription upang manood”.

Ayon sa analytics ng mga streaming service (2025), hanggang 8% ng mga nabigong pagsisimula ng playback ay nauugnay sa mga error sa DRM. Sa mga ito, 60% ay expired na lisensya, 25% — hindi pagkakatugma ng device, at 15% — mga error sa network sa kahilingan ng susi. Ang awtomatikong pagsubok muli pagkatapos ng 5 segundo ay lumulutas ng 40% ng mga kaso ng error sa network.