Neuerungen in PlayReady Version 4.5

Diese Seite enthält eine Übersicht über die wichtigsten Änderungen zwischen PlayReady, Version 4.4 und PlayReady, Version 4.5.

Allgemeine Änderungen in PlayReady Version 4.5

Herausforderung verschlüsselung mit PlayReady Server Deployment Certificate

In früheren Versionen von PlayReady werden Lizenzkauf und andere Client-Herausforderungen immer mit einem festen öffentlichen Schlüssel verschlüsselt. Ab PlayReady 4.5 kann ein Client, der codiert ist, nur mit einem unterstützenden Server sprechen, stattdessen Probleme mit dem PlayReady Server-Bereitstellungszertifikat, das von Microsoft ausgestellt wurde, datenschutz verschlüsseln. Das PlayReady Server SDK entschlüsselt dann die Herausforderung mit dem entsprechenden privaten Schlüssel, der von der PlayReady Server SDK-Anwendung übergeben wird, anstelle eines festen privaten Schlüssels.

Lizenzserverzeit

In früheren Versionen von PlayReady benötigt die Clientanwendung in der Regel die Clientanwendung, um mit einem separaten Secure Time-Server zu sprechen, um die Zeit abzurufen, die zum Festlegen der lokalen Uhr verwendet wird. Ab PlayReady 4.5 kann ein Client, der codiert ist, nur mit einem unterstützenden Server sprechen, stattdessen eine Zeit verwenden, die vom PlayReady Server SDK während des Lizenzkaufs bereitgestellt wird. Weitere Informationen finden Sie unter PlayReady Trusted Clocks.

Schlüssel Exchange

Mithilfe des Lizenzkaufprotokolls kann ein PlayReady-Client und -Server jetzt beliebige Schlüssel austauschen, die verwendet werden können, um beliebige anwendungsbezogene Daten zu verschlüsseln, entschlüsseln, zu signieren und zu überprüfen, wo die Schlüssel selbst mithilfe von PlayReady geschützt sind. Wenn der Client SL3000 ist, werden die Schlüssel selbst durch die vertrauenswürdige Ausführungsumgebung geschützt. Weitere Informationen finden Sie unter PlayReady Key Exchange.

Wasserzeichenrichtlinie

Die Funktionalität wurde hinzugefügt, um die Verwendung der "Watermarking Signalling Signalling Explicit Digital Video Output Restriction" gemäß den PlayReady-Complianceregeln zu vereinfachen.

Änderungen in PlayReady Server SDK Version 4.5

Allgemeine Serveränderungen

Schlüssel Exchange Lizenzen können verwendet werden, um während des Lizenzkaufs beliebige Schlüssel für einen Client bereitzustellen.

Wenn der Client bereitgestellt wird, werden die unterstützten Wasserzeichentechnologien der PlayReady Server SDK-Anwendung zur Verfügung gestellt. Dies vereinfacht die Verwendung der "Watermarking Signalling"-Einschränkung für die explizite digitale Videoausgabe gemäß der Definition der PlayReady-Complianceregeln.

Änderungen der Server-API-Dokumentation

Neue Server-API-Dokumentation für die .NET Standardversion des PlayReady Server SDK wurde erstellt und veröffentlicht. Microsoft empfiehlt die Migration zum .NET Standard SDK.

Die Server-API-Dokumentation in der Datei PlayReady.chm, die im PlayReady Documentation Pack enthalten ist, gilt nur für die ältere .NET Framework Version des PlayReady Server SDK. Diese Dokumentation gilt jetzt als veraltet, wurde seit PlayReady 4.0 nicht aktualisiert und erhält keine zukünftigen Updates.

Die meisten APIs in den beiden SDKs sind identisch, sodass die .NET Standard-Dokumentation für die meisten Zwecke ausreichend sein sollte. Es gibt jedoch einige erhebliche Unterschiede, bei denen Klassen, Schnittstellen und Methoden unterschiedlich sind.

Hier sind die allgemeinen Unterschiede zwischen den beiden SDKs.

  1. Das .NET Standard SDK verwendet Schnittstellen an vielen Stellen, an denen das .NET Framework SDK Klassen verwendet.

  2. Die von der Anwendung implementierten .NET Standard SDK-Handlerschnittstellen verwendet asynchrone Methoden, bei denen das .NET Framework SDK synchrone Methoden verwendet. Daher enden die API-Namen der .Net Standard SDK-Handlerschnittstelle mit dem Wort "Async" und geben eine Task-Klasse<anstelle einer einfachen Klasse> zurück (wobei die Klasse für die Handlerschnittstellenmethode spezifisch ist).

  3. Das .NET Standard SDK ist transportagnostisch. Daher wird kein HTTP-Kontext direkt für die Anwendung bereitgestellt. Wenn Sie ASP.NET Core verwenden, lesen Sie die ASP.NET Core Dokumentation, insbesondere die IHttpContextAccessor-Schnittstelle.

  4. Das .NET Standard SDK unterstützt das Paketinhaltsprotokoll nicht (z. B. IPackagingDataAcquisitionHandler ist nicht vorhanden). Diese Funktionalität wird in PlayReady 4.6 wiederhergestellt.

Hier ist eine vollständige Liste der spezifischen Unterschiede ab PlayReady 4.5. Diese Liste enthält keine Funktionalität, die nur im .NET Standard SDK vorhanden ist, und listet nicht alle Verpackungsklassen auf, die wiederhergestellt werden.

 

.NET Framework Klasse oder Schnittstelle .NET Standardäquivalent Unterschiede
ProtocolChallengeContext-Klasse IProtocolChallengeContext-Schnittstelle Die HttpRequest Request-Eigenschaft ist nur im .NET Framework SDK vorhanden, wie oben beschrieben.
ProtocolChallenge-Klasse IProtocolChallenge-Schnittstelle Keine.
IDeleteLicenseHandler-Schnittstelle identisch ProcessDeleteLicenseDataAsync ist synchron im .NET Framework SDK, wie oben beschrieben.
DeleteLicenseDataChallenge-Klasse IDeleteLicenseDataChallenge-Schnittstelle Keine.
IDomainHandler-Schnittstelle identisch HandleJoinDomainAsync und HandleLeaveDomainAsync sind synchron im .NET Framework SDK, wie oben beschrieben.
JoinDomainChallenge-Klasse IDomainChallenge- und IJoinDomainChallenge-Schnittstellen Die statische JoinDomainChallenge.GenerateDomainKeyPair-Methode ist im .NET Standard SDK nicht vorhanden. Der Verlust dieser Funktionalität ist ein Fehler, der in PlayReady 4.6 behoben wird, indem es als statische Methode zu DomainCertificateBuilder hinzugefügt wird.
LeaveDomainChallenge-Klasse ILeaveDomainChallenge-Schnittstelle Keine.
ILicenseAcknowledgementHandler-Schnittstelle identisch HandleLicenseAcknowledgementAsync ist synchron im .NET Framework SDK, wie oben beschrieben.
LicenseAcknowledgementChallenge-Klasse ILicenseAcknowledgementChallenge-Schnittstelle Keine.
ILicenseAcquisitionHandler-Schnittstelle identisch HandleLicenseAcquisitionAsync ist synchron im .NET Framework SDK, wie oben beschrieben.
LicenseChallenge-Klasse ILicenseChallenge-Schnittstelle Keine.
IMeteringHandler-Schnittstelle identisch GetMeteringCertificateAsync und ProcessMeteringDataAsync sind synchron im .NET Framework SDK, wie oben beschrieben.
MeteringCertificateChallenge-Klasse IMeteringCertificateChallenge-Schnittstelle Keine.
ProcessMeteringDataChallenge-Klasse IProcessMeteringDataChallenge-Schnittstelle Keine.
ISecureStopHandler-Schnittstelle identisch ProcessSecureStopDataAsync ist synchron im .NET Framework SDK, wie oben beschrieben.
SecureStopDataChallenge-Klasse ISecureStopDataChallenge-Schnittstelle Die GetSecureStopData-Methodenüberladung, die einen ISecureStop2Handler verwendet, ist nur im .NET Framework SDK vorhanden. Das .NET Standard SDK lädt diesen Handler stattdessen wie alle anderen.
ISecureStopHandler2-Schnittstelle identisch GetSecureStop2AESKeyAsync ist synchron im .NET Framework SDK, wie oben beschrieben.
PlayReadyServerAuthorization-Klasse identisch Die Methoden der Klasse sind im .NET Framework SDK und der Instanz im .NET Standard SDK statisch.

Server-API-Änderungen

Dies ist lediglich eine Übersicht. Weitere Informationen finden Sie in der Server-API-Dokumentation .

Die LicenseResponse.GetLicenses-Methode gibt jetzt ein leeres Array anstelle von NULL zurück, wenn keine Lizenzen hinzugefügt wurden.

Die folgenden Klassen und Enumerationen wurden hinzugefügt.

  • AdvancedLicense-Klasse (abstrakte, erbt von Lizenz) – eine Teilmenge vorhandener Eigenschaften und Methoden aus MediaLicense wurde in diese Klasse verschoben, und MediaLicense erbt jetzt von AbstractLicense. Es sind keine Anwendungsänderungen erforderlich, um MediaLicense zu verwenden.
  • KeyExchangeLicense-Klasse (erbt von AdvancedLicense) – wird verwendet, um Lizenzen zu erstellen, die während des Lizenzkaufs beliebige Schlüssel für einen Client bereitstellen.
  • KeyExchangeRight-Klasse (erbt von Right) – wird verwendet, um den Schlüssel und seine zulässige Verwendung für eine KeyExchange-Lizenz anzugeben.
  • KeyExchangeAlgorithm-Enumeration – wird verwendet, um die zulässige Verwendung für einen Schlüssel in einer KeyExchange-Lizenz anzugeben.
  • WatermarkVendor-Klasse – wird verwendet, um die unterstützten Wasserzeichentechnologien des Clients für die Anwendung verfügbar zu machen.
  • LicenseServerTimeCertificate-Klasse – wird verwendet, um das Zertifikat für die Signatur des Lizenzservers zu enthalten, die in der Lizenzkaufantwort zurückgegeben wird.

Nachfolgend wurden einzelne Klassen hinzugefügt.

  • Die PlayReadyHeader-Klasse macht verfügbar, ob der Header die Unterstützung pro Streamschlüssel angibt und ob er explizit eine Lizenz anfordert oder nicht.
  • Die Enumeration "ContentKeyType" fügt den Wert KeyExchange hinzu.
  • Die Zertifikatklasse fügt Bytearrayeigenschaften hinzu, die den öffentlichen Schlüssel und den öffentlichen Schlüssel des Zertifikats anzeigen.
  • Die Lizenzklasse fügt eine GUID-Eigenschaft hinzu, die die eindeutige ID der Lizenz und eine IEnumerable<Right-Eigenschaft> anzeigt, um die Rechte zurückzugeben, die der Lizenz hinzugefügt wurden.
  • Die LicenseChallengeTeeAPIs-Enumeration fügt Werte für alle neuen PK 4.5 TEE-APIs hinzu.
  • Die Enumeration "LicenseChallengeReeFeatures" fügt Werte für LicenseServerTime und KeyExchange hinzu.
  • Die LicenseChallenge-Klasse fügt die Liste von KeyExchangeAlgorithms hinzu, die vom Client unterstützt werden, die WatermarkVendors den Client unterstützt, die PK-Versionen des TEEs des Clients und REE (die möglicherweise identisch sind) und ob der Client die aktuelle LicenseServerTime erfordert.
  • Die LicenseResponse-Klasse fügt eine LicenseServerTimeCertificate-Eigenschaft hinzu, um das Zertifikat festzulegen, das zum Signieren der Lizenzserverzeit verwendet wird, die in der Lizenzkaufantwort zurückgegeben wird.
  • Die ExplicitOutputRestrictionsConstants-Klasse fügt Konstanten für Watermark und InternalScreenOnly hinzu. Weitere Informationen zu diesen GUIDs finden Sie in den PlayReady-Complianceregeln.

Änderungen am PlayReady Device Porting Kit Version 4.5

Allgemeine Änderungen am Geräteporting Kit

  • Das gesamte PlayReady Device Porting Kit wurde auf Microsoft Source-Code Annotation Language (SAL) 2.0 aktualisiert.
  • Einige nicht unterstützte Codepathen, die nur in Microsoft-internen Implementierungen verwendet werden, wurden entfernt, um Verwirrung zu beseitigen und Kompilierungszeiten und binäre Größen zu reduzieren. Weitere Verbesserungen in diesem Bereich werden voraussichtlich in zukünftige Versionen aufgenommen.
  • Wo die zugrunde liegende Compiler- und Computerarchitektur unterstützt wird, können systemeigene 128-Bit-Ganzzahltypen jetzt verwendet werden, um die Standardimplementierung von ECC256 zu beschleunigen.
  • Eine Standardimplementierung des SHA256 HMAC-Algorithmus wurde hinzugefügt.

Änderungen der GERÄTEporting Kit-API

Dies ist lediglich eine Übersicht. Weitere Informationen finden Sie in der API-Dokumentation in den zugehörigen Codekommentaren im PlayReady Device Porting Kit .

DRM_CDMI_SetServercertificate dürfen jetzt mit einem PlayReady Server-Bereitstellungszertifikat aufgerufen werden, um Lizenzkäufe und andere Clientprobleme zu verschlüsseln. Die Funktion leitet in diesem Szenario an Drm_AppContext_SetProperty weiter. Die vorhandene Nutzung bleibt unverändert.

Die folgenden öffentlichen Funktionen wurden hinzugefügt:

  • Drm_AppContext_SetProperty
  • Drm_KeyExchange_Prepare
  • Drm_KeyExchange_Perform
  • Drm_KeyExchange_Close

Die folgenden Strukturen wurden hinzugefügt:

  • DRM_DGP_REE_FEATURE_LIST_4_5
  • DRM_DGP_TEE_API_LIST_4_5

Die folgenden TEE-APIs wurden hinzugefügt:

  • DRM_TEE_BASE_GetSystemTime2
  • DRM_TEE_LICPREP_PackageKey2
  • DRM_TEE_LICENSESERVERTIME_ProcessResponseData
  • DRM_TEE_DECRYPT_PrepareToDecrypt2
  • DRM_TEE_LICGEN_CompleteLicense2
  • DRM_TEE_KEYEXCHANGE_Prepare
  • DRM_TEE_KEYEXCHANGE_Perform

Die folgenden OEM-TEE-APIs wurden hinzugefügt:

  • OEM_TEE_BASE_ECC256_SetKey
  • OEM_TEE_CRYPTO_SHA256_HMAC_VerifyMAC
  • OEM_TEE_CRYPTO_SHA256_HMAC_CreateMAC
  • OEM_TEE_PERSISTENTSTORAGE_Read
  • OEM_TEE_PERSISTENTSTORAGE_Write
  • OEM_TEE_GetSupportedWatermarkVendors

Die folgenden OEM-TEE-APIs wurden ohne funktionsbezogene Änderungen umbenannt:

Alter Name Neuer Name
OEM_TEE_DECRYPT_UnshuffleScalableContentKeys OEM_TEE_BASE_UnshuffleScalableContentKeys
OEM_TEE_DECRYPT_CalculateContentKeyPrimeWithAES128Key OEM_TEE_BASE_CalculateContentKeyPrimeWithAES128Key
OEM_TEE_DECRYPT_DeriveScalableKeyWithAES128Key OEM_TEE_BASE_DeriveScalableKeyWithAES128Key
OEM_TEE_DECRYPT_InitUplinkXKey OEM_TEE_BASE_InitUplinkXKey
OEM_TEE_DECRYPT_UpdateUplinkXKey OEM_TEE_BASE_UpdateUplinkXKey
OEM_TEE_DECRYPT_DecryptContentKeysWithDerivedKeys OEM_TEE_BASE_DecryptContentKeysWithDerivedKeys
OEM_TEE_DECRYPT_EnforcePolicy OEM_TEE_POLICY_Enforce