INVESTIGATION OF A KERNEL LEVEL DRM IMPLEMENTATION by gyvwpsjkko

VIEWS: 6 PAGES: 15

									INVESTIGATION OF A KERNEL LEVEL DRM
          IMPLEMENTATION

   Alapan Arnab, Duncan Bennett, Marlon Paulse and Andrew Hutchison

                      {aarnab, dbennett, mpaulse, hutch}@cs.uct.ac.za
                            Data Networks Architectures Group
                             Department of Computer Science
                                 University of Cape Town
                                       Rondebosch
                                           7701

                                            Abstract

    In this paper we discuss our experiences in implementing an operating system level DRM con-
troller based on the GNU-Linux kernel. This paper investigates the feasibility of creating a trans-
parent, application independent DRM controller and the performance implications thereof. Our
investigation has revealed, that while a number of access control rules can be enforced transpar-
ently at the operating system level, there are also a number of rules that require application level
enforcement. Thus, we recommend separation of rights to two levels of enforcement to take advan-
tage of transparent enforcement at the kernel level. Our performance analysis shows promise with
no wall time impact. However, there is still a significant performance impact and improvements
are necessary if DRM controllers are to be deployed in multi-user, high-load environments like file
servers.
     INVESTIGATION OF A KERNEL LEVEL DRM
               IMPLEMENTATION

                                                 Abstract

         In this paper we discuss our experiences in implementing an operating system level DRM con-
     troller based on the GNU-Linux kernel. This paper investigates the feasibility of creating a trans-
     parent, application independent DRM controller and the performance implications thereof. Our
     investigation has revealed, that while a number of access control rules can be enforced transpar-
     ently at the operating system level, there are also a number of rules that require application level
     enforcement. Thus, we recommend separation of rights to two levels of enforcement to take advan-
     tage of transparent enforcement at the kernel level. Our performance analysis shows promise with
     no wall time impact. However, there is still a significant performance impact and improvements
     are necessary if DRM controllers are to be deployed in multi-user, high-load environments like file
     servers.



1     Introduction
Protection of confidential data has been a problem since ancient times. Protection of data has always
hinged on two important factors - keeping the data a secret and trusting the people who have access
to the secret. Since the time of Julius Caesar, secrecy has been achieved through various encryption
schemes, which over time have become better and better, to the extent that current computing power
will not be able to break a strongly encrypted message in usable time. However the issue of trust has
not been resolved and, intentionally or unintentionally, holders of secret information can do what they
want to do with the secret information.

Digital Rights Management DRM systems attempt to provide “persistent access control ” [14] by
restricting what end-users can do with digital data. DRM protected data have use licenses associated
with them which provide the access control rules for the data, and a DRM controller interprets and
implements these access control rules.

DRM has been promoted as a solution to combat music piracy, but the principles can easily be
extended to a generalised data security solution. The usefulness of DRM as a general security solution
will thus depend on the ease of supporting and integrating with existing computer systems, which in
turn depends on the implementation of the DRM controller.

The DRM controller can be implemented in three layers of the computer system – the application layer,
the operating system layer and the hardware layer – and DRM systems exist on all three levels [3].
At the application layer, solutions such as Apple’s iTunes Music service or Adobe Secure PDF require
the use of proprietary formats and protocols and are often application specific. Thus the solutions
are usually not portable and provide limited functionality [9, 6]. At the operating system layer, there
is currently only one well known solution – Microsoft’s Rights Management Services (RMS) – which
still requires a tight integration with applications and thus retains many of the disadvantages of the
application layer systems [6]. The operating system layer could however provide a more complete
solution for a DRM controller although some authors, for example Rosenblatt, argue that such a
solution has too much overhead to be effective [13]. At the hardware layer, the potential security
offered by a DRM controller is high and holds great promise. Some, like Rosenblatt [13], believe
that the hardware solution is the real solution for DRM systems. However, current solutions such as
DVD-CSS have been failures; but that is more due to flawed design [7, 9].

In this paper we discuss our experiences with the implementation of an operating system kernel DRM
controller. The solution is part of a wider DRM specification being developed as a generic solution
for DRM [2]. We defined two hypotheses for our investigation into the viability of such a solution:


                                                      1
    1. The prototype kernel level DRM controller can enforce a wide range of digital rights, to a wide
       range of files, transparently to any end-user applications trying to access the DRM protected
       content. [HYP-01]

    2. The performance cost imposed on the system by the prototype kernel level DRM controller is
       negligible. [HYP-02]


In HYP-01 our aim is to create a DRM controller that allows any existing application to access
DRM protected works. For this purpose, there is need for a generic DRM package format that can
accommodate any data, and one such format is defined in [2]. If our hypothesis is successful, it will
significantly reduce the costs involved for the adoption of DRM as a general security solution.

In HYP-02 our aim is to investigate the performance implications of a kernel level DRM solution, in
particular to investigate the claims made by Rosenblatt [13]. It is desirable that a kernel level DRM
controller has minimal performance hits in handling both protected and unprotected data.


2      Related Work
The majority of current DRM systems are implemented at the application level, and as discussed
previously, only one system – Microsoft’s Rights Management Services (RMS) – features a DRM
controller in the operating system kernel. In this section, we detail some of the differences between
RMS and our implementation. We also discuss some previous work criticising DRM controllers for
operating system kernels.

2.1    Microsoft Rights Management Services (RMS)

Microsoft’s RMS is currently the only DRM system that has part of its controller in the operating
system kernel. However, the controller does not provide transparent protection and requires applica-
tions to be “RMS enabled” to interact with protected files [1]. A protected file in a non-RMS enabled
kernel will be seen as an encrypted file and no actions can be performed on it. But, applications
which are not RMS enabled cannot do simple functions such as opening a file even if the application
is running in a RMS enabled kernel [1]. Application level support does have its advantages and RMS
can support a wide range of rights in applications.

Because Microsoft RMS is a proprietary system, not much has been disclosed about its designs, how
the kernel module interacts with the Windows NT kernel and the performance impacts the kernel
module has in relation to the normal Windows NT kernel.

2.2    Criticisms for OS Kernel DRM Controllers

In [12], Reid et al. argue that mainstream operating systems are inappropriate for use as DRM clients.
Mainstream operating systems use Discretionary Access Control (DAC) security policies rather than
Mandatory Access Control (MAC) security policies. A DAC system allows ordinary users of a system
to define their own security. By granting ordinary users this ability, a user could reconfigure the
security policy of the system to subvert the DRM protection. The authors also point out the inability
of mainstream operating systems to support the principle of least privilege. Since system privileges
are based on the users’ identity, any program executing on behalf of a user is granted the same access
control privileges as the user. There are no efficient mechanisms for restricting users’ access control
rights.

Operating system level implementations may also degrade the overall performance of a system. In [13],
Rosenblatt argues that, since an operating system level DRM controller must intercept system call
requests to enforce digital rights, it would need to intercept all such requests. It does not discriminate
between system call requests that need protection and those that do not need protection. This

                                                    2
unnecessary interception of system call requests can impose a large overhead on the system.


3      System Design and Implementation




        Figure 1: Framework for a Componentised Digital Rights Management (DRM) System


In this section, we discuss the design and implementation of a kernel level DRM controller. As discussed
before, the system is part of a complete DRM system framework described in [2]. An overview of
the components involved in the framework is shown in figure 1. Although the user component in
the specifications can interact with almost all the components, the implementation only focused on
the license server and the user controller components. A certificate authority is also present in the
implementation, but there is no interaction between the components.

In [11], Park et al. categorised a variety of DRM systems. These categories depended on two factors
– the type of “control set” or use license used and the distribution mechanism. Since DRM is a form
of persistent access control, the distribution mechanism should not impact the security of the data.
Hence, we did not consider the distribution as a factor. Park et al. discussed three types of control sets
– the fixed control set, where the DRM policies are set with the DRM controller, the embedded control
set, where the DRM policies are combined with the protected data and the external control set where
the DRM policies are separate to the protected data providing maximum flexibility. These distinctions
are also present in the OMA DRM 1.0 specifications and are called Forward Lock, Combined Delivery
and Separate Delivery respectively [10]. Although our design could make use of embedded control
sets, we only implemented and tested protected data with external control sets.

3.1   System Overview

The system implements a DRM controller responsible for enforcing rights protection on an end user
machine. The controller represents part of the user component in the architecture discussed above.
As discussed earlier the aim of the implementation is to create a controller that supports multiple file
formats and is transparent to the applications that access the files. Due to the wide availability of
literature on GNU-Linux kernels and its open source nature we decided to implement the system on
the GNU-Linux operating system, specifically the 2.6.13.4 vanilla kernel with preemptive support1 .
   1
     Preemptive support might not be relevant, but we have not tested to see if there are performance implications of
including preemptive support.



                                                         3
The controller consists of two core modules: an operating system kernel module and a user-space
daemon module. These modules communicate through the use of a device file. The daemon module is
responsible for the management and retrieval of DRM use licenses from the DRM content distributors’
remote license servers, while kernel module enforces the access control rules specified in these use
licenses.

To address the criticisms regarding the principle of least privilege as discussed by Reid et al. [12], we
have decided to implement a different mechanism for identity of end users. Instead of relying on local
machine authentication, we have decided to make use of a certificate based system, which provides a
more global user identity base.

3.2   File Format

One of the often overlooked problems with DRM system interoperability is the file formats used.
In [2], a layered file format that can accommodate different requirements is described. This is shown
in figure 2. The layers represent data that is added or a process that is applied to a previous layer
(for example, metadata is applied to the original data while compression is performed to all the data
combined in lower layers) and can be used in either directions (i.e. to create or to use the protected
data).




                           Figure 2: Layered approach to DRM file formats



In the implementation we followed this layering architecture and the file format is shown in figure 3.
The compressed data contains the protected data with optional security features. For the purposes
of the prototype, we used the MD5 hash as the identifier, but the identifier will fit between the hash
and the compressed data. Due to the focus on viability of kernel level DRM controller and time
constraints, we did not make use of compression or encryption, but we do intend to add these features
in later versions of the prototype and analyse the performance implications thereof. The magic number
gives the file format an unique MIME type identifier allowing the kernel module to identify a DRM
protected file and to ignore non-DRM protected files. This feature greatly enhances the performance
of the DRM controller.

3.3   Rights Expression Language (REL)

RELs are the languages used to express access control rules and thus are one of the cornerstones of
a DRM system. In this implementation we used a scaled down version of the Open Digital Rights
Language (ODRL) with bi-directional extensions as detailed in [4]. This is also the first system
to support negotiation of rights (although admittedly very primitive) for a protected work using a

                                                   4
                                -------------------------------
                                |   Magic Number (2 B)        |
                                -------------------------------
                                |   MD5 Hash (16 B)           |
                                -------------------------------
                                | Encrypted, Compressed Data |
                                -------------------------------

                             Figure 3: File format of the implementation



protocol detailed in [5].

In ODRL, rights are known as permissions and limitations to these permissions are known as con-
straints. Thus a permission like display can have a constraint of count with a value of 5 to restrict
the end user to viewing a file for a maximum of 5 times. For the implementation, we focused on the
following permissions, with the related system calls:


  1. DELETE : unlink

  2. DISPLAY : read

  3. EXECUTE : execve

  4. MODIFY : write

  5. SAVE : write

  6. MOVE : rename


The permissions we implemented reflect a fair percentage of the total permissions expressible in the
standard ODRL data dictionary. However, we only implemented two constraints – COUNT and
DATETIME.
license                      ->   permission+ end
permission                   ->   start_permission type constraint* end
constraint                   ->   start_constraint type argument* constraint* end
argument                     ->   start_argument ID argvalue end
type                         ->   (1-9)+
argvalue                     ->   (1-9a-zA-Z)+
end                          ->   ;
start_permission             ->   !
start_constraint             ->   &
start_argument               ->   @

                            Figure 4: Kernel license format specifications


As discussed by Guth et al. in [8], contract enforcement can be divided into two steps. These are
contract authentication and contract interpretation. Elements relevant to the authentication stage are
not necessarily relevant to the enforcement stage. Guth et al. also present a core set of elements needed
to represent expressions from a range of REL’s. We have taken this set of elements as a starting point
and defined a “kernel license” containing only elements needed for enforcement. The kernel license
consists of two key elements, permissions and constraints (from the ODRL specifications). However
the kernel license format is expressed using plain text rather than XML. In practice, these elements
map to numeric values with plain text arguments. A constraint may map to other elements such as

                                                   5
containers or contexts. Within the kernel license, a constraint serves as an all purpose modifier which
either limits or refines the meaning of its parent element. The basic format of a kernel license is given
in figure 4.

3.4   Kernel-Daemon Interaction

Figure 5 gives an overall view of the process involved in processing a DRM protected file in our
system. The following steps describe the interaction between the kernel module and the daemon.
Communication takes place through the use of a device file.




                  Figure 5: The DRM Controller Architecture and Communications


Step A: The application receives as input a DRM protected file.

Step B: The application requests access to the file. The kernel module intercepts this request.

Step C: The kernel module sends a request for license details to the daemon.

Step D: The daemon checks the license store for a license. If a license exists, the daemon proceeds
     to step G. Otherwise, it proceeds to step E.

Step E: The daemon connects to a license server enabling the negotiation of a license download.

Step F: If a license is successfully negotiated, the daemon proceeds to step G. Otherwise, a message
     is sent to the kernel module to deny file access.

Step G: The validity of the license is checked against a revocation list. If a license is invalid, the
     daemon may return to step E to negotiate a new license.

Step H: The daemon returns the license to the kernel module in the kernel license format. This will
     contain all relevant information from the original license.

Step I: The kernel module performs a final check on the access request. The end-user and the
     request are referenced against the relevant fields in the use license. If these details are valid, the
     application is granted access to the requested file.


3.5   The Daemon

The daemon module implements several components. The responsibilities of the daemon module are
described below.

                                                    6
3.5.1    Management of a License Store

In order to retrieve DRM use licenses for the kernel module, the daemon stores licenses in a local
license store. The daemon manages these licenses, having full rights to add, revoke or modify license
content.

3.5.2    Negotiate Licenses with a License Server

If a license is not available in the license store, the daemon initiates a negotiation for a new license
with a content distributor’s license server. The daemon activates a user interface, and a child process
is started to await a response from the user interface. This frees the main daemon process to continue
communicating with the kernel. Once the negotiation is complete, a message is sent to the child
process. If the message contains a license, the license is added to the license store. The user can then
try to attempt to access the file once more.

3.6     The Kernel Module

The kernel module contains two components: the Access Enforcement Component (AEC) and the
Access Decision Component (ADC). Together these two components act as a reference monitor. All
access requests to DRM protected content must pass through these two components. The ADC makes
decisions on whether to allow access to the DRM content or not, while the AEC is responsible for
enforcing the decisions made by the ADC.

In order to enforce digital rights, the AEC defines a set system calls which replace the some of the
original system calls in the kernel. Whenever a request is made, the AEC’s system calls are called
instead of the original system calls. Within each of its own system calls, the AEC, checks with the
ADC if access can be granted, and depending on the response from the ADC, access is either granted
or denied. In order to deny access, the AEC simply returns an error message to the application
requesting access. In order to grant access, the AEC calls the original system call to serve the access
request.


4       Security Considerations
DRM is a security service and thus the objective is to provide as secure a system as possible. However,
in the implementation of our system we have not implemented some security features due to our
narrow focus, although all these features are slated for future additions. However, these features do
not directly impact the operation of the system. We will discuss the security considerations according
to the security services outlined in ITU’s X.800 standard:

4.1     Authentication

Authentication is an important element in access control – the data must be accessible only by the
authorised user. For the purposes of our prototype, we made use of basic digital certificates for user
authentication. However, the system is extensible to make use of other authentication mechanisms
such as PAM, Liberty Alliance identity protocols etc.

4.2     Access Control

The purpose of a DRM system is to enforce persistent access control and thus this is an essential
security service. Only authenticated users with the correct rights should be granted access to data.

Another issue associated with access control is discussed by Reid et al. in [12] with regards to the
ease of bypassing a kernel level DRM controller. However, as discussed by Zugenmaier in [15], it is
possible to sidestep this issue by insisting on the presence of a proper DRM controller through the use


                                                    7
of a TPM module. However, such mechanisms are currently not enforced by our system.

4.3     Data Confidentiality

Normally, DRM packages make use of encryption for data confidentiality. Although our system could
handle encrypted data packages, this part was very primitive and thus not included in our analysis.

Another part of data confidentiality is the confidentiality of use licenses and other data residing on
the client computer. For our prototype, we did not consider the security of such data as we expect
that any real world implementation would make use of a secure, tamper-resistant hardware device for
storage.

4.4     Data Integrity

The system made use of signed hashes to ensure data integrity.

4.5     Non-Repudiation

All data is signed and thus allows for non-repudiation. A more interesting problem arises with the
communication between the kernel and the daemon module, and the use of these modules themselves.
At the moment, we have no non-repudiation mechanism in place for this purpose. However, as
discussed by Zugenmaier in [15], the use of a hardware token such as a TPM module would help with
proving the integrity of the kernel module and the daemon and thus help with proving the integrity
of the communication between the two components.

4.6     Availability

If the kernel module is not loaded or the daemon module is not operational, then DRM protected
data will not be accessible (as expected). If the system is offline, then the license server would not
be accessible and thus new DRM protected data with missing or invalid licenses will be inaccessible.
There is also the situation where the daemon module is unavailable, but the kernel module is running.
In this case, DRM protected data is not accessible, and the kernel sends an appropriate error message.


5       HYP-02: Performance Analysis
This section describes the experiment that was conducted to determine the performance cost imposed
on the system by the DRM controller, the results of the experiment and the analysis of these results.
The aim in this experiment was to prove or disprove HYP-02, discussed in section 1. We discuss
HYP-02 first as the results contribute to answering HYP-01.

5.1     Experiment

5.1.1    Method

The following two system calls were used during this experiment:

    1. read(), and
    2. rename().

These system calls correspond to the DRM use license permissions, DISPLAY and MOVE, respectively.
They were chosen for this experiment because they represent the two types of access operations which
can be performed by the file system of an operating system on the data stored on the disk. The read()
system call performs sequential accesses on each byte of the data, whereas the rename() system call
only operates on the entire chunk of data - a file - as a whole.

                                                  8
The experiment involved the following three tests.


  1. First, we measured the duration of the read() and rename() system calls in a standard Linux
     kernel when accessing non-DRM protected files of various sizes.

  2. We then determined the system call overhead of the two system calls when the DRM controller
     kernel module was enabled. As in test 1, all the files used in this test were non-DRM protected.

  3. Finally, we repeated test 2, but this time, we used files which were DRM protected.


Two sets of files, both consisting of six files each, were used. The files in the one set were DRM
protected, while those in the other set were regular non-DRM protected files. Each set was comprised
of the files with the following file sizes:


  1. 1KB,

  2. 32KB,

  3. 128KB,

  4. 1MB,

  5. 32MB, and

  6. 128MB.


For each test-run, the system calls were invoked 10 times per file. The duration of the system call
was then determined by taking the average of the 10 measurements. These results were tabulated
and are presented in tables 1 and 2. The DRM protected files did not make use of either encryption
or compression. We hope to further investigate the performance costs if these factors are taken into
account.

5.1.2    Test Environment

The experiment was conducted on an Intel Celeron desktop computer with a 1.7GHz CPU clock speed
and 512 MB of RAM, which can be considered as representative of an average end-user machines. We
used a standard 2.6.13.4 Linux kernel compiled with preemptive support.

5.2     Results

Tables 1 and 2 show the results of the three tests for the read() and rename() system calls respectively.
In each table, the performance costs incurred by the DRM controller are shown.

5.3     Analysis

There are three areas in the DRM controller which contribute to a performance overhead:


  1. Intercepting the access request and detecting DRM protected data.

  2. Communicating with the daemon.

  3. Parsing the use license and enforcing the rights specified in the license.




                                                   9
                        Std kernel             Std kernel + DRM ctl.    Std kernel + DRM ctl.
      File size   Non-DRM data access time   Non-DRM data access time   DRM data access time    Non-DRM data overhead   DRM data overhead
       (KB)                 (µs)                        (µs)                     (µs)                    (%)                  (%)
          1               39.237                       47.902                  4939.474                22.084              12488.817
         32               80.437                       86.257                  6557.291                 7.235               8052.083
        128               245.132                     248.649                  5113.205                 1.435               1985.899
        1024             1602.570                     1581.591                 6587.491                 1.309               311.058
       32768            47366.808                    46725.513                57306.870                 1.354                20.985
      131072            188026.205                   185969.232               214434.032                1.094                14.045

     Table 1: Comparing the duration of the read() system call when handling DRM protected and non-DRM protected data on a DRM-enabled and
     DRM-free system.
10




                        Std kernel             Std kernel + DRM ctl.    Std kernel + DRM ctl.
      File size   Non-DRM data access time   Non-DRM data access time   DRM data access time    Non-DRM data overhead   DRM data overhead
       (KB)                (µs)                         (µs)                     (µs)                   (%)                   (%)
          1              15.0425                       25.337                  6804.710                68.436              45136.563
         32               12.868                       22.066                  6272.514                71.480              48645.058
        128               11.301                       19.802                  6561.940                75.223              57965.127
        1024              11.238                       21.228                  6486.350                88.895              57618.010
       32768              11.031                       21.392                  7052.769                93.926              63835.899
      131072              11.115                       23.912                  7422.106               115.133              66675.583

     Table 2: Comparing the duration of the rename() system call when handling DRM protected and non-DRM protected data on a DRM-enabled and
     DRM-free system.
The cost of intercepting the access request and detecting whether the request applies to DRM protected
data occurs regardless whether the data is DRM protected or not. This is the stage where the DRM
controller distinguishes between access requests that need DRM protection and access requests that
do not. Assuming that the daemon communications and rights enforcement cost is negligible, this
cost will be the best-case performance cost that will be incurred by the DRM controller.

Table 1 shows the result of the three tests for the read() system call. We see that the performance costs
imposed by the DRM controller when accessing non-DRM protected information, there is an increase
in the overhead by 22% for a 1K file, decreasing until it reaches a near 1% performance overhaed cost
for a 128MB file. This suggests that the overhead from intercepting access requests and detecting
DRM data is so small compared to the overhead of communicating with the daemon and enforcing
the license rights, that it is negligible. If we had measured access times for file sizes beyond 128MB,
we are certain that overhead would decrease even further.

Looking at table 2, we see the access times when non-DRM protected content in a standard kernel
with the DRM controller enabled remain almost the same. This is as expected, as the rename()
system call performs only one access on the data, regardless on the size of the data. We attribute
the discrepancies in the access times to experimental error, arrangement of files on disc and possible
variances in system load. We also notice that performance overhead increases as the file size increases,
which is unexpected.

When accessing DRM-protected content on a DRM-enabled system using the read() system call, we
observed a similar trend as in the non-DRM protected case. Although the access times increase as
the file sizes increase, the performance overhead decreases. Initially, we find a 12489% increase in
performance cost. This high cost increase is due to the large overhead involved when communicat-
ing with the daemon, parsing the license, and traversing the in-memory license structure to enforce
digital rights. As more read requests are performed this cost becomes less noticeable, and drops to
approximately 14% for a 128 MB file.

Table 2 again shows similar access times when accessing DRM-protected content, regardless of the
size of the file. This time, the performance cost ranges between 45136.6% to 66675.6%, which is
very high, compared to the performance cost imposed when accessing non-DRM protected data in a
DRM-enabled system. The large overhead remains, even on large files.

In both the read() and rename() cases, the overhead due to the daemon communications and the rights
enforcement far outweigh the cost of intercepting access requests. This, of course, raises questions
regarding the infrastructure of the DRM controller. If a file found to be DRM protected by the kernel,
it must start a expensive communication with the daemon. This costly process might best be avoided
by introducing a hardware implementation of a license store, instead of file-system based one which is
managed by a user-space application. If the license store was managed by kernel, the need to request
licenses from the daemon would be removed. However, there might still be a cost, as the the kernel
still needs to establish communication with the daemon to allow it to retrieve licenses from remote
license servers.

Even though there are high costs incurred, the net effect on time is minimal and will not be noticable
by the end user for single user machines. This analysis will however not hold for multi-user or high
performance machines and thus improvements are necessary before it can be considered for deployment.

We are also need to consider the frequency at which accesses to DRM protected content are made.
If access to protected content is relatively infrequent, then the huge cost might still be judged to be
negligible, since the performance cost is still sufficiently small that a human user would not notice
it. However such a judgement cannot be reached without further investigation of file access patterns,
such as those created by web servers, or a multi-user system where the majority of files are protected.



                                                   11
6      HYP-01: Viability of a Kernel Level DRM Controller
The current system has been built in order to test the feasibility of an operating system level DRM
controller. It does not seek to provide a complete solution to the problem, thus we considered it
sufficient to implement only the core functionalities. There are a number of problems which have
been encountered that fall outside the scope of the current implementation which we do not detail in
this paper. This section describes the issues that would need to be addressed in a complete system
implementation. We conclude this section by re-examining our first hypothesis, described in section
1.

6.1    Interpreting Rights Expressions

Some rights are harder to enforce since they cannot easily be identified at the kernel level. For
example, ODRL defines limitations to be placed upon the number of pages that an end user may
print. Within the GNU-Linux kernel there is no concept of a document page because they only exist
within applications such as word processors that need to support such an entity. Similar problems
will exist with hardware implementations of DRM controllers.

Thus, we believe that there needs to be two levels of rights in a DRM system if an operating system
or hardware level implementation is to be successful.

    1. Level 1: These rights (or permissions in ODRL) are common to all operating systems and
           devices. They would include the permissions we have implemented in our prototype, such
           as restrictions on reading a file, and will in effect be persistent extensions of existing access
           control rules. Thus these restrictions will be enforced at the operating system or hardware
           level.
    2. Level 2: These rights are only enforceable at the application layer because only certain appli-
           cations will be able to make sense of the rights. Rights like the permission to print a certain
           number of pages or the portions of a document that can be excerpted only make sense to
           the application handling the file.

With the above categorisation, it will no longer be necessary to require application support if the
DRM protection is restricted to Level 1 rights. It should be possible to specify in Level 1, the right
to access a file only with a specific application thus preventing bypassing of Level 2 restrictions.

6.2    Compensating for Application Behaviour

Some applications behave unexpectedly. For instance, multiple access attempts may be made before
an application determines that a file cannot be accessed. The daemon module must compensate
and distinguish genuine requests from repeat requests. This is to avoid initiating multiple license
negotiations for the same asset.

6.3    General Implications of Operating System level DRM

Our first hypothesis states that application level transparency can be achieved. The initial prototype
has demonstrated that a basic mechanism can be put in place to handle access attempts at the kernel
level. Furthermore, application level support was not required. However, there are still a number of
problems that must be solved before access control can be successfully enforced at the kernel level.
Simple file formats and applications can be supported with relatively little work. However other
applications behave in a more complex manner. This requires the presence of additional logic within
the kernel module, which may complicate matters unnecessarily.

The performance impact is negligible in wall time for the user, and considering that this is a prototype
kernel module, kernel level DRM modules for users can be a practical solution.

                                                    12
7     Future Work
As discussed in the course of the paper, there are a number of areas for future work. Foremost, is the
handling of compression and encrypted files by the kernel module, and the performance implications
of these features. We are currently in the process of perfecting our approach, and hope to perform
similar performance experimentation as presented in this paper on these extensions.

Secondly, and more complex in nature is to investigate automatic negotiation of use licenses by the
license server. Automatic negotiation of use licenses will be the next major step in DRM and does
not feature in any current DRM implementations, mainly because negotiations are not handled by
any current implementation. However, as discussed in [5], negotiation of use licenses will lead to fairer
use licenses and a variety of different business models – both crucial if DRM is to be embraced by the
consumers.

We would also like to improve on the number of permissions and constraints that can be handled
by the kernel module, and identify all the possible Level 1 permissions. We would also like to add
modules to handle other RELs like XrML.


8     Conclusions
In this paper, we presented a prototype DRM controller, which enforces rights to digital content at the
operating system level of a computer. It offers DRM protection for any file format, transparently to any
user-space application trying to access the DRM protected content. We described its implementation,
and discussed an experiment which was conducted to evaluate its performance. We also looked at how
effectively it is able to enforce digital rights.

The existing prototype does not address all the problems of implementing a DRM controller. In our
implementation, we have ignored security issues such as encryption and secure daemon communica-
tions. However, the system does demonstrate that an operating system level DRM implementation is
possible, supporting multiple file formats and remaining transparent to applications, and thus proves
hypothesis one with regards to the viability of kernel level controllers.

However, not all access control rules can be enforced at the application layer and indeed any future
hardware layer implementations. This leads to a separation of types of permissions into two levels –
permissions can be easily enforced by the operating system (or future hardware DRM controllers) and
permissions that need to be enforced by applications. Thus, there is a need to categorise permissions
according to these levels.

In addition, the performance overhead for unprotected data should not increase in a fully implemented
system. Therefore only protected data need be considered. In the case of protected data, it is sufficient
to ensure that the user remains unaware of performance overhead. At the present stage, the overhead
is in terms of milliseconds and thus undetectable by end users. However, in terms of performance
figures, the overhead is very high for some types of file operations. Thus, while the the overhead does
not appear to impact end users, there is a high performance cost for kernel level DRM controller. This
could be due to our inexperience in implementation of kernel modules, and further improvements are
necessary.


9     Acknowledgements
This work is partially supported through grants from the UCT Council and the National Research
Foundation (NRF) of South Africa. Any opinions, findings, and conclusions or recommendations
expressed in this paper/report are those of the author(s) and do not necessarily reflect the views of
UCT, the NRF or the trustees of the UCT Council.


                                                   13
References
 [1] Technical overview of windows rights management services for windows server 2003. White paper,
     Microsoft, 2003.

 [2] Arnab, A. Specifications for a componentised digital rights management (DRM) framework.
     Tech. Rep. CS05-03-00, University of Cape Town, 2005.

 [3] Arnab, A., and Hutchison, A. Digital Rights Management - An overview of Current Chal-
     lenges and Solutions. In Proceedings of Information Security South Africa (ISSA) Conference
     2004 (2004).

 [4] Arnab, A., and Hutchison, A. Extending ODRL to Enable Bi-Directional Communication.
     In Proceedings of the 2nd International ODRL Workshop, Lisbon, Portugal (2005).

 [5] Arnab, A., and Hutchison, A. Fairer usage contracts for DRM. In Proceedings of the fifth
     ACM Workshop on Digital Rights Management, Co-Located with ACM CCS 2005, Alexandria,
     Virginia, USA (2005).

 [6] Arnab, A., and Hutchison, A. Requirement Analysis of Enterprise DRM Systems. In Proceed-
     ings of Information Security South Africa (ISSA) Conference 2005, Johannesburg, South Africa
     (2005).

 [7] Bechtold, S. Digital Rights Management in the United States and Europe. IVir, Buma/Stemra
     - Copyright and the Music Industry: Digital Dilemmas.

 [8] Guth, S., Neumann, G., and Strembeck, M. Experiences with the enforcement of access
     rights extracted from ODRL-based digital contracts. In Proceedings of the 2003 ACM workshop
     on Digital Rights Management (2003), ACM, pp. 90–102.

 [9] Mulligan, D., Han, J., and Burstein, A. How DRM Based Content Delivery Systems
     Disrupt Expectations of ”Personal Use”. In Proceedings of the 2003 ACM workshop on Digital
     Rights Management (2003), ACM, pp. 77–89.
     URL: http://doi.acm.org/10.1145/947380.947391.

[10] Open Mobile Alliance (OMA). Digital rights management. Approved Version 15 Jun 2004
     – OMA-Download-DRM-V1 0-20040615-A, 2004.

[11] Park, J., Sandhu, R., and Schifalacqua, J. Security architectures for controlled digital
     information dissemination. In Proceedings of the 16th Annual Computer Security Applications
     Conference (2000).

[12] Reid, J. F., and Caelli, W. J. DRM, Trusted Computing and Operating System Architecture.
     In Conferences in Research and Practice in Information Techology (Newcastle, Australia, 2005),
     vol. 44, Australian Computer Society, Inc., pp. 127 – 136.

[13] Rosenblatt, B. DRM for the Enterprise, 2004.

[14] Rosenblatt, B., and Dykstra, G. Integrating content management with digital rights man-
     agement - imperatives and opportunities for digital content lifecycles. White paper, Giantsteps
     Media Technology Strategies, 2003.
     URL: http://www.giantstepsmts.com/drm-cm white paper.htm.

[15] Zugenmaier, A. Security and privacy. In Proceedings of Information Security South Africa
     (ISSA) Conference 2005, Johannesburg, South Africa (2005).




                                                14

								
To top