A Tool Pack Mechanism for DRM Interoperability
Jeho Nam2007, ETRI Journal
visibility
…
description
3 pages
link
1 file
⎯As the number of digital content service providers increases, a variety of digital rights management (DRM) systems appear without supporting interoperability. The lack of interoperability in DRM systems causes inconvenience to customers, especially when they want to play content through multiple devices manufactured by different vendors. In this letter, we propose a novel method to support interoperability between different DRM systems. The proposed technique aims to build an open framework structure which satisfies DRM vendors' requirements by enhancing the security of intellectual property management and the protection tools.
Related papers
Interoperable DRM Framework for Multiple Devices Environment
ETRI Journal, 2008
As networks increase and cross-convergence occurs between various types of devices and communications, there is an increasing demand for interoperable service in the business environment and from end users. In this paper, we investigate interoperability issues in the digital rights management (DRM) and present a practical framework to support interoperability in environments with multiple devices. The proposed architecture enables end users to consume digital content on all their devices without awareness of the underlying DRM schemes or technologies. It also enables DRM service providers to achieve interoperability without costly modification of their DRM schemes.
DRM Convergence: Interoperability between DRM Systems
2009
The vision of the multimedia world is that digital content can be freely shared and moved between all kinds of devices. This would be possible for both, unprotected and protected contents. Currently, various Digital Rights Management (DRM) systems are used to control access on the protected content. The most famous examples include Apple Fairplay, Windows Media DRM, Open Mobile Alliance (OMA) DRM, and Marlin DRM. The protected content format, license management, and trust management differs from one DRM system to another. Therefore, it is necessary to mediate those differences to make DRM systems interoperable. The aim of this thesis is to investigate the approaches for DRM interoperability. Each DRM system has its own Public Key Infrastructure (PKI) domain to manage the trust between different entities like devices and license servers. However, if the entities belong to two similar DRM systems but each having different trust anchor then there is a need of trust establishment that can be achieved through Interoperability in PKI. After analysis of the requirements and studying existing solutions like OMArlin and Coral, a new concept of Generic Interoperability Solution is proposed to achieve the interoperability between different DRM systems. The proposed solution does not require changes to the implementations at the device end. Instead, it introduces a new entity named Content Format Translation (CFT) that communicates with license servers in both DRM systems. A CFT may be a Web service or a device in the home environment to transfer the translated content from one device to another. Moreover, the proposed solution also requires the interaction between both license servers to move the rights from one DRM system to another. This interaction is accomplished through interoperability in PKI.
DRM interoperability and reusability through a generic software architecture
… Consumer and User …, 2006
The domain of digital rights management (DRM) is currently lacking a generic software architecture that supports interoperability between and reuse of specific DRM technologies. This lack of architectural support is a serious drawback in light of the rapid evolution of a complex domain like ...
Towards a software architecture for DRM
Proceedings of the 5th ACM workshop on Digital rights management - DRM '05, 2005
The domain of digital rights management (DRM) is currently lacking a generic architecture that supports interoperability and reuse of specific DRM technologies. This lack of architectural support is a serious drawback in light of the rapid evolution of a complex domain like DRM. It is highly unlikely that a single DRM technology or standard will be able to support the diversity of devices, users, platforms, and media, or the wide variety of system requirements concerning security, flexibility, and efficiency. This paper analyses state-of-the-art DRM technologies and extracts from them high level usage scenarios according to content consumers, producers, and publishers. In addition, the key services are identified both from a functional and security perspective.
Interoperability mechanisms for registration and authentication on different open DRM platforms
IJCSNS, 2006
A novel approach to DRM systems
Modern Digital Rights Management (DRM) systems are often developed as web software platforms designed as service oriented architectures composed of a federation of coordinated web entities that play distinct roles and dynamically interact within a trusted environment. Such a design approach requires that trustu relationships have to be dynamically established across multiple and heterogeneous organizational boundaries so as to facilitate an ``on-the-fly'' resource sharing. This introduces non-trivial security architectural requirements concerning with the mechanisms that allow different security realms of web entities to be federated. This paper presents a DRM system developed as a web software platform designed to give a specific support both to the interaction of the web entities involved in the platform and to the development of the trusted relationships among them, in a much more flexible way than before, dynamically and with minimal overheads and shared infrastructure.
PKI AS A WAY TO LEVERAGE DRM INTEROPERABILITY
2007
ABSTRACT Managing fair content access to digital objects in a digital World is a hard task. This task involves, among other things, the capability to manage a large number of users/actors, devices and software components allied to the capacity to establish trust relationships and trust environments between them. To establish this trust environment, digital object rights management solutions often implement their own specific security services that are, most of the times, not compatible between them.
Open DRM and the Future of Media
IEEE Multimedia, 2008
Looking at modern Information and Communication Technologies and at the variety of devices and gadgets with the potential to exchange information and share functionalities, we consider that interoperability is in fact a killer functionality. However, interoperability is not always easy to achieve. A clear example of such complexity is the lack of interoperability between Digital Rights Management (DRM) systems. The authors strongly believe that the road to DRM interoperability has to pass through the definition of open platforms, that is, those containing open and defined interfaces to allow the exchange of the necessary data to interoperate, as opposed to other more closed and obscure solutions. In this paper, we analyze some of the currently available DRM architectures, focusing on those who provide open-source, open-specifications or open-interfaces, and identifying their functional modules. We also provide some hints on how those platforms could interoperate.
A Service-Oriented Framework to Promote Interoperability Among DRM Systems
2006
Through the past years, several digital rights management (DRM) solutions for controlled dissemination of digital information have been developed using cryptography and other technologies. Within so many different solutions, however, interoperability problems arise, which increase the interest on integrated design and management of these technologies. Pursuing these goals, this paper presents a framework which aims at promoting interoperability among DRM systems, using a serviceoriented architecture (SOA) and a high-level policy modeling approach.
Икона святых Петра и Павла из Белозерска XIII в. в контексте византийской иконографии верховных апостолов
Труды ГЭ. Т. 121: Византия в контексте мировой культуры: материалы научной конференции памяти А. В. Банк (1906–1984). 11–14 октября 2022 г. СПб. ГЭ. С. 44–62; 382–383; 413–414, 2024
Despite far from perfect condition of the icon of the Holy Apostles Peter and Paul in the same-name cathedral in Belozersk, the initial composition of the image can be established with sufficient confidence. Although the composition may appear traditional, the icon (created by a Novgorodian artist in the 1220s) has no analogues in either the earlier history of icon painting or the Byzantine iconography of Apostles Peter and Paul. Paired full-length images of saints (brothers or saints of comparable rank) chosen for similar reasons of veneration were traditionally represented en face. This rule, however, never applied to depictions of the two preeminent apostles, who appear facing each other in religious images of various types; this practice has remained consistent across the history of Eastern Christian art from its earliest period. In some cases this manner of representation may be explained by the fact that the apostles often flanked the blessing Christ, who was shown standing between them; however, the same alignment of the apostles’ figures also featured in all other сompositional contexts. In our opinion, this visual arrangement originated from the ancient traditio legis motif, which represented Saints Peter and Paul as founders of the Church: the apostles were depicted bending to Jesus Christ and receiving from his hands the Law symbolised by a book (traditio legis) and keys (traditio clavium). The apostles’ poses became part of the visual tradition as vestiges of this early motif which gradually disappeared from the iconographical repertory. Until the Late Mediaeval period, the Belozersk icon remained a unique exception among the many representations of Saints Peter and Paul, reflecting the quest for new art imagery by thirteenth-century Russian masters.
A Tool Pack Mechanism for DRM Interoperability
Bumsuk Choi, Youngbae Byun, Jeho Nam, and Jinwoo Hong
ABSTRACT⎯As the number of digital content service
providers increases, a variety of digital rights management
(DRM) systems appear without supporting interoperability.
The lack of interoperability in DRM systems causes
inconvenience to customers, especially when they want to play
content through multiple devices manufactured by different
vendors. In this letter, we propose a novel method to support
interoperability between different DRM systems. The proposed
technique aims to build an open framework structure which
satisfies DRM vendors’ requirements by enhancing the security
of intellectual property management and the protection tools.
Keywords⎯Digital rights management (DRM), IPMP,
MPEG, security, interoperability.
I. Introduction
Many digital rights management (DRM) standard
organizations have been founded to support interoperability since
2000. Intellectual property management and protection (IPMP)
is a representative DRM architecture developed by MPEG for
interoperable and flexible distribution of multimedia content
between different user terminals and different content providers.
The basic idea of MPEG-2/4 IPMPX [1], [2] is to make each
DRM function as an object module. This object module, called
an IPMP tool, provides content protection functions, such as
authentication, encryption, and watermarking. It defines an
IPMP terminal which manages IPMP tools and controls a player.
Interoperability is achieved by standardizing the interface
between an IPMP terminal and an IPMP tool and also between
the IPMP tools. The format of the signaling information that
indicates which IPMP tools are applied to the content has also
Manuscript received Sept. 20, 2006; revised Mar. 20, 2007.
This work was supported by the IT R&D program of MIC/IITA [2005-S-403-02, SmarTV
Technology and 2007-S-003-01 Development of Protection Technology for Terrestrial DTV
Program].
Bumsuk Choi (phone: + 82 42 860 1574, email: [email protected]), Youngbae Byun (email:
[email protected]), Jeho Nam (email: [email protected]), and Jinwoo Hong (email:
[email protected]) are with the Radio & Broadcasting Research Division, ETRI, Daejeon, S.
Korea.
ETRI Journal, Volume 29, Number 4, August 2007
been standardized. This solution can be called the single IPMP
tool solution. Ideally, it is a very reasonable method to achieve
interoperability. Realistically, it is unlikely for DRM vendors to
accept this standard. This is true for the following reasons.
1) The security of the IPMP tool itself is very critical for the
protection of content. Therefore, it is unlikely for DRM
vendors to reveal their private IPMP tools.
2) The information about the IPMP tools should be written
publicly in the associated content. This may be used in
malicious attacks and threaten the DRM system.
3) A DRM system is composed of many kinds of IPMP tools
and operates through interactions among them. It is easy to
infer what kind of process is performed in the DRM
system by analyzing interchanging messages. The DRM
vendors are not willing to expose these interactions to
unreliable devices.
4) When a developed IPMP tool has totally new functions
and protocols, a new set of standardized interface messages
needs to be defined. This causes a conventional IPMP
terminal to be changed considerably.
To solve these problems, we propose an advanced method
we call the tool pack solution which supports interoperability
between different DRM systems.
II. Proposed DRM Architecture
Most DRM vendors have a dedicated set of IPMP tools and
are reluctant to separate them into individual tools. The
rationale behind the tool pack is to bind the private IPMP tools
as a tool group and establish a tool agent to operate the tools in
the tool group [3]. Figure 1 shows the internal structure and
interface of the tool pack.
A tool pack is defined as a structure containing the tool agent
and the tool group, so DRM vendors can provide their private
tools in the tool group with the tool agent in the tool pack
structure. The tool agent communicates with the IPMP
Bumsuk Choi et al.
539
terminal. The tool agent operates the tools in the tool group in a
proprietary way, so it is not necessary to define common
interface messages for the communications between the tool
agent and the tool group. As shown in Fig. 1, common
interface messages are needed only for minimal
communications between the tool agent and the IPMP terminal.
Compared with the single IPMP tool solution, the tool pack
solution makes it possible to hide detailed operational
information from the IPMP terminal and reduces the number
of standard interface messages. Additionally, it increases the
extensibility because a reduced set of interface messages is
enough for the operation of any future tool pack.
The tool pack solution is composed of several technical
items such as the IPMP terminal, the tool pack structure, and
interface messages.
IPMP Terminal
Common
interface
message
ToolAgent
ToolAgent
ToolAgent
ToolAgent
Internal
message
Internal
message
Internal
message
Internal
message
ToolGroup
ToolGroup
ToolGroup
ToolGroup
ToolPack 1
ToolPack 2
ToolPack 3
ToolPack n
Fig. 1. Structure and interface of a tool pack.
1. IPMP Terminal for Tool Pack
An IPMP terminal is a module within a device which
executes DRM-related functions in a trusted fashion. The
IPMP terminal extracts DRM information, the tool pack, keys,
and license from the content. The IPMP terminal also controls
the critical points internal to a device. Such a control point is a
specific position where the IPMP tools may operate along the
content decoding pipelines.
The IPMP terminal, using the DRM information, locates the
required tool pack and instantiates the tool agent. Once instantiated,
the IPMP terminal handles initialization, authentication, and
supervision of the tool agent using IPMP messages. The IPMP
messages are usually generated by the IPMP terminal or the tool
agent during decoding time. However, in some cases, they may be
delivered in the DRM information in the content (for example,
periodically changed key data may be delivered to a device in a
DRM message). In this case, it is a role of the IPMP terminal to
extract the IPMP messages and deliver them to the tool agent.
When a missing tool pack is found, the IPMP terminal obtains the
missing tool pack from a remote server. Once used, all tool packs
540
Bumsuk Choi et al.
are kept in the secure storage of the device.
2. Tool Pack Structure
A tool pack structure, as a container for the tool agent and the
tool group, is represented by the following schema shown in
Fig. 2. Each element is defined by the following semantics.
ToolPackID contains a unique identification.
Pack contains a unit of tool pack. Each tool pack unit exists
for its target device. Multiple packs can be conveyed in the tool
pack structure in case the DRM vendor wants to support more
than one device environment.
DeviceInformation contains H/W or S/W (including OS)
information of the target device which the tool agent and the
tool group can operate on.
ToolAgent contains sub-elements for tool agent.
ToolGroup contains sub-elements for tool group.
ToolPackageType indicates the details of the package of the
binary code. Examples are CAB or a Winzip.
ToolAgentBody contains binary code of tool agent.
ToolGroupBody contains binary code of IPMP tool.
Signature contains a digital signature for the authenticity.
The tool pack data conveys information for initialization of
the tool agent such as parameter values or flags. The tool pack
data can be delivered together with the tool pack or can be
delivered separately.
ToolPackRefID contains reference identification of the tool
pack. It indicates the matching tool pack needed for the tool
pack data.
OpaqueData contains information for initializing the tool
agent. The data form is dedicated to a specific tool agent.
Therefore, only a proper tool agent can recognize it and use this
information.
Signature contains a digital signature for authenticity.
3. APIs for Tool Pack
Once the IPMP terminal and the tool agent are instantiated in
a device, they communicate with each other using interface
messages [4].
InitialAuthenticationAndMutualAuthentication: The IPMP
terminal and the tool agent authenticate each other and make a
secure channel to transfer data. These messages are referenced
from MPEG-2/4 IPMPX specification.
GetToolGroupReference: The tool agent can optionally use
a private library containing algorithms such as encryption or
watermarking. In this case the tool agent requests the reference
of the tool group from the IPMP terminal.
SendToolGroupReference: The IPMP terminal retrieves
the tool group from the tool pack structure and sends the
reference of the tool group to the tool agent.
ETRI Journal, Volume 29, Number 4, August 2007
dmp2rtb: ToolPackType
dmp2rtb: ToolPackID
dmp2rtb: PackType
dmp2rdi: Devicelnformation
+
dmp2rtb: ToolAgentType
dmp2rtb: ToolPackageType
dmp2rtb: ToolAgent
–
–
dmp2rtb: ToolAgentBody
dsig:Signature
ToolPack
–
–
dmp2rtb: Pack
–
+
–
dmp2rtb: ToolGroup Type
1..∞
dmp2rtb: ToolPackageType
dmp2rtb: ToolGroup
–
–
dmp2rtb: ToolGroupBody
dsig:Signature
dsig:Signature
dsig:Signature
+
+
+
Fig. 2. Schema structure of a tool pack.
GetToolReference: The tool agent may need a single IPMP
tool. The single IPMP tool is a popular and stand-alone IPMP
tool used by many DRM systems where the tool agent needs
more than one single IPMP Tool.
SendToolReference: The IPMP terminal sends the reference
of the single IPMP tool to the tool agent.
GetToolPackData: The tool agent can be implemented to
be always called with the same initial state. Alternatively, the
tool agent may be implemented to be called with an initial
value that changes whenever it is called or with an initial value
downloaded from, for example, an external authorized tool
server to provide more enhanced security.
SendToolPackData: The IPMP terminal retrieves the tool
pack data and sends it to the tool agent.
GetControlPointList: The tool agent requests the control
point list to connect each tool to a control point.
SendControlPointList: The IPMP terminal sends the list of
control points available in the device. This message contains
the number of control points and a set of information including
the control point ID and the location information so that an
IPMP tool can be connected. The control point list is extended
from the MPEG-2/4 IPMPX. For the tool pack mechanism, we
defined additional control points as those before storing, before
playing, and before transferring.
CanProcess: When the initialization, authentication, and
connection processes are successful, the IPMP terminal is
notified that the tool agent is ready to decode content.
DisconnectToolPack: The IPMP terminal commands the
ETRI Journal, Volume 29, Number 4, August 2007
tool agent to disconnect tools from the control point and stop
the processing.
NotifyToolPackEvent: The tool agent notifies the IPMP
terminal that an event occurred during the initialization process
or decoding process. The IPMP terminal performs the proper
action according to the type of the event.
III. Conclusion
In this paper, we presented an advanced interoperable DRM
method. The distinctive feature of the proposed method is that
it is based on an open framework structure, yet it satisfies the
DRM vendors’ requirements by enhancing the security of
IPMP tools. To achieve this, we introduced a tool pack
mechanism which allows users to keep the critical information
on the operation of IPMP tools away from the outer entities.
References
[1] ISO/IEC 13818-1, Information Technology: Generic Coding of
Moving Pictures and Associated Audio Information, Part 11: IPMP on
MPEG-2 Systems, May 2002.
[2] ISO/IEC 14496-13, Information Technology: Coding of Audio-Visual
Objects, Part 13: Intellectual Property, May 2002.
[3] Digital Media Project; Approved Document No. 2 – Technical
Reference: Architecture; 2005/04, www.dmpf.org/
[4] Digital Media Project; Approved Document No. 3 – Technical
Specification: Interoperable DRM Platform; 2005/04, www.dmpf.org/
Bumsuk Choi et al.
541
Related papers
Can Jews Be Antisemitic? – The Case of Neturei Karta’s Extreme Orthodox Anti-Zionist and Anti-Israel Ideology
Antisemitism in Hungary: Appearance and reality, 2023
Anti-Nutrition Fallacies and Inconsistencies in Politics and Medicine in the Era of Pandemic Vitamin D3 Deficiency and Nutri-Immunosuppression (in press)
IJHNFM: International Journal of Human Nutrition and Functional Medicine (ISSN 2378-4881), 2021
War veterans and the transnational origins of Italian Fascism (1917–1919)
Journal of Modern Italian Studies, 2016
Die metaphorische Konstruktion psychischer Krisen und Extremzustände: Entwertungen, versteckte Normalitätskonstruktionen und offene Horizonte
Zeitschrift für Disability Studies, 2024
Fenomenología y marxismo en la obra de Herbert Marcuse
Ideas Y Valores, 1980
Second Language Writing Instruction
In H. Mohebbi & C. Coombe (eds.) Research Questions in Language Education and Applied Linguistics: A Reference Guide. Bern: Springer , 2022
ELEMENTARY SCHOOL TEACHERS' PERCEPTIONS CONCERNING THE INTEGRATION OF MUSIC INTO THE MATHEMATICS TEACHING
ELEMENTARY SCHOOL TEACHERS PERCEPTIONS CONCERNING THE INTEGRATION OF MUSIC AND MATHEMATICS , 2021
Characteristics of effective telephone counselling skills
British Journal of Guidance & Counselling, 1997
Homza Some Glorious and Less Glorious Primacies of the Students
‘ANNUS MIRABILIS’ 1989 AND SLOVAKIA: FROM A TOTALITARIAN REGIME TO DEMOCRACY, 2021
Planet Hunters. VII. Discovery of a New Low-Mass, Low-Density Planet (PH3 C) Orbiting KEPLER-289 with Mass Measurements of Two Additional Planets (PH3 B and D)
The Astrophysical Journal, 2014
Quality of learning community and presentations task: investigating student’s discourse of the celestial objects coordinates in astronomy to construct scientific reasoning
Journal of Physics: Conference Series, 2019
Inside-out Pedagogy": Theorising Pedagogical Transformation through Teaching Philosophy
Australian Journal of Teacher Education, 2014
La atención psiquiátrica a las residencias de ancianos dependientes de los servicios sociales
Zerbitzuan Gizarte Zerbitzuetarako Aldizkaria Revista De Servicios Sociales, 1992
Incorporating Guided-Inquiry Learning into the Organic Chemistry Laboratory
Journal of Chemical Education, 2007
The differential regulation of Smad7 in kidney tubule cells by connective tissue growth factor and transforming growth factor-beta1
Nephrology, 2007
Redistribution in Public Project Problems via Neural Networks
IEEE/WIC/ACM International Conference on Web Intelligence