95 research outputs found

    Optimistic fair exchange

    Get PDF
    A fair exchange guarantees that a participant only reveals its items (such as signatures, payments, or data) if it receives the expected items in exchange. Efficient fair exchange requires a so-called third party, which is assumed to be correct. Optimistic fair exchange involves this third party only if needed, i.e., if the participants cheat or disagree. In Part I, we prove lower bounds on the message and time complexity of two particular instances of fair exchange in varying models, namely contract signing (fair exchange of two signatures under a contract) and certified mail (fair exchange of data for a receipt). We show that all given bounds are tight by describing provably time- and message-optimal protocols for all considered models and instances. In Part II, we have a closer look at formalizing the security of fair exchange. We introduce a new formal notion of security (including secrecy) for reactive distributed systems. We illustrate this new formalism by a specification of certified mail as an alternative to the traditional specification given in Part I. In Part III, we describe protocols for generic and optimistic fair exchange of arbitrary items. These protocols are embedded into the SEMPER Fair Exchange Layer, which is a central part of the SEMPER Framework for Secure Electronic Commerce.Ein Austausch ist fair, wenn eine Partei die angebotenen Güter, wie zum Beispiel digitale Signaturen, Zahlungen oder Daten, nur abgibt, wenn sie die erwarteten Güter im Tausch erhält. Ohne eine als korrekt angenommene dritte Partei, welche eine mit einem Notar vergleichbare Rolle übernimmt, ist fairer Austausch nicht effizient möglich. Ein fairer Austausch heißt optimistisch, falls diese dritte Partei nur in Problemfällen am Protokoll teilnimmt. In Teil I werden beweisbar zeit- und nachrichtenoptimale Protokolle für die Spezialfälle \u27;elektronische Vertragsunterzeichnung" (fairer Austausch zweier Signaturen; engl. contract signing) und \u27;elektronisches Einschreiben" (fairer Austausch von Daten gegen eine Quittung; engl. certified mail) von fairem Austausch vorgestellt. Teil II beschreibt einen neuen Integritäts- und Geheimhaltungsbegriff für reaktive Systeme. Dieser basiert auf einer Vergleichsrelation \u27;so sicher wie", welche die Sicherheit zweier Systeme vergleicht. Ein verteiltes, reaktives System wird dann als sicher bezeichnet, wenn es so sicher wie ein idealisiertes System (engl. trusted host) für diesen Dienst ist. Mit diesem Formalismus geben wir eine alternative Sicherheitsdefinition von \u27;elektronischem Einschreiben" an, deren Semantik im Gegensatz zu der in Teil I beschriebenen Definition nun unabhängig vom erbrachten Dienst ist. Teil III beschreibt ein Design und optimistische Protokolle für generischen fairen Austausch von zwei beliebigen Gütern und den darauf aufbauenden SEMPER Fair Exchange Layer. Dieser ist ein wesentlicher Baustein des SEMPER Framework for Secure Electronic Commerce

    Optimistic fair exchange

    Get PDF
    A fair exchange guarantees that a participant only reveals its items (such as signatures, payments, or data) if it receives the expected items in exchange. Efficient fair exchange requires a so-called third party, which is assumed to be correct. Optimistic fair exchange involves this third party only if needed, i.e., if the participants cheat or disagree. In Part I, we prove lower bounds on the message and time complexity of two particular instances of fair exchange in varying models, namely contract signing (fair exchange of two signatures under a contract) and certified mail (fair exchange of data for a receipt). We show that all given bounds are tight by describing provably time- and message-optimal protocols for all considered models and instances. In Part II, we have a closer look at formalizing the security of fair exchange. We introduce a new formal notion of security (including secrecy) for reactive distributed systems. We illustrate this new formalism by a specification of certified mail as an alternative to the traditional specification given in Part I. In Part III, we describe protocols for generic and optimistic fair exchange of arbitrary items. These protocols are embedded into the SEMPER Fair Exchange Layer, which is a central part of the SEMPER Framework for Secure Electronic Commerce.Ein Austausch ist fair, wenn eine Partei die angebotenen Güter, wie zum Beispiel digitale Signaturen, Zahlungen oder Daten, nur abgibt, wenn sie die erwarteten Güter im Tausch erhält. Ohne eine als korrekt angenommene dritte Partei, welche eine mit einem Notar vergleichbare Rolle übernimmt, ist fairer Austausch nicht effizient möglich. Ein fairer Austausch heißt optimistisch, falls diese dritte Partei nur in Problemfällen am Protokoll teilnimmt. In Teil I werden beweisbar zeit- und nachrichtenoptimale Protokolle für die Spezialfälle ';elektronische Vertragsunterzeichnung" (fairer Austausch zweier Signaturen; engl. contract signing) und ';elektronisches Einschreiben" (fairer Austausch von Daten gegen eine Quittung; engl. certified mail) von fairem Austausch vorgestellt. Teil II beschreibt einen neuen Integritäts- und Geheimhaltungsbegriff für reaktive Systeme. Dieser basiert auf einer Vergleichsrelation ';so sicher wie", welche die Sicherheit zweier Systeme vergleicht. Ein verteiltes, reaktives System wird dann als sicher bezeichnet, wenn es so sicher wie ein idealisiertes System (engl. trusted host) für diesen Dienst ist. Mit diesem Formalismus geben wir eine alternative Sicherheitsdefinition von ';elektronischem Einschreiben" an, deren Semantik im Gegensatz zu der in Teil I beschriebenen Definition nun unabhängig vom erbrachten Dienst ist. Teil III beschreibt ein Design und optimistische Protokolle für generischen fairen Austausch von zwei beliebigen Gütern und den darauf aufbauenden SEMPER Fair Exchange Layer. Dieser ist ein wesentlicher Baustein des SEMPER Framework for Secure Electronic Commerce

    Is electronic cash possible?

    Get PDF
    Cash-like payments in electronic commerce and at the traditional point of sale are expected to be beneficial, e.g., because of privacy protection, low transaction costs, and irrevocability. Therefore, we discuss how to design electronic cash in a way that it both mirrors the most important characteristics of raditional cash, but also fulfils the expectations which arise towards electronic means of payment. We analyse the problems and trade-offs between the different characteristics to be implemented. This analysis is based on a user survey and a review of existing technologies for electronic payment systems. Finally we argue why existing systems do not fulfil the critical requirements, and point out future work towards electronic cash which will meet more requirements

    Privacy-enabled Services for Enterprises

    No full text
    The IBM Enterprise Privacy Architecture (EPA) is a methodology for enterprises to provide an enhanced and well-defined level of privacy to their customers. EPA is structured in four building blocks. The privacy regulation analysis identifies and structures the applicable regulations. The management reference model enables an enterprise to define and enforce an enterprise privacy strategy and the resulting privacy practices. The privacy agreement framework is a methodology for privacy-enabling business process re-engineering. It outputs a detailed model of the privacy-relevant players and activities as well as the privacy policies that govern these activities. The technical reference architecture defines the technology needed for implementing the identified practices. The Platform for Enterprise Privacy Practices (E-P3P) is a refinement of EPAs technical reference architecture: Enterprises collect a certain amount of personal data while promising fair information practices to their customers. E-P3P enables an enterprise to keep the privacy promises made. It formalizes these privacy promises into policies and associates a consented policy to each piece of collected data. This consented policy can then be used in access control decisions to enforce the privacy promises made

    From absence of certain vulnerabilities towards security proofs: pushing the limits of formal verification

    Get PDF
    The application of formal methods for rigorously validating cryptographic protocols has been getting increasing attention. The de facto standard for modeling such protocols in formal proof systems is the Dolev-Yao model that, e.g., uses abstract encryption instead of cryptographic encryption primitives. The Dolev-Yao model has been originally intended and successfully used for detecting flaws in many protocols. However, recent publications claim to perform actual proofs of security using this model, i.e., absence of any attack. We doubt this claim and challenge Dolev-Yao-based models as being oversimplified for establishing security proofs against arbitrary attacks. We substantiate our claim by an example protocol. This protocol has been proven secure in a Dolev-Yao-based model using formal methods. In a later publication, the protocol has been broken by describing a cryptographic attack. The attack was not detected in the formal analysis since any Dolev-Yao-based model only comprises a predefined set of adversary capabilities. The particular attack to break the protocol was not comprised. The only reliable long-term remedy is to proof resilience against all attacks (both known and unknown ones). Recent approaches on cryptographic models of security have already made great progress towards this goal. Unfortunately, proofs in these are more complex and harder to automate. On the short run, it therefore is appropriate to improve the quality of formal analysis without striving for complete proofs. This can be achieved by means of evolving a catalog of adversary capabilities. Future formal analysis can then show resilience against any attack in this catalog. We initiate this discussion on an “adversary capability catalog ” by providing a cryptographer’s wish list. This list that points out several features which approaches based on the Dolev-Yao model or future extensions of it should cover in order to be effective for cryptographic protocol verification.
    • …
    corecore