Andrew Hutchison

Persistent access control: a formal model for drm

Digital rights management (DRM) can be considered to be a mechanism to enforce access control over a resource without considering its location. There are currently no formal models for DRM, although there has been some work in analysing and formalising the interpretation of access control rules in DRM systems. A formal model for DRM is essential to provide specific access control semantics that are necessary for creating interoperable, unambiguous implementations. In this paper, we discuss how DRM differs as an access control model to the three well known traditional access control models - DAC, MAC and RBAC, and using these existing approaches motivate a set of requirements for a formal model for DRM. Thereafter, we present a formal description of LiREL, a rights expression language that is able to express access control policies and contractual agreement in a single use license. Our motivation with this approach is to identify the different components in a license contract and define how these components interact within themselves and with other components of the license. A formal notation allows for an uniform and unambiguous interpretation and implementation of the access control policies.

GENERATING NETWORK SECURITY PROTOCOL IMPLEMENTATIONS FROM FORMAL SPECIFICATIONS

We describe the Spi2Java code generation tool, which we have developed in an attempt to bridge the gap between formal security protocol specification and executable implementation. Implemented in Prolog, Spi2Java can input a formal security protocol specification in a variation of the Spi Calculus, and generate a Java code implementation of that protocol. We give a brief overview of the role of code generation in the wider context of security protocol development. We cover the design and implementation of Spi2Java which we relate to the high integrity code generation requirements identified by Whalen and Heimdahl. By defining a Security Protocol Implementation API that abstracts cryptographic and network communication functionality we show that protocol logic code can be separated from underlying cryptographic algorithm and network stack implementation concerns. The design of this API is discussed, particularly its support for pluggable implementation providers. Spi2Javas functionality is demonstrated by way of example: we specify the Needham-Schroeder Public Key Authentication Protocol, and Lowes attack on it, in the Spi Calculus and examine a successful attack run using Spi2Java generated implementation of the protocol roles.

Fairer usage contracts for DRM

DRM has been widely promoted as a means to enforce copyright. In many previous papers, it has been argued that DRM gives too much power to rights holders and actually goes beyond the restrictions provided by copyright laws. In this paper we argue that DRM does not actually implement the fundamentals of copyright law, and is rather a mechanism for enforcing licence and contract restrictions on digital data. However, we believe that DRM does have a place in the digital distribution of copyrighted works and present two mechanisms that would allow users to get a more balanced deal from the rights holders. The mechanisms we present also allow for newer business models that cannot be easily implemented with current DRM systems.

An architecture for secure searchable cloud storage

Cloud Computing is a relatively new and appealing concept; however, users may not fully trust Cloud Providers with their data and can be reluctant to store their files on Cloud Storage Services. This paper describes a solution that allows users to securely store data on a public cloud, while also allowing for searchability through the users encrypted data. Users are able to submit encrypted keyword queries and, through a symmetric searchable encryption scheme, the system finds all files with such keywords contained within. The system is designed in such a manner that trust from a public cloud provider is not required. The solution satisfies confidentiality of data; data integrity is maintained, file sharing is catered for and a user key-revocation scheme is in place. A further advantage of this approach is that if there is a security breach at the cloud provider, the users data will continue to be secure since all data is encrypted. Users also do not need to worry about Cloud Providers gaining access to their data illegally. The architecture of the system consists of two components, the Client side application and the Server application running on the compute cloud. The client side application performs all the security operations on the data. Along with saving and retrieving data from the Storage Service, the Server application performs the processing involved in handling the encrypted queries. The performance overheads of such a system are potentially significant in terms of additional processing time and the size of the additional meta-data needed. Preliminary results show that the storage overheads remain fairly constant as input file sizes increase — as file sizes were increased from 3Kb to 147Mb, the security overhead remained between 1038b and 1053b. This overhead is basically insignificant when storing large files. Overall the benefits of a searchable encrypted cloud service are significant and the approach is viable for using public clouds while still retaining control of the data.

Interfacing Trusted Applications with Intrusion Detection Systems

In this paper we describe an interface between intrusion detection systems and trusted system components. The approach presented differs from conventional intrusion detection systems which are only loosely coupled to the components which they protect. We argue that a tighter coupling makes an IDS less vulnerable to desynchronization attacks, furnishes it with higher quality information and makes immediate and more fine grained responses feasible. Preliminary results show that this can be achieved through an external, nonspecific, voluntary reference monitor accessible to applications through a simple API. Reasonable performance can be maintained by moving most of the IDS functionality into the context of the trusted application.

Using Payment Gateways to Maintain Privacy in Secure Electronic Transactions

Because many current payment systems are poorly implemented, or of incompetence, private data of consumers such as payment details, addresses and their purchase history can be compromised. Furthermore, current payment systems do not offer any non-repudiable verification to a completed transaction, which poses risks to all the parties of the transaction — the consumer, the merchant and the financial institution. One solution to this problem was SET, but it was never really a success because of its complexity and poor reception from consumers. In this paper, we introduce a third party payment system that aims to preserve privacy by severing the link between their purchase and payment records, while providing a traceable transaction that maintains its integrity and is non-repudiable. Our system also removes much of the responsibilities placed on the merchant with regards to securing sensitive data related to customer payment, thus increasing the potential of small businesses to take part in e-commerce without significant investments in computer security.

Predicting the Performance of Transactional Electronic Commerce Protocols

As security practitioners, there is a tendency to neglect performance issues. The Secure Electronic Transaction (SET) protocol is proposed as the transactional electronic commerce protocol of choice, yet it has been criticised for its complexity and denseness. This paper reports on a performance analysis of SET conducted through the development of a queueing model. The purpose of modelling SET was to predict its performance and determine which stages in the protocol are likely bottlenecks and points for optimisation when doing SET implementations. Results reveal that existing infrastructures will generally suffice for SET, financial network authorization delay directly affects performance and that transaction times are strongly dependent on the merchant and gateway processing time.

Experiences in Implementing a Kernel-Level DRM Controller

The enforcement of DRM licenses is performed by a DRM controller, and it can be implemented at the application level, the operating system level and at a hardware level. In this paper we discuss our experiences in implementing an operating system level DRM controller based on the GNU-Linux kernel. This paper investigates the feasibility of creating a transparent, application independent DRM controller and the performance implications thereof. Our investigation has revealed, that while a number of access control rules can be enforced transparently 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 advantage of transparent enforcement at the kernel level. Our performance analysis shows promise with minimal user observable time impact for small files less than 25 MB in size. However, there is still a significant performance impact and a very noticeable user observable time performance impact for larger files. Thus improvements are necessary if DRM controllers are to be deployed in multi-user, high-load environments like file servers.

Enhanced security protocol engineering through a unified multidimensional framework

Multidimensional security protocol engineering is effective for creating cryptographic protocols since it encompasses a variety of design, analysis, and deployment techniques, thereby providing a higher level of confidence than individual approaches offer. SPEAR II, the Security Protocol Engineering and Analysis Resource II, is a protocol engineering tool built on the foundation of previous experience garnered during the SPEAR I project in 1997. The goal of the SPEAR II tool is to facilitate cryptographic protocol engineering and to aid users in distilling the critical issues during an engineering session by presenting them with an appropriate level of detail and guiding them as much as possible during design, analysis and implementation. The SPEAR II tool currently consists of four components that have been integrated into one consistent and unified graphical interface: a protocol specification environment (GYPSIE), a GNY statement construction interface (visual GNY), a Prolog-based GNY analysis engine (GYNGER), and a message rounds calculator. The multidimensional approach realized by SPEAR II is combined with a graphical interface that focuses on making specification of a protocol and its associated conditions for formal analysis as straight forward and painless as possible. Experiments that we have conducted confirm that the analysis engine is able to generate accurate proofs for achievable GNY-based goals, while preliminary usability experiments have indicated that the interface utilized by SPEAR II is both expressive and simple to use for specifying cryptographic protocols and constructing logic statements pertaining to these protocols.

A Generic Graphical Specification Environment for Security Protocol Modelling

Designing and implementing security protocols is a difficult task. A graphical specification environment helps one to cope with this complexity by enabling the visualization of hierarchical message structures and providing suitable abstraction and encapsulation so that designers can retain a high-level perspective while also being free to hone in on the details of the design. The graphical interface framework described in this paper isolates the critical issues in a protocol design and presents the user with an appropriate level of detail. This is accomplished through the use of a high-level view of the message flow and a more detailed component view that shows the structure of each protocol message. Each view can be easily manipulated by using standard graphical interface mechanisms such as drag-and-drop and context specific pop-up menus. An added advantage of this interface is that it is possible to connect to analysis or code generation routines via a GGSE-API.