Automated Cryptographic Analysis of the Pedersen Commitment Scheme

Aiming for strong security assurance, recently there has been an increasing interest in formal verification of cryptographic constructions. This paper presents a mechanised formal verification of the popular Pedersen commitment protocol, proving its security properties of correctness, perfect hiding, and computational binding. To formally verify the protocol, we extended the theory of EasyCrypt, a framework which allows for reasoning in the computational model, to support the discrete logarithm and an abstraction of commitment protocols. Commitments are building blocks of many cryptographic constructions, for example, verifiable secret sharing, zero-knowledge proofs, and e-voting. Our work paves the way for the verification of those more complex constructions.Comment: 12 pages, conference MMM-ACNS 201

Formal Analysis of ISO/IEC 9798-2 Authentication Standard using AVISPA

International audienceUse of formal methods is considered as a useful and efficient technique for the validation of security properties of the protocols. In this paper, we analyze the protocols of ISO/IEC 9798-2 entity authentication standard using a state-of-the-art tool for automated analysis named AVISPA. Our analysis of the standard using AVISPA's OFMC and CL-AtSe back-ends shows that the two party protocols are secure against the specified security properties while the back-ends are able to find attacks against unilateral and mutual authentication protocols involving a trusted third party

Information Assurance Protocols for Body Sensors Using Physiological Data

Griffith Sciences, School of Information and Communication TechnologyFull Tex

Formal Validation of Security Properties of AMT's Three-Way Handshake

Multicasting is a technique for transmitting the same information to multiple receivers over IP networks. It is often deployed on streaming media applications over the Internet and private networks. The biggest problem multicast introduces today is that it is an all or nothing solution. Every element on the path between the source and the receivers (links, routers, firewalls) requires multicast protocols to be enabled. Furthermore, multicast has a conceptual business model, and therefore is not an easy case to make. These factors, embedded deep in technology, but ultimately shaped by economics, led to a lack of multicast deployment. To address this problem, the AMT (Automatic IP Multicast without explicit Tunnels) specification has been developed by the Network Working Group at the IETF. This specification is designed to provide a mechanism for a migration path to a fully multicast-enabled backbone. It allows multicast to reach unicast-only receivers without the need for any explicit tunnels between the receiver and the source. We have formally validated the three-way handshake in the AMT specification using AVISPA against two main security goals: secrecy and authentication. We have demonstrated that the authentication goal is not met: an attacker can masquerade as an AMT relay, and the AMT gateway (at the end user) cannot distinguish a valid relay from an invalid one. Another attack was also found where an intruder can disconnect or shutdown a valid session for a valid end-user using a replay attack

A Lightweight Type System with Uniqueness and Typestates for the Java Cryptography API

Java cryptographic APIs facilitate building secure applications, but not all developers have strong cryptographic knowledge to use these APIs correctly. Several studies have shown that misuses of those cryptographic APIs may cause significant security vulnerabilities, compromising the integrity of applications and exposing sensitive data. Hence, it is an important problem to design methodologies and techniques, which can guide developers in building secure applications with minimum effort, and that are accessible to non-experts in cryptography. In this thesis, we present a methodology that reasons about the correct usage of Java cryptographic APIs with types, specifically targeting to cryptographic applications. Our type system combines aliasing control and the abstraction of object states into typestates, allowing users to express a set of user-defined disciplines on the use of cryptographic APIs and invariants on variable usage. More specifically, we employ the typestate automaton to depict typestates within our type system, and we control aliases by applying the principle of uniqueness to sensitive data. We mainly focus on the usage of initialization vectors. An initialization vector is a binary vector used as the input to initialize the state for the encryption of a plaintext block sequence. Randomization and uniqueness are crucial to an initialization vector. Failing to maintain a unique initialization vector for encryption can compromise confidentiality. Encrypting the same plaintext with the same initialization vector always yields the same ciphertext, thereby simplifying the attacker's task of guessing the cipher pattern. To address this problem practically, we implement our approach as a pluggable type system on top of the EISOP Checker Framework. To minimize the cryptographic expertise required by application developers looking to incorporate secure computing concepts into their software, our approach allows cryptographic experts to plug in the protocols into the system. In this setting, developers merely need to provide minimal annotations on sensitive data—requiring little cryptographic knowledge. We also evaluated our work by performing experiments over one benchmark and 7 real-world Java projects from Github. We found that 6 out 7 projects have security issues. In summary, we found 12 misuses in initialization vectors

Seve: Automatic tool for verification of security protocols

Master'sMASTER OF SCIENC