La Avanceret indholdsbeskyttelse i Windows 11 Den er afhængig af avancerede DRM-teknologier med PlayReady som kernekomponent og et stærkt fokus på brugen af sikker hardware. Streamingplatforme og -udbydere anvender i stigende grad denne tilgang for at tilbyde HD-, 4K- og endda UHD-video uden frygt for ulovlig kopiering eller udtrækning.
I denne sammenhæng, at forstå hvordan det fungerer Trin-for-trin implementering af DRM og sikker afspilning I Windows-økosystemet (både Windows 11 og Windows 10, såvel som Xbox) er det afgørende for enhver udvikler, der ønsker at levere premium-indhold, overholde studiets regler og sikre en god brugeroplevelse. Vi vil roligt, men grundigt, gennemgå alle de involverede elementer: PlayReady HWDRM og SWDRM, Windows TEE, exit-beskyttelse, licensering, UWP-appmigrering og mere.
Hardwarebaseret DRM med PlayReady: koncept og fordele
Kernen i sikker afspilning i moderne Windows er PlayReady med hardwarebaseret DRM-understøttelse (HWDRM)integreret direkte i operativsystemet som en indbygget komponent. I modsætning til rent softwarebaseret DRM (SWDRM) bruger hardwaretilgangen en beskyttet kryptografisk kerne og et betroet runtime-miljø til at beskytte alt kritisk: private nøgler, indholdsnøgler og komprimerede eller ukomprimerede videostreams.
Takket være denne model, indholdet af HD (1080p) og ultra HD (UHD) Det kan afspilles på en bred vifte af Windows-enheder, hvor alt følsomt materiale holdes inden for sikre hardwareområder. Det praktiske resultat er, at overfladearealet for uautoriseret kopiering reduceres drastisk, da tasterne aldrig eksponeres, og videoen kun "afvikles" i den sidste strækning af den beskyttede pipeline.
PlayReady i Windows 10 og Windows 11 er ikke længere en simpel AppX-komponent: Det er en del af selve systemet. og er eksponeret for UWP-applikationer gennem navneområdet Windows.Media.Protection.PlayReadyDerudover indeholder Windows SDK'et de nødvendige headere til at håndtere PlayReady-specifikke fejlkoder, hvilket giver apps mulighed for at reagere præcist på licens- eller exit-beskyttelsesproblemer.
Blandt forbedringerne i PlayReady til moderne Windows skiller følgende sig også ud: evne til proaktivt at erhverve flere ikke-persistente licenser i en enkelt besked, understøttelse af tidsbegrænsede licenser (LDL) med udløb i realtid, adskillelse af lyd- og videolicenser og kontrollerede maksimale opløsninger (MaxResDecode), selv når mere kraftfulde nøgler er tilgængelige.
Windows TEE: Sådan integreres det betroede runtime-miljø
For at hardware-DRM skal give mening, er Windows afhængig af en Eget betroet udførelsesmiljø (TEE), kendt som Windows TrEE. Selvom de interne detaljer om implementeringen ikke er offentligt tilgængelige, beskrives det, hvordan den passer ind i PlayReady-arkitekturen til UWP.
Windows implementerer en OEM proxy-lag som serialiserer PRITEE-kaldene og sender dem til en brugertilstandsdriver i Windows Media Foundation-undersystemet. Derfra omdirigeres disse kald enten til Windows TrEE-driveren eller til OEM-grafikdriveren, afhængigt af enhedskonfigurationen og den valgte udgående sti.
Dette design tillader alle udgangsbeskyttelse i HWDRM Disse regler anvendes indefra Windows TEE. Med andre ord ved systemet til enhver tid, hvilke udgange der er tilsluttet, hvad de understøtter (HDCP, stiktyper, Miracast osv.), og anvender PlayReady-licensreglerne, før indholdet vises på en skærm eller et fjernsyn.
Hvis en producent eller organisation har brug for at udvikle en specifik TEE-port til PlayReady på Windows, tilbyder Microsoft støtte via direkte kanaler (for eksempel specialiserede tekniske kontakter), da dette er et meget følsomt område med hensyn til sikkerhed og compliance.
Chrome, Edge og andre browsere: PlayReady-understøttelse og streamingoplevelse
I browsersektoren er tendensen tydelig: udnytte hver platforms native DRM For at reducere afhængigheder af plugins og muliggøre sikker streaming i den bedst mulige kvalitet. Indtil nu har Chrome på Windows primært brugt Widevine, Googles DRM-løsning, som i nogle scenarier begrænser den maksimale opløsning, der er tilgængelig for premium-indhold.
Google arbejder på at Chrome kan bruge PlayReady DRM med hardwareunderstøttelse på Windows 11. Dette åbner døren for at afspille 4K- og UHD-videoer, ligesom Microsoft Edge gør det. Faktisk bruger store platforme som Netflix allerede PlayReady til at beskytte deres high-end-titler i Windows-økosystemet.
Googles plan indebærer Chrome-understøttelse samtidig PlayReady og WidevineDette giver brugerne mulighed for at vælge den bedste mulighed for hver enhed. Derudover vil browseren indbygge en privatlivsindikator, der er synlig i adresselinjen, når et websted tilgår indhold, der er beskyttet af PlayReady, hvilket giver brugerne mulighed for at tillade eller blokere denne adgang på en informeret måde.
Dette skridt sætter Chrome i en mere konkurrencedygtig position i streamingoplevelse på Windows 11hvilket bringer dens ydeevne og visuelle kvalitet tættere på den, Edge allerede tilbyder, takket være dens dybe integration med systemet og med PlayReady HWDRM.
DRM-grundlæggende i Windows: Fra Windows 2000 til Windows 11
Støtten fra DRM til digital lyd i Windows Det er ikke nyt. Det har eksisteret siden Windows 2000 og Windows 98/Me. Men sandheden er, at kernesikkerhed for alvor begyndte at slå igennem i Windows XP og senere versioner. I disse versioner stoppede systemet med at tillade uautoriserede drivere, der kunne opfange beskyttet lyd og optage den ukrypteret til disk.
Klassisk arkitektur er baseret på opbevaring af beskyttet indhold på disk i krypteret formatUnder afspilning forbliver streamen krypteret/forvredet, mens den læses og gemmes i hukommelsen, indtil den når DRMK-driveren (Drmk.sys). Denne komponent dekrypterer indholdet og sender det direkte til en betroet lyddriver, hvilket minimerer den del af datastien, hvor indholdet vises i klartekst.
Når en filtergraf konstrueres til at gengive en ukontrolleret lydsekvens, autentificerer DRMK de involverede adapterdrivere og KS-filtre. Hvis nogen af grafkomponenterne ikke opfylder DRM-kraveneSystemet afviser hele reproduktionskæden for at forhindre lækager.
En DRM-kompatibel controller skal blokere uautoriserede kopier under afspilning af digitalt indhold og deaktiver standard digitale udgange, der er modtagelige for optagelse (såsom S/PDIF). Interessant nok gælder denne begrænsning ikke for USB-enheder. I øjeblikket tillader DRMK kun afspilning af sikkert indhold via USB-højttalere, der ikke har yderligere digitale udgange.
Hardware-DRM vs. software-DRM: Vigtigste forskelle og betingelser
Når man udvikler UWP-applikationer rettet mod indhold af høj værdi, er det vigtigt at være klar over, hvornår det bruges. Hardware-DRM (HWDRM) og hvornår man skal bruge software-DRM (SWDRM)Og adfærd ændrer sig markant. Især med hensyn til udgangsbeskyttelse.
Med PlayReady HWDRM på Windows 10 og 11 gælder systemet strengere udgangsbeskyttelsesniveauer (OPL) til ukomprimeret digital video.
En anden vigtig forskel er, at med HWDRM, Outputbeskyttelse anvendes på alle skærme baseret på den mindst kapable skærmHvis en bruger har to skærmeHvis den ene skærm har HDCP, og den anden ikke har, og licensen kræver HDCP, vil afspilning mislykkes, selvom indholdet kun vises på den HDCP-kompatible skærm. I SWDRM ville afspilning være tilladt, så længe det kun vises på den HDCP-aktiverede skærm.
Derudover understøtter HWDRM ikke Beskyttet mediesti (PMP)Windows Media Video/VC-1-codec'et understøttes ikke, og multi-GPU-konfigurationer har begrænsninger for vedvarende licensering. Dette kræver forsigtighed ved opgradering af grafikhardware på brugercomputere.
Administrer flere GPU'er og persistente licenser med PlayReady
I scenarier hvor en pc har mere end én GPU (for eksempel integreret grafik plus et dedikeret kort), bliver administrationen af persistente licenser i HWDRM mere kompleks. PlayReady forbinder disse licenser med et hash-datalager (HDS), der er knyttet til hardwarenøglerne til den GPU, der er i brug på anskaffelsestidspunktet.
Lad os forestille os den typiske proces: en kunde køber en computer med en integreret GPU, bruger en app, som de anskaffer sig Vedvarende licenser under hardware-DRMog installerer senere et nyt dedikeret grafikkort. På det tidspunkt vil alle HDS-licenser, der er knyttet til den integrerede GPU, ikke længere være gyldige med det nye kort, som vil have sin egen uafhængige HDS.
For at forhindre afspilning i at mislykkes, fordi den nye hardware ikke kan dekryptere de gamle licenser, vedligeholder PlayReady en Separat HDS for hver detekteret GPUDet betyder, at hvis appen registrerer en GPU-ændring, kan den være nødt til at genkøbe licenser for indhold, der, set fra et SWDRM-scenarie eller uden hardwareændringer, allerede ville være løst.
I praksis bør applikationer, der administrerer persistente licenser i HWDRM, forudse det mulige faktiske "tab" af licenser efter opgraderinger af grafikkort. Da dette er et relativt sjældent problem, vælger mange udbydere dog at håndtere det via kundesupport, når indholdet holder op med at afspilles korrekt efter en hardwareændring.
Sådan tvinger du brugen af software-DRM (tilsidesætter HWDRM)
Noget indhold, på grund af dets natur eller de anvendte teknologier, De er ikke kompatible med hardware-DRMDette er tilfældet med noget indhold af "cocktail"-typen, visse video-codecs udover H.264/HEVC eller endda HEVC-indhold på enheder, hvis HWDRM ikke understøtter den pågældende codec.
I disse tilfælde kan det være tilrådeligt at deaktivere brugen af HWDRM og tving PlayReady til at bruge softwarebeskyttelseslagetSom standard vil det blive brugt, hvis systemet understøtter hardware-DRM. Så du skal eksplicit deaktivere det, før du starter afspilning. Og sørg for, at der ikke er nogen PlayReady-objekter tilbage i hukommelsen.
En måde at gøre dette på er at oprette en konfigurationscontainer i ApplicationData.LocalSettings og indtast værdien SoftwareOverride = 1 i nøglen LegeklarFor at genaktivere HWDRM skal du blot indstille værdien til 0. Derudover vil for hver afspilning MediaProtectionManager med ejendommen Windows.Media.Protection.UseSoftwareProtectionLayer = true, hvilket tvinger brugen af softwarelaget.
Den nemmeste måde at finde ud af, hvilken type DRM der bruges i en UWP-app, er at tjekke mappen PlayReady i pakkens LocalCache fra programmet. Hvis en fil vises mspr.hdsVi arbejder med SWDRM. Hvis det vi ser er en anden fil .hds I dette tilfælde befinder vi os under HWDRM. Ved at slette PlayReady-mappen og gentage testen kan du verificere konfigurationsændringer.
Detektion af hardware DRM-funktioner (herunder AES128CBC og HEVC)
Før man beslutter, hvilken type indhold der skal vises, eller hvilke licenser der skal udstedes, anbefales det kraftigt, at applikationen Kontroller, hvilke hardware-DRM-funktioner enheden understøtterFor at gøre dette tilbyder PlayReady metoden PlayReadyStatics.CheckSupportedHardware, som modtager en værdi fra optællingen som parameter PlayReadyHardwareDRMFeatures.
Ved at konsultere f.eks. funktionen HardwareDRM Er det muligt at finde ud af, om der er generel DRM-understøttelse til hardware? Ved at spørge... HEVC Den afgør, om hardwaren understøtter H.265 højeffektiv video-codec. Fra og med Windows 10 version 1709 er det også muligt at kontrollere, om enheden understøtter AES128CBC hardwarekryptering ved hjælp af funktionen Aes128Cbc.
Da denne optælling muligvis ikke findes i tidligere versioner af systemet og kan forårsage undtagelser, hvis den bruges uden kontrol, skal den kombineres med ApiInformation.IsApiContractPresent (version 5 af Windows.Foundation.UniversalApiContract) før forespørgslen udføres. Det typiske mønster er først at kontrollere for tilstedeværelsen af kontrakten og, kun hvis den er tilgængelig, kalde den CheckSupportedHardware.
Derudover ejendommen PlayReadyStatics.PlayReadyCertificateSecurityLevel returnerer klientcertifikatsikkerhedsniveauHvis værdien er 0, er klienten ikke individualiseret eller provisioneret. Hvis den er mindre end 3000, betyder det, at hardware-DRM ikke bruges. Og hvis den er lig med eller større end 3000, indikerer det, at enheden opfylder betingelserne for HWDRM.
Outputbeskyttelse: OPL, HDCP, Miracast og eksplicitte begrænsninger
En af grundpillerne i PlayReady-modellen i Windows 10 og 11 er den omfattende kontrol over video- og lydudgangeLicenser kan definere forskellige outputbeskyttelsesniveauer (OPL) for komprimeret digital video, ukomprimeret digital video, analoge stik, HDMI, DVI, DisplayPort, MHL eller Miracast.
I tilfælde af video tillader en OPL på 100 normalt indhold at passere igennem uden større restriktioner. Højere niveauer omfatter betingelser som f.eks. interagere med HDCP eller begrænse indholdets effektive opløsning. Over visse tærskler sender Windows 10 aldrig komprimeret digital video til udgangene, uanset den specifikke værdi, i overensstemmelse med PlayReady-complianceretningslinjerne.
Kortlægningstabellen viser, at SWDRM for OPL 270 vil forsøge at aktivere HDCP, og hvis det mislykkes, vil opløsningen reduceres til 520.000 pixels. Med HWDRM dog... Afspilning blokeres på HDMI/DVI, hvis HDCP ikke kan etableresFor OPL 300, hvis HDCP-typebegrænsningen er defineret, vil kun indhold med HDCP 2.2 og sekvenstype 1 være tilladt. Ellers vil afspilningen blive afbrudt.
For lyd bestemmer OPL'er også, om passagen af komprimeret eller ukomprimeret digital lydog under hvilke betingelser HDCP eller SCMS skal konfigureres i CopyNever. Igen, efterhånden som niveauerne stiger, bliver restriktionerne strengere og kan fuldstændig forhindre afspilning, hvis de ikke overholdes.
Miracast betragtes som en funktion i Windows 10. digital udgang plusPlayReady tillader afspilning af indhold via Miracast, så længe HDCP 2.0 eller højere er aktiveret. Afhængigt af den OPL, der er tildelt i licensen, vil enheden forsøge at etablere HDCP. Hvis dette mislykkes, vil den ikke sende indhold til den pågældende udgang. Når høje OPL'er og HDCP-typebegrænsninger kombineres, er afspilning kun tilladt, hvis HDCP 2.2 og den korrekte streamtype opnås.
Forudsætninger og migrering af PlayReady UWP-applikationer
At skabe UWP-applikationer, der udnytter PlayReady og dens HWDRM-funktionerFørst skal nogle miljøkrav opfyldes. Det er vigtigt at arbejde på Windows 10 eller nyere, og hvis du kompilerer de officielle PlayReady-eksempler til UWP, skal du bruge Visual Studio 2015 eller nyere (til 8.1-apps understøttes VS 2013 stadig).
I migreringsprocessen fra Windows Store-apps 8.xa UWP til Windows 10 er den mest åbenlyse ændring navneområdet: du skal erstatte alle referencer til Microsoft.Media.PlayReadyClient af Windows.Media.Protection.PlayReadyReferencer til WinMD-metadata kommer nu fra systemets universelle kontrakter (f.eks. windows.foundation.universalappcontract.winmd).
Hvis du vil afspille beskyttet 1080p HD- eller UHD-indhold, skal du Implementer PlayReady-hardware-DRMFor de typer indhold, der ikke er kompatible med HWDRM, anvendes hardwareoverstyringslogikken og brugen af SWDRM beskrevet ovenfor.
Med hensyn til MediaProtectionManager, er det vigtigt at konfigurere det med de korrekte egenskaber: GUID'et for PlayReady-beskyttelsessystemet (MediaProtectionSystemId), tilknytningen af systemidentifikatorer til strengen PlayReadyWinRTTrustedInput og containerens GUID (MediaProtectionContainerGuidDenne konfiguration gør det muligt for Windows-multimediapipelinen at knytte beskyttelsesanmodninger til den relevante PlayReady-motor.
Proaktiv erhvervelse af ikke-persistente licenser og licenskæder
En af de vigtigste forbedringer i de seneste versioner af PlayReady er Proaktiv erhvervelse af ikke-persistente licenser før afspilningen begynder. I tidligere versioner kunne de kun hentes reaktivt under afspilningsprocessen. Dette øgede tiden til den første frame.
El anbefalet flow består af:
- Opret en afspilningssession, hvor ikke-persistente licenser gemmes.
- Link den session til licensanskaffelsesklassen.
- Generer en licensserviceanmodning (LAServiceRequest).
- Færdiggør anskaffelsesprocessen.
- Knyt den session til den multimediekilde, der bruges af afspilleren.
PlayReady giver dig også mulighed for at gruppere købet af [noget] i én besked. flere ikke-persistente licenserDette sparer rundture til serveren. Det giver også brugeren mulighed for at gennemse et indholdsbibliotek, mens licenser til forskellige uddrag downloades i baggrunden. Dette reducerer ventetider senere, når brugeren beslutter, hvad han vil se.
Derudover kan licenser omfatte avancerede midlertidige restriktioner: absolut udløb, udløb efter første afspilning eller udløb i realtid. Ved at kombinere disse mekanismer med flere licenser i den samme besked er det muligt at dække tilfælde, hvor korttidslicenser (STL'er) oprindeligt købes under browsing, og senere erhverves en længerevarende licens, der tillader uafbrudt afspilning indtil slutningen af indholdet.
Sikker stop og sessionskontrol
En anden funktion, der er introduceret i PlayReady, kaldes Sikkert stopDenne funktion er designet til at give enheden mulighed for pålideligt at informere en streamingtjeneste om, at afspilningen af et bestemt segment er afsluttet.
Denne mekanisme muliggør langt mere præcis kontrol af brugsbegrænsninger og generering af forbrugsrapporter i tjenester med flere enheder. Der er to typiske scenarier:
- Når afspilningen slutter naturligt (slut på indhold), eller brugeren stopper den frivilligt.
- Når en tidligere session uventet afbrydes af en tvungen applukning eller et systemnedbrud.
Applikationen bør kontrollere for mulige problemer i begyndelsen eller slutningen af sessionen. Sikre stop afventer og send de tilsvarende udfordringer uafhængigt af enhver anden afspilning. Microsoft giver konkrete eksempler, der viser, hvordan man implementerer dette flow i en UWP-app.
Brug af PlayReady på Xbox One og sikkerhedsovervejelser
Hvis du vil drage fordel PlayReady DRM i en UWP-app til Xbox OneDet første trin er at indhente godkendelse til den Partner Center-konto, der er knyttet til appen. Denne godkendelse kan behandles via en Microsoft-kontakt eller ved at sende konto- og virksomhedsoplysningerne via de angivne kanaler.
Når tilladelsen er givet, er det nødvendigt at Tilføj manuelt en enhedsfunktion (DeviceCapability) i applikationsmanifestet (Package.appxmanifestDette gøres ved at redigere filen i XML-tilstand og tilføje den tilsvarende post i sektionen. <Capabilities> for at aktivere brugen af PlayReady på konsollen.
Xbox-udviklingssæt har en begrænsning på sikkerhedsniveauet: de tillader kun afspilning af indhold med SL150-niveau, mens kommercielle enheder kan håndtere højere niveauer såsom SL2000 eller SL3000. At udføre tests i devkitsDu bør bruge testindhold, der kun kræver SL150-licenser. En anden mulighed er at implementere logik, så visse testkonti får rabat på licenser til bestemte aktiver.
Med denne konfiguration kan apps tilbyde en sikker streamingoplevelse på Xbox One. Dette stemmer overens med den oplevelse, der opnås på Windows 10/11 med HWDRM, og kombinerer PlayReady, TEE og udgangsbeskyttelse i henhold til de samme overholdelsesregler.
Samlet set er DRM- og sikker afspilningsøkosystemet i Windows 11 afhængigt af en meget moden kombination af PlayReady, et pålideligt runtime-miljø, omfattende outputkontrol og fleksibel licensadministration, der gør det muligt for udviklere og streamingplatforme at levere HD- og UHD-indhold med et højt sikkerhedsniveau uden at ofre en problemfri slutbrugeroplevelse.
