Search

Protean signatures (PSs), recently introduced by Krenn et al. (CANS ‘18), allow a semi-trusted third party (the sanitiser), to modify a signed message in a controlled way: the signer can define the message parts to be arbitrarily editable by the sanitiser, as well as message parts which can be redacted (but not altered otherwise) by the sanitiser. Thus, PSs generalise both redactable signatures (RSs) and sanitisable signatures (SSs) into a single notion. Invisibility for PSs guarantees that no outsider (i.e. any party not being signer or sanitiser) can decide which message parts can be edited. However, the current definition of invisibility does not prohibit that an outsider can decide which parts are redactable – only which parts can be edited are hidden. This negatively impacts the privacy guarantees provided by this definition. The authors extend PSs to be fully invisible. Their notion guarantees that an outsider can identify neither editable nor redactable parts. They, therefore, introduce the new notions of invisible RSs and invisible non-accountable SSs ( S S ′ ), along with a consolidated framework for aggregate signatures. Using those building blocks, their resulting construction is significantly more efficient than the original scheme by Krenn et al., which they demonstrate in a prototypical implementation.

From smart homes to highly energy-optimized office building and smart city, the adoption of living in smart spaces requires that the inhabitants feel comfortable with the level of data being collected about them in order to provide smartness. However, you usually provide this consent on—or best before—your very first interaction. Thus, firstly your consent might vary over the time of usage. Secondly, it is not always obvious if data is currently collected or not. This paper addresses two missing elements in the interaction with a smart environment: First, the general concept of dynamicity of consent to data collection. Second, provision of a physical interaction to gather and change consent and a physical feedback on the current data collection status. By the feedback being physical we mean being visual, haptic or accoustic, in order to allow natural perception by the users in the physical space. For both components we provide examples which show how one could make both the current status as well as the consent physical and discuss the user perception. We argue that having a physical interaction to start potentially privacy-invasive data collections is a useful enrichment for legal consent, and physically visible status is helpful to make a decision.

The introduction of the General Data Protection Regulation (GDPR) in Europe raises a whole series of issues and implications on the handling of corporate data. We consider the case of security-relevant data analyses in companies, such as those carried out by Security Information and Event Management (SIEM) systems. It is often argued that the processing of personal data is necessary to achieve service quality. However, at present existing systems arguably are in conflict with the GDPR since they often process personal data without taking data protection principles into account. In this work, we first examine the GDPR regarding the resulting requirements for SIEM systems. On this basis, we propose a SIEM architecture that meets the privacy requirements of the GDPR and show the effects of pseudonymization on the detectability of incidents.

We introduce the notion of Protean Signature schemes. This novel type of signature scheme allows to remove and edit signer-chosen parts of signed messages by a semi-trusted third party simultaneously. In existing work, one is either allowed to remove or edit parts of signed messages, but not both at the same time. Which and how parts of the signed messages can be modified is chosen by the signer. Thus, our new primitive generalizes both redactable (Steinfeld et al., ICISC ’01, Johnson et al., CT-RSA ’02 & Brzuska et al., ACNS ’10) and sanitizable signatures schemes (Ateniese et al., ESORICS ’05 & Brzuska et al., PKC ’09). We showcase a scenario where either primitive alone is not sufficient. Our provably secure construction (offering both strong notions of transparency and invisibility) makes only black-box access to sanitizable and redactable signature schemes, which can be considered standard tools nowadays. Finally, we have implemented our scheme; Our evaluation shows that the performance is reasonable.

Application development for the cloud is already challenging because of the complexity caused by the ubiquitous, interconnected, and scalable nature of the cloud paradigm. But when modern secure and privacy aware cloud applications require the integration of cryptographic algorithms, developers even need to face additional challenges: An incorrect application may not only lead to a loss of the intended strong security properties but may also open up additional loopholes for potential breaches some time in the near or far future. To avoid these pitfalls and to achieve dependable security and privacy by design, cryptography needs to be systematically designed into the software, and from scratch. We present a system architecture providing a practical abstraction for the many specialists involved in such a development process, plus a suitable cryptographic software development life cycle methodology on top of the architecture. The methodology is complemented with additional tools supporting structured inter--domain communication and thus the generation of consistent results: cloud security and privacy patterns, and modelling of cloud service level agreements. We conclude with an assessment of the use of the Cryptographic Software Design Life Cycle (CryptSDLC) in a EU research project.

Sanitizable signature schemes (SSS), as well as redactable signature schemes (RSS), gained a lot of attention in the recent past. In a nutshell, both types of signature schemes allow to alter signed data in a controlled way by a, potentially semi-trusted, third party. The resulting signatures still verify. Thus, the authenticity of the subsequently modified content is preserved. In this position paper, we discuss the state-of-the-art, and highlight potential future research opportunities. We hope this work gives rise to additional ideas, real-life use-cases, and interesting upcoming research, helping to bring both primitives into practice. Hence, this paper is meant as a starting point for readers interested in these primitives, looking for new research and application opportunities. In other words, we think that both primitives deserve further attention.

In this paper, we measure the overhead in message size and in firmware code-size for exchanging signed messages with constrained devices typically found in the Internet-of-Things (IoT) domain. The application of digital signatures on every important message in the IoT helps to increase its resilience against attacks and increases the data quality level. Other papers have shown that Elliptic Curve Cryptography (ECC) signatures can be applied on modern constrained devices. Our focus is on message size as we identified this to be the most prevailing problem as it relates to the storage required at each handling node and directly relates to the communication overhead, which in turn results in an increased energy consumption. We give analytical information for typical message sizes in two different protocols (MQTT and COAP), as well as real measurements on a Zolertia ReMOTE when it comes to firmware code-size overheads. Our measurements indicate that a suitable encoding of message level security can decrease the message overhead of signatures by at least 30 percent and still balance its usability by keeping it decodable into JSON, the prevailing exchange format of many IoT upper layer protocols. Our new HYBRID format is suitable to achieve end-to-end, i.e., device-to-application, integrity.

Sanitizable signatures are a variant of digital signatures where a designated party (the sanitizer) can update admissible parts of a signed message. At PKC ’17, Camenisch et al. introduced the notion of invisible sanitizable signatures that hides from an outsider which parts of a message are admissible. Their security definition of invisibility, however, does not consider dishonest signers. Along the same lines, their signer-accountability definition does not prevent the signer from falsely accusing the sanitizer of having issued a signature on a sanitized message by exploiting the malleability of the signature itself. Both issues may limit the usefulness of their scheme in certain applications.