Secure interoperable digital content distribution mechanisms in a multi-domain architecture

Abstract

Current DRM systems use the Authorized Domain concept to allow sharing of DRM-enabled multimedia contents across multiple devices. However, some devices in an authorized domain may support only a limited number of DRM systems of the content providers due to their heterogeneous capabilities. Lack of interoperability among DRM systems enforces these devices to stick to a common DRM system which restricts the sharing of different DRM-enabled multimedia contents among them. Most of the current solutions use a translation entity to provide interoperability among different DRM standards with a trust assumption over that entity. This assumption may not assure the content providers that their contents and licenses will be translated and distributed in a secure and legal way. In this paper, we propose a secure interoperable content distribution mechanism for commercial and user generated contents among multiple authorized domains without any trust assumption on the translation entity.

Appendices

Appendix A: Registration process

In the registration process, the Local Domain Manager, Content Providers, Authorized Domain Managers and the End Devices register to the Registration Server (RS) by sending their public-key certificate (PKI) to the Registration Server. The detailed protocols are given below.

1.1 A.1 Registration of a Content Provider (CP)

• 1. CP sends its PKI certificate and its adopted DRM system to the RS.

• 2. After verification of the CP’s authenticity, RS adds its details to a list that shows the available Content Providers and its DRM agents.

1.2 A.2 Registration of Local Domain Manager (LDM) and Authorized Domain Managers (ADM)

For registration of a device that is going to function as an Local Domain Manager or an Authorized Domain Manager, the device has to be TPM-enabled and has a pair of public-key cryptographic keys called $\mathcal{AIK}$ keys generated by the TPM. The LDM/ADM obtains an $\mathcal{AIK}$-certificate which contains its $\mathcal{AIK}$ public key signed by a trusted Certifying Authority.

• 1. TPM sends its $\mathcal{AIK}$-certificate and platform configuration state to the RS.

• 2. RS verifies the authenticity of TPM using $\mathcal{AIK}$-certificate and LDM/ADM device’s trust level using the remote attestation protocol described in Section 2.1.2.

• 3. In the case of LDM after successful verifications, RS installs the DRM agent DRM _LDM in the LDM device and sends an LDM-certificate that contains general description about its services and security properties signed by the RS.

• 4. In the case of ADM after successful authentication, RS installs a DRM agent DRM _ADM in the ADM and sends to the ADM a set of domain credentials (i.e., a unique domain key, a domain certificate consisting of a unique domain ID and the maximum number of devices allowed for that domain, public key of the ADM device etc.) for the domain that the ADM device is going to manage.

1.3 A.3 Registration of an End Device (ED)

An End Device that wants to join an Authorized Domain first registers to the Registration Server as follows.

• 1. ED sends its PKI certificate to the RS.

• 2. RS verifies the authenticity of the ED, stores the credentials of the ED in its database and sends the list of available Authorized Domains and DRM systems to the ED.

• 3. ED selects a DRM system from the list which it can support and informs RS.

• 4. RS installs the selected DRM system in ED.

Appendix B: Multi-domain creation process

The creation of a multi-domain involves the following processes: Local Domain Manager adding to it various Content Providers who are willing to distribute their contents; joining and registration of End Devices to various Authorized Domains. The detailed protocols are given below.

1.1 B.1 Local Domain Manager (LDM) adding a Content Provider (CP)

After the registration, the Local Domain Manager can proceed to add Content Providers who are willing to distribute their contents.

• 1. LDM selects a desired CP from the available list of CPs with the RS.

• 2. RS forwards the LDM to the selected CP for authentication and agreement.

• 3. TPM of LDM sends its $\mathcal{AIK}$ certificate and platform configuration state to the CP.

• 4. CP verifies authenticity of TPM using $\mathcal{AIK}$ certificate and the trust level of the LDM device using the remote attestation protocol described in Section 2.1.2.

• 5. CP sends its PKI certificate to the LDM.

• 6. LDM verifies the authenticity of the CP.

• 7. After successful mutual authentication, CP grants its approval and sends its specific DRM rules and mechanisms to the LDM securely.

• 8. LDM’s Content Provider Support Module stores the DRM rules and mechanisms of that CP.

• 9. LDM repeats steps 1–8 for all the CPs for which it wants to do content negotiation.

1.2 B.2 End Device (ED) joining an Authorized Domain

• 1. ED selects a desired ADM from the available ADM list and sends the request to the RS to join that domain.

• 2. RS approves the request and sends a digitally signed user certificate which contains the information of the device and its owner, the public key of the device and the approval from RS to the device.

• 3. ED forwards the certificate and request for joining the domain to the ADM.

• 4. After verification of the certificate, if the device satisfies the rules of that domain, ADM approves the device as a domain member and stores the certificate in its database.

• 5. ADM sends a domain user certificate and a domain key to the device.

• 6. ADM updates its domain device list and sends the list to the RS and all the current domain members.

Appendix C: Multi-domain modification process

A multi-domain gets modified when one of the following happens:

• an End Device joins/leaves/removed from an Authorized Domain;

• an End Device gets transferred from the Authorized Domain AD _cur to the Authorized Domain AD _new ;

• a Content Provider leaves/joins the multi-domain.

We describe in detail the protocols for the following three cases. The other cases are repetitions of earlier protocols given in the section.

1.1 C.1 Leaving/removing of an End Device (ED) from a Authorized Domain

When an End Device wants to leave its Authorized Domain, it sends a digitally signed Leave Domain Request to Authorized Domain Manager (ADM). When an End Device belonging to an Authorized Domain is found to be violating the U-License for any content, Registration Server will request the corresponding Authorized Domain Manager to remove the device from the domain. Registration Server then adds the device identity to the list of revoked devices. The remaining of the protocols in both cases are the following.

• 1. ADM verifies the request, approves the request and removes the certificate of ED from the database.

• 2. ADM updates its domain device list and sends the list to the RS and all the current domain members.

• 3. ADM updates the domain keys and sends the updated keys to the members of the domain.

1.2 C.2 Transferring an End Device (ED) between Authorized Domains

There are some situations in which an End Device has to be transferred from an Authorized Domain AD _cur to another domain AD _new . In OMA DRM [17], transferring of devices across Authorized Domains requires to execute a leave domain and a join domain protocols which is inefficient and requires more network resources. In our case, the device need not have to again get authenticated by the Registration Server. Instead of executing the join and leave domain protocols, the device can be directly transfered to AD _new with a simpler transfer domain protocol. Devices can check the free slot availability of any AD _new with the Registration Server and can send the request of transferring to the Authorized Domain Manager of AD _cur . We will denote the Authorized Domain Manager of AD _cur as ADM _cur and the Authorized Domain Manager of AD _new as ADM _new . The protocol for transferring an End Device from AD _cur to AD _new is as follows.

• 1. ED sends a digitally signed Transfer Domain Request to ADM _cur .

• 2. ADM _cur verifies the request, attests the state of ED and approves the request. It sends to ED a digitally signed Transfer Certificate showing the device’s attestation status and the eligibility to join another domain.

• 3. ADM _cur removes the domain user certificate of ED from the database.

• 4. ADM _cur updates its domain device list and sends the list to the RS and all the current domain members.

• 5. ADM _cur updates the domain keys and sends the updated key to domain member devices.

• 6. ED sends the Transfer Certificate to the ADM _new .

• 7. ADM _new verifies the Transfer Certificate and generates a domain user certificate and sends along with the domain key to the device.

• 8. ADM _new updates its domain device list and sends the updated list to RS and all the domain members.