Communications and Network, 2010, 2, 230-234
doi:10.4236/cn.2010.24033 Published Online November 2010 (http://www.SciRP.org/journal/cn)
A Novel Digital Rights Management Scheme in
P2P Networks
Jing Feng, Ruoshan Kong, Yulin Wang
International School of Software, Wuhan University, Wuhan, China
Received November 12, 2010; revised November 15, 2010; accepted November 16, 2010
Abstract
P2P networking is a distributed application architecture that partitions tasks or workloads between peers.
How to integrate P2P networks and DRM to offer a novel content distribution mode for digital media re-
sources is a significant research project. In this paper, a novel DRM architecture in P2P Networks is pro-
posed, three phases include content provide phase, content purchase phase and content access phase, are
modeled, and key technologies are introduced. Finally analysis indicates that the proposed scheme has the
characteristics of security, controllability and scalability.
Keywords: Peer-to-peer (P2P), Digital Rights Management (DRM), Intellectual Property (IP)
1. Introduction
Peer-to-peer (P2P) networking is a distributed applica-
tion architecture that partitions tasks or workloads be-
tween peers [1]. The rise of P2P networks has been an
inevitable outgrowth of the rise of the Internet. Unfortu-
nately, P2P networks have grown from useful tools in
information sharing to havens for trafficking in unau-
thorized copies of Intellectual Property (IP) [2]. The
widespread application of P2P file sharing brings about
some critical problems, such as security and piracy. How
to protect IP in such P2P networks has become an urgent
problem.
Digital rights management (DRM) is a term for access
control technologies that can be used by hardware manu-
facturers, publishers, copyright holders and individuals
to limit the usage of digital content and devices [3].
There are a number of DRM solutions on the market,
such as Microsoft’s Windows Media Rights Manager
(WMRM), IBM’s Electron ic Med ia Mana ge ment System
(EMMS), InterTrust’s Rights System, and RealNet-
works’s RealSystems Media Commerce Suite (RMCS)
[4]. However, there are few DRM solutions in P2P net-
works. How to integrate P2P network s and DRM to offer
a novel content distribution mode for digital media re-
sources is a significant research project [5]. By now
some research results have been achieved. In [6], a man-
ageable overlay network architecture with DRM is pro-
posed for live streaming. In [7], an integrated copyright
protection scheme for large-scale content delivery over
the Internet is propo sed. And [8] describes a solutio n for
the problem of copyright infringement in P2P networks
for music sharing, and a P2P protocol that integrates the
functions of identification, tracking, and sharing of music
with those of licensing, monitoring, and payment is pro-
posed.
In this paper, a novel digital rights management
scheme in P2P networks is proposed. The scheme com-
bines the advantages of P2P networks and DRM. The
rest of this paper is organized as follows. The proposed
architecture integrating DRM and P2P networks is in-
troduced in Section 2. In Section 3, key technologies
include file packaging, kernel control and file hiding in
the scheme are described. Finally, the characteristics of
the proposed system are concluded in Section 4.
2.Proposed Architecture
The network architecture of P2P is shown in Figure 1.
There are four kinds of key nodes: (1) Certificate server,
offers two kind of certificate, one for digital content pro-
viders and the other for digital content buyer; (2) Au-
thentic server, stores the user authorizing certificates and
keys, and is responsible to verify user’s identity; (3) In-
dex server, maintain the status and buffer information of
peers. The status information consists of the peers’ iden-
tifying information such as user identification, password,
AC address, and so on; (4) Peers, digital content M

J. FENG ET AL.
231
Index ServerAuthentic Server
Peer
Peer
Peer
Certificate Server
Peers
Figure 1. The DRM architecture in P2P network.
providers or buyers, storing content package, keep con-
necting to index server during the whole alive time.
 CS: certificate server
 AS: authentic server
 IS: index server
 pi: peer i
 HFPi: hardware fingerprint information of
peer i
 UIi: user information of user i
 Ci,j: the content j on peer i
 ij
 Mi,j: the piece of content j offered by peer i
C : the encrypted content j on peer i
 ,ij M : the piece of encryption content j of-
fered by peer i
 Ki: content encryption key for peer i
 i
K
: content decryption key for peer i
There are mainly three phases in the scheme: content
provide phase, content purchase phase and content ac-
cess phase.
2.1.Content Provide Phase
In this system, any content provider needs to register on
CS and then the corresponding certificate of provided
content can be obtained. The certificate includes user
information (such as user identification, password),
hardware fingerprint information (such as CPU identifi-
cation, MAC address, disk serial number, etc.), content
information (such as content size, content type, content
price and etc.) and encryption key. After encrypting and
packaging, the content package can be shared on the peer
of content provider. The basic work flow of content pro-
vide phase is as follows:
Step 1: content provider, suppose Pi, sends a request
to CS for sharing the digital content. The user informa-
tion and hardware fingerprint information of this pro-
vider and content information will be send to CS. CS
offers digital content provider certificate to the peer.
Ki, as (1) show, composed of UIi and HFPi is the ma jor
part of this certificate.
ii
K
UIi

※
H
FP (1)
Step 2: the content will be encrypted using i
K
, as (2)
shown, and then packaged by the P2P client application
to add prefix to the package. The details of packag e pre-
fix will be described in the Section 3. Then the
self-extracting package can be shared by the P2P client
application in.
i
p
,i
encrypt wit
ihK ii
Ci C (2)
2.2. Content Purchase Phase
Any content buyer, suppose i, want to buy content
needs to register on certificate server and downloads
content using certificate by paying with a purchase order.
Then th e list o f the p eer s sha rin g the co nt ent pa ck age c an
be obtain from
pj
I
S. The P2P client application on i
can download complete content package pieces from
these listed peers. The basic work flow of content pur-
chase phase is as follows:
p
Step 1: register on certificate server using user
i
p

232 J. FENG ET AL.
informati on and har d ware fi n ger print informat i on.
Step 2: search the content in the P2P client application
in i. After paying with a purchase order, the list of
peers sharing the content can be obtained from
p
I
S.
Step 3: download content pieces from these peers and
compose them to ,ij
C, as (3) described, w here is set
of peers offer content pieces to. P
i
p

,,
m
ijp Pmji
CM encryptwithK


where ,,
m
decryptwith K
mf mf
MM
(3)
Then, ,ij
C and some control programs are packaged
into self-extracting packag e. At this time i is not only
a buyer, but also a content sharing peer un til the package
is deleted in .
p
i
p
2.3. Content Access Phase
Step 1: double click the self-extracting package, the pro-
grams stored in prefix of package will first be run. ’s
certificate will be verified by
i
p
A
S. If is authorized,
i
p
i
K
can be get from
A
S and the ,ij C can be de-
crypted using (4). Otherwise, unauthorized accessing
message will pop-up to .
i
p
,,
i
decrypt with K
ij ij
CC (4)
Step 2: ,ij , can be opened by the universal applica-
tion associated with file type of .
C
,ij
Step 3: Once finish accessing ,ij C, temporary files
generated by self-extracting package will be cleared.
C
3. Key Technologies
3.1. File Packaging
The main function of the package module (shows in Fig-
ure 2) is to package the encryp ted ciphertext, monitoring
procedures, packing procedures, files and processed hid-
ing drive, monitoring module DLL and API interception
drive together.
3.2. Kernel Control
Client monitoring module is the most important and
complicated module in th is system. It takes charge of the
running state of the third-party applications. And it can
prevent illegal operations such as “copy”, “paste” or
“save as” which may destruct copyrights. Monitoring
module includes three files: monitoring procedure (deci-
pher.exe), mouse/keyboard hook(mousehook.dll), and
API interception drive(driver_hook_ssdt.sys). The basic
flowing is as follows:
Figure 2. Internal structure of the packaged file.
1) After unpacking, monitoring procedure and API in-
terception drive will run automatically. First, monitoring
procedure must obtain the absolute path which leads to
object file, and then pass the path to the API interception
drive. The system uses the “ShellExecute” function to
open the file. This function would ask for the file’s path,
and it can choose the third-party application according to
the file format.
2) Since the API interception drive has the absolute
path, system will monitor all processes that are opening
files at the moment, and check whether their absolute
paths are the same path as the one which monitoring
procedure has transferred already. If they are the same,
the system will return the process ID to the monitoring
procedure.
3) When the monitoring procedure obtains the process
ID of a third-party application, it will use the SetWin-
dowsHookEx API function to hang the object process to
the mouse/keyboard hook. This action will prevent un-
authorized “copy” or “save as”. The detail principle will
be expressed in the next section.
4) After obtaining the process ID of the third-party
application, API interception drive will change the
ZwWriteFile API function to prevent all the “write” op-
eration that the function may operate. This will protect
the content at the drives level. More detail can be found
in the next section.
5) The monitoring procedure will wait the third-party
process until the process stop. Once the process stops,
system will unload the DLL and drives, and delete the
two file folders and all their contents that are generate
when unpackin g occu rs.

J. FENG ET AL.
233
……
Processrecord1
The distance to the next record
Thread count
……
Processrecord2
The distance to the next record
Thread count
……
Processrecord3
The distance to the next record
Thread count
……
……
Changed point
Original point
Figure 3. Modification of processes list.
3.3. Processes Hiding 3.4. Files Hiding
Processes hiding can make use of the Rootkit technology.
When the files are unpacked, system will load a process
hiding drive (driver_hide_proc.sys) to hide the running
monitoring procedure. This can prevent users to check or
end the monitoring process with some tools such as ex-
plorer. Processes hiding module does its job at the drives
level. The details of principle are as follows:
The principle of files hiding module is basically the same
as processes hiding module. To hide files, we can replace
the kernel function of ZwQueryDirectoryFile, or modify
the FileInformationBuffer list.
4. Conclusions
1) When the system obtains the current system proc-
esses list, it will call a kernel function named ZwQuery-
SystemInformation. But if the address of ZwQuerySys-
temInformation in SSDT is changed, the system can call
the NewZwQuerySystemInformation (Detour Function)
driver_hide_proc.sys.
According to the scheme, we can conclude the charac-
teristics of the proposed system as follows:
1) Security: the system security can be carried out
from three aspects including content, user and right. Spe-
cific certificates are defined for specific users.
2) Controllability: it can process transmission control,
post control and access control etc. Certificates are com-
bined with hardware information. The system can take
control of the personal computers that consumers use.
2) The driver_hid e_ pro c.sys sto res th e or iginal ad dr ess
of ZwQuerySystemInformation. NewZwQuerySystem
Information can call the original ZwQuerySystemInfor-
mation function with the original address. 3) Simplicity: consumers can use digital content with-
out installing any other custom software.
3) Call the original function ZwQuerySystemInforma-
tion. Scalability: it can be realized from many aspects such
as the functions, modularization, interfaces and rights
expression language.
4) Because NewZwQuerySystemInformation calls
ZwQuerySystemInformation when th e system is runn ing ,
ZwQuerySystemInformation will return the result to
NewZwQuerySystemInformation, not directly to the
system.
5. Acknowledgements
5) Figure 3 shows that NewZwQuerySystemInforma-
tion function can modify the returned processes list, de-
lete the records of packing process and monitoring proc-
ess, then return the changes list to the system.
This work was supported in part by the National
High-Tech Program “863” of P. R. China under Grant
No. 2009A A01Z41 2.

234 J. FENG ET AL.
6. References
[1] En.wikipedia.org/wiki/Peer-to-peer.
[2] B. Rosenblatt, “Integrating DRM with P2P Networks:
Enabling the Future of Online Content Business Models,”
DRM Watch, Vol. 18, 2003.
[3] En.wikipedia.org/wiki/Digital_rights_management
[4] Q. Liu, R. Safavi-Naini and N. P. Sheppard, “Digital
Rights Management for Content Distribution,” Proceed-
ings of the First Australasian Information Security
Workshop, Vol. 2003, 2003, pp. 49-58.
[5] Y. B. Wang, R. Lv and Z. G. Hong, “A P2P Application
Demonstration System for Resilient Overlay Networks
with Intelligent Nodes Supporting DRM,” Proceedings of
the 2009 International Joint Conference on Computa-
tional Sciences and Optimization, 2009, pp. 336-339.
[6] X. G. Lan, J. R. Xue, L. H. Tian, et al., “A Peer-to-Peer
Architecture for Live Streaming with DRM,” Proceed-
ings of the 6th IEEE Consumer Communications and
Networking Conference, 2009, pp. 1-5.
[7] X. S. Lou, K. H. wang and R. F. Zhou, “Integrated Copy-
right Protection in Peer-to-Peer Networks,” Proceedings
of the 27th International Conference on Distributed Com-
puting System Workshops, 2007, pp. 28-35.
[8] T. Kalker, D. H. J. Epema, P. H. Hartel, et al., “Mu-
sic2Share-Copyright-Compliant Music Sharing in P2P
Systems,” Proceedings of the IEEE, Vol. 92, No. 6, 2004,
pp. 961-970.