PDCF Header Key Acquisition for Smartcard Broadcast Terminals
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Receiving terminals supporting only the smartcard profile cannot record and store broadcast contents transmitted using transmitting-end encryption protocols like IPSec and SRTP, as they cannot generate or include the necessary encryption keys in the recorded files, limiting their ability to share or reproduce encrypted content.
Innovation Solution
A method that encrypts broadcast content with a Content Item Encryption Key (CIEK) and includes acquisition information for second and third encryption keys in the header of the recorded file, allowing terminals with both DRM and smartcard profiles to record and store content using a Packetized DRM Content Format (PDCF), enabling key acquisition and decryption.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If receiving terminals use only smartcard profile for encryption key management, then the terminal structure remains simple and cost-effective, but the terminal cannot record and store broadcast contents transmitted using transmitting-end encryption protocols like IPSec and SRTP
Solution Approach 1:
The patent introduces an intermediary mechanism by storing acquisition information (URL, key identifier, timestamp) in the PDCF file header that mediates between the smartcard profile terminal and the transmitting-end encryption protocol. This intermediary information enables the terminal to obtain necessary encryption keys from external servers without requiring built-in DRM engine capabilities, thus resolving the contradiction between maintaining simple terminal structure and achieving protocol compatibility.
Solution Approach 2:
The patent applies preliminary action by pre-storing acquisition information for encryption keys in the PDCF file header during the recording process. This preliminary inclusion of key acquisition data enables smartcard profile terminals to later retrieve and use the necessary keys for decryption, allowing them to handle transmitting-end encryption protocols without requiring complex pre-configured key management systems.
2Adaptability or versatility
If receiving terminals include DRM engine to support transmitting-end encryption protocols, then the terminal can record and store encrypted broadcast contents, but the terminal structure becomes complex and costly
Solution Approach 1:
The patent extracts the complex DRM engine functionality from the terminal device and relocates it to external servers. By doing so, the terminal only needs to store acquisition information in the PDCF header and retrieve keys externally, rather than implementing full DRM capabilities locally. This extraction resolves the contradiction by maintaining recording capability while reducing terminal complexity.
Solution Approach 2:
The patent uses the PDCF file header as an intermediary structure that contains acquisition information for encryption keys. This intermediary mechanism allows smartcard profile terminals to access transmitting-end encrypted content without requiring built-in DRM engines, as the header provides the necessary information to retrieve keys from external sources, thus resolving the contradiction between functionality and complexity.
3Ease of operation
If smartcard profile terminals cannot generate encryption keys for PDCF files, then the key management remains secure and standardized, but the terminals cannot share or reproduce encrypted broadcast content
Solution Approach 1:
The patent introduces an intermediary solution by storing acquisition information (URL, key identifier, timestamp) in the PDCF file header. This intermediary mechanism enables smartcard profile terminals to obtain necessary encryption keys from external servers without requiring local key generation capabilities, thus resolving the contradiction between maintaining secure standardized key management and enabling content sharing.
Solution Approach 2:
The patent applies preliminary action by pre-storing acquisition information for encryption keys in the PDCF file header during content recording. This preliminary inclusion of key acquisition data enables smartcard profile terminals to later retrieve and use the necessary keys for content reproduction and sharing, without requiring complex local key generation capabilities.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
Disclosed is a method of recording and storing a broadcast content received for mobile broadcast services in a transmitting-end level. A broadcast receiving terminal includes a type of the key profile in the header of the recorded file for the particular broadcast content, the CIEK which is used in encrypting the broadcast content and encrypted with the second layer encryption key, and the acquisition information on the second layer encryption keyThe acquisition information on the second layer encryption key is included in a corresponding field of the header according to the type of the used profile. As in the SRTP and IPSec, a recorded file format in the transmitting-end level recording is the PDCF. Information associated with the encryption of the encrypted broadcast content is stored in the OMA DRM common header box (ohdr box) of the PDCF recorded file.