Volker Kessler

Formal Semantics for Authentication Logics

We present a new BAN-like logic and a new formal semantics for logics of authentication. The main focus of this paper is on the foundation of this logic by a possible-worlds semantics. The logic was designed for implementation in the tool AUTLOG and is able to handle most kinds of protocols used in practice. The underlying logic is a K45-logic, including negation. We replace the critical idealization step by changing the set of premises. The formal semantics enables us to detect flaws in previous logics. We apply the logic to a new authentication protocol designed for UMTS.

AUTLOG-an advanced logic of authentication

We present a modified version of the BAN logic which is implemented in PROLOG. The modifications are motivated by the analysis of a lot of protocols. We analyze a challenge-response protocol and its dual version in order to show the advantages of the modified logic. The analysis shows an interesting difference between two protocols which seem to be very similar. Finally, we discuss the inability of the logic to handle parallel protocol runs.<<ETX>>

A Sound Logic for Analysing Electronic Commerce Protocols

We present an authentication logic which is capable to analyse one of the most important features of electronic commerce protocols, i.e., the accountability of transactions. By referring to a formal semantics we prove that the calculus is correct. We apply our logic to the payment systems SET and Payword. The formal analysis explains why micropayment systems based on chains of hashvalues do not lead to the same level of assurance as usual payment systems.

On the Chinese Wall Model

We present a modified version of the Chinese Wall model. Especially, we make some investigations on the indirect information flow induced by the write access. In the original Brewer-Nash model the write permission is very restricted. There a subject can get write access to one object only and only during early states of the system. We change this rule and introduce a dynamic concept of the “conflict of interest relation”. Thus, we prevent an indirect information flow by building more Chinese Walls. Finally, we prove that the system is “conflict secure”, i.e. a subject can never get sensitive information from two or more objects which are in conflict of interest to each other.

A formal security model for microprocessor hardware

The paper introduces a formal security model for a microprocessor hardware system. The model has been developed as part of the evaluation process of the processor product according to ITSEC assurance level E4. Novel aspects of the model are the need for defining integrity and confidentiality objectives on the hardware level without the operating system or application specification and security policy being given, and the utilization of an abstract function and data space. The security model consists of a system model given as a state transition automaton on infinite structures and the formalization of security objectives by means of properties of automaton behaviors. Validity of the security properties is proved. The paper compares the model with published ones and summarizes the lessons learned throughout the modeling process.

A Formal Security Model for Microprocessor Hardware

The paper introduces a formal security model for a microprocessor hardware system. The model has been developed as part of the evaluation process of the processor product according to ITSEC assurance level E4. Novel aspects of the model are the need for defining integrity and confidentiality objectives on the hardware level without the operating system or application specification and security policy being given, and the utilisation of an abstract function and data space. The security model consists of a system model given as a state transition automaton on infinite structures, and the formalisation of security objectives by means of properties of automaton behaviours. Validity of the security properties is proved. The paper compares the model with published ones and summarises the lessons learned throughout the modelling process.

VIRTUES AND VICES ABOUT MONEY

According to the New Testament ‘the love of money’ is a root of all evil and a no-go for church elders. After the financial crises this warning and old virtues are rediscovered. The articles analyse virtues and vices dealing with money. Consulting insights from old texts such as Aristotle, the New Testament, Thomas Aquinas and modern authors like Comte-Sponville and Sofsky we develop a classification with two virtues, generosity and frugality, and two corresponding vices, meanness and greed. Due to the different facets of the topic we discuss these virtues and vices by combining explanations from philosophy, theology, psychology, sociology, and economy. These discussions are led by the question “how can we live these virtues in our modern society?”. Especially, we discuss the challenge of living frugal in a market economy, which regards greed as a ‘virtue in disguise’.

Sicherheitsmodelle in Theorie und Praxis

Die Untersuchung des Begriffs „Sicherheitsmodell“ fuhrt zu dem Ergebnis, das ein Sicherheitsmodell ein Modell im traditionellen Sinne der Wissenschaft ist, namlich eine Beschreibung mit Abstraktion auf das Wesentliche. Eine (formale) Modellierung der Sicherheitsanforderungen ist eine wichtige Voraussetzung, um einerseits hohe Sicherheit zu erreichen und andererseits diese Sicherheit nachzuweisen. Die aus der Literatur bekannten Sicherheitsmodelle greifen jeweils einzelne Sicherheitsaspekte heraus, die sie eingehend analysieren. Der Sicherheitsbedarf eines realen Systems umfast jedoch typischerweise eine individuelle Kombination verschiedener Sicherheitsaspekte. Deshalb existiert zu einem vorgegebenen System nur in Ausnahmefallen bereits ein fur seine Bedurfnisse genau passendes Sicherheitsmodell. Dies wird an einem Beispiel erlautert.

Eine korrekte Authentifikationslogik zur Analyse von Electronic-Commerce-Protokollen

Kryptographische Protokolle enthalten haufig subtile Fehler, die manchmal erst Jahre nach dem Design festgestellt werden. Deswegen hat es sich als gunstig erwiesen, diese Protokolle bereits im Designprozes formal zu analysieren. Eine formale Methode zwingt einen Protokolldesigner dazu, genau aufzuschreiben, welche Voraussetzungen er benotigt und welche Sicherheitsziele er erreichen will.