Active Networks is a network infrastructure which is programmable on a per-user or even per-packet basis. Increasing the flexibility of such network infrastructures invites new security risks. Coping with these security risks represents the most fundamental contribution of Active Network research. The security concerns can be divided into those which affect the network as a whole and those which affect individual elements. It is clear that the element problems must be solved first, as the integrity of networklevel solutions will be based on trust of the network elements. In this

Cryptographic mechanisms are an important security component of an operating system in securing the system itself and its communication paths. Indeed, in many situations, cryptography is the only tool that can solve a particular problem, e.g., network-level security. While cryptography by itself does not guarantee security, when applied correctly, it can signi cantly improve overall security. Since one of the main foci of the OpenBSD system is security, various cryptographic mechanisms are employed in a number of di erent roles. This paper gives an overview of the cryptography employed in OpenBSD. We discuss the various components (IPsec, SSL libraries, stronger password encryption, Kerberos IV, random number generators, etc.), their role in system security, and their interactions with the rest of the system (and, where applicable, the network). 1

Proposals for programmable network infrastructures, such as active networks and open signaling, provide programmers with access to network resources and data structures. The motivation for providing these interfaces is accelerated introduction of new services, but exposure of the interfaces introduces many new security risks. The risks can be reduced or eliminated via appropriate restrictions on the exported interfaces. In this article we describe some of the security issues raised by active networks. We then describe our secure active network environment architecture. SANE was designed as a security infrastructure for active networks, and was implemented in the SwitchWare architecture. SANE restricts the actions loaded modules (including "capsules") can perform by restricting the resources that can be named; this is further extended to remote invocation by means of cryptographic credentials. SANE can be extended to support restricted control of quality of service in a programmable...

Recent work in the area of network security, such as IPsec, provides mechanisms for securing the trac between any two interconnected hosts. However, it is not always possible, economical, or even practical from an administration and operational point of view to upgrade the software and con guration of all the nodes in a network to support such security protocols. One apparent solution to this problem is the use of security gateways that apply the relevant security protocols on behalf of the protected nodes, under the assumption that the \last hop" between the security gateway and the end node is safe without cryptography. Such a gateway can be set to enforce speci c security policies for dierent types of trac. While this solution is appealing in static scenarios (such as building so-called \intranets"), the use of Layer-3 (network) routers as security gateways presents some transparency and con guration problems with regards to peer authentication in the automated key management prot...

Abstract. Software that covertly monitors user actions, also known as spyware, has become a first-level security threat due to its ubiquity and the difficulty of detecting and removing it. Such software may be inadvertently installed by a user that is casually browsing the web, or may be purposely installed by an attacker or even the owner of a system. This is particularly problematic in the case of utility computing, early manifestations of which are Internet cafes and thin-client computing. Traditional trusted computing approaches offer a partial solution to this by significantly increasing the size of the trusted computing base (TCB) to include the operating system and other software. We examine the problem of protecting a user accessing specific services in such an environment. We focus on secure video broadcasts and remote desktop access when using any convenient, and often untrusted, terminal as two example applications. We posit that, at least for such applications, the TCB can be confined to a suitably modified graphics processing unit (GPU). Specifically, to prevent spyware on untrusted clients from accessing the user’s data, we restrict the boundary of trust to the client’s GPU by moving image decryption into GPUs. We use the GPU in order to leverage existing capabilities as opposed to designing a new component from scratch. We discuss the applicability of GPU-based decryption in these two sample scenarios and identify the limitations of the current generation of GPUs. We propose straightforward modifications to future GPUs that will allow the realization of the full approach. 1

accounting. OCB uses djM j=ne + 2 block-cipher calls for a nonempty message M . (The empty string takes three block-cipher invocations, the same as a one-block message). We compare with CBC encryption and CBC encryption plus a CBC MAC:

iKP - the Internet Keyed Payments protocol family - defines an architecture for secure account-based (e.g., credit card) payments over the Internet or similar open network environments. Readers unfamiliar with the Internet Keyed Payments protocol (iKP) family are referred to the general iKP paper [1] and Specifications of Zurich iKP Prototype (ZiP) [10, 3]. This document describes the cryptographic part of the Zurich iKP Prototype (ZiP) as API's and cryptographic primitives used. 3 Acknowledgments The Zurich iKP Prototype (ZiP) represents a joint effort by Michael Steiner, Gene Tsudik and Els Van Herreweghen. Contributions made by Ralf Hauser, Phil Janson, Steen Larsen and Michael Waidner are gratefully acknowledged. i Contents 1 Status of this Memo i 2 Abstract i 3 Acknowledgments i 4 Crypto-API 1 4.1 Types : : : : : : : : : : : : : : : : : : : : : : : : : : : : 1 4.2 Functions : : : : : : : : : : : : : : : : : : : : : : : : : : 1 4.2.1 Signatures : : : : : : : : : : : : : : : : ...

As a general design criterion, a symmetric key cipher should not be closed under functional composition due to the implications on the security of the cipher. However, there are scenarios in which this property is desirable and can be obtained without reducing the security of a cipher by increasing the computational workload of the cipher. We expand the idea of a symmetric key cipher being closed under functional composition to a more general scenario where there exists a function that converts the ciphertext resulting from encryption under a specific key to the ciphertext corresponding to encryption with another key. We show how to perform such a conversion without exposing the plaintext. We discuss the tradeoff between the computational workload and security, and the relationship between such conversions and proxy cryptography. We conclude with a description of some practical applications of our results.

Abstract: As a general design criterion, a symmetric key cipher should not be closed under functional composition due to the implications on the security of the cipher. However, there are scenarios in which this property is desirable and can be obtained without reducing the security of a cipher by increasing the computational workload of the cipher. We expand the idea of a symmetric key cipher being closed under functional composition to a more general scenario where there exists a function that converts the ciphertext resulting from encryption under a specific key to the ciphertext corresponding to encryption with another key. We show how to perform such a conversion without exposing the plaintext. We discuss the tradeoff between the computational workload and security, and the relationship between such conversions and proxy cryptography. We conclude with a discussion of some practical applications of our results.

draft-ietf-openpgp-formats-06.txt