SPEKE API v1: personalizaciones y restricciones a la especificación de DASH-IF - Especificación de API de Secure Packager and Encoder Key Exchange

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

SPEKE API v1: personalizaciones y restricciones a la especificación de DASH-IF

La especificación CPIX de DASH-IF, https://dashif. org/docs/DASH-IF-CPIX-v2-0.pdf admite varios casos de uso y topologías. La especificación de API de SPEKE se ajusta a la especificación CPIX con las siguientes personalizaciones y restricciones:

  • SPEKE sigue el flujo de trabajo Encriptador-Consumidor.

  • En las claves de contenido cifradas, SPEKE aplica las siguientes restricciones:

    • SPEKE no admite la verificación de firma digital (XMLDSIG) para cargas de solicitud o respuesta.

    • SPEKE requiere 2048 certificados basados en RSA.

  • En los flujos de trabajo de rotación de claves, SPEKE requiere el filtro ContentKeyUsageRule, KeyPeriodFilter. SPEKE omite todos los demás ajustes ContentKeyUsageRule.

  • SPEKE omite la funcionalidad UpdateHistoryItemList. Si la lista está presente en la respuesta, SPEKE la omite.

  • SPEKE admite la rotación de claves. SPEKE utiliza únicamente el `ContentKeyPeriod@index para realizar un seguimiento del período clave.

  • Para admitir MSS PlayReady, SPEKE usa un parámetro personalizado debajo de la DRMSystem etiqueta,. SPEKE:ProtectionHeader

  • En el empaquetado HLS, si URIExtXKey está presente en la respuesta, debe contener todos los datos que se van a agregar en el parámetro de la etiqueta EXT-X-KEY del URI como una lista de reproducción de HLS, sin ningún otro requisito de señalización.

  • En la lista de reproducción de HLS, en la etiqueta DRMSystem, SPEKE proporciona los parámetros personalizados opcionales speke:KeyFormat y speke:KeyFormatVersions para los valores de los parámetros KEYFORMAT y KEYFORMATVERSIONS de la etiqueta EXT-X-KEY.

    El vector de inicialización (IV) de HLS siempre sigue el número de segmentos a menos que el operador lo especifique de forma explícita.

  • Al solicitar claves, el encriptador puede utilizar el atributo @explicitIV opcional en el elemento ContentKey. El proveedor de claves puede responder con un IV mediante @explicitIV, aunque el atributo no esté incluido en la solicitud.

  • El encriptador crea el identificador de la clave (KID), que es el mismo para cualquier ID de contenido y periodo de clave especificados. El proveedor de claves incluye el KID en la respuesta al documento de solicitud.

  • El proveedor de claves podría incluir un valor para el encabezado de respuesta de Speke-User-Agent a fin de que se identifique con fines de depuración.

  • Actualmente, SPEKE no admite varios seguimientos o claves por contenido.

    El encriptador compatible con SPEKE actúa como cliente y envía operaciones POST al punto de conexión del proveedor de claves. El encriptador podría enviar una solicitud heartbeat periódica para asegurarse de que la conexión entre el encriptador y el punto de conexión del proveedor de claves está en buen estado.