Biblio

The complete digitization of telecommunications allows new attack scenarios, which have not been possible with legacy phone technologies before. The reason is that physical access to legacy phone technologies was necessary. Regarding internet-based communication like voice over the internet protocol (VoIP), which can be established between random nodes, eavesdropping can happen everywhere and much easier. Additionally, injection of undesirable communication like SPAM or SPIT in digital networks is simpler, too. Encryption is not sufficient because it is also necessary to know which participants are talking to each other. For that reason, the research project INTEGER has been started with the main goals of providing secure authentication and integrity of a VoIP communication by using a digital signature. The basis of this approach is the Trusted Platform Module (TPM) of the Trusted Computing Group (TCG) which works as a hardware-based trusted anchor. The TPM will be used inside of wireless IP devices with VoIP softphones. The question is if it is possible to fulfill the main goals of the project in wireless scenarios with Wi-Fi technologies. That is what this contribution aims to clarify.

A nonrepudiation protocol from party S to party R performs two tasks. First, the protocol enables party S to send to party R some text x along with a proof (that can convince a judge) that x was indeed sent by S. Second, the protocol enables party R to receive text x from S and to send to S a proof (that can convince a judge) that x was indeed received by R. A nonrepudiation protocol from one party to another is called two-phase iff the two parties execute the protocol as specified until one of the two parties receives its complete proof. Then and only then does this party refrain from sending any message specified by the protocol because these messages only help the other party complete its proof. In this paper, we present methods for specifying and verifying two-phase nonrepudiation protocols.

A nonrepudiation protocol from a sender S to a set of potential receivers \R1, R2, ..., Rn\ performs two functions. First, this protocol enables S to send to every potential receiver Ri a copy of file F along with a proof that can convince an unbiased judge that F was indeed sent by S to Ri. Second, this protocol also enables each Ri to receive from S a copy of file F and to send back to S a proof that can convince an unbiased judge that F was indeed received by Ri from S. When a nonrepudiation protocol from S to \R1, R2, ..., Rn\ is implemented in a cloud system, the communications between S and the set of potential receivers \R1, R2, ..., Rn\ are not carried out directly. Rather, these communications are carried out through a cloud C. In this paper, we present a nonrepudiation protocol that is implemented in a cloud system and show that this protocol is correct. We also show that this protocol has two clear advantages over nonrepudiation protocols that are not implemented in cloud systems.

Web Services can be invoked from anywhere through internet without having enough knowledge about the implementation details. In some cases, single service cannot accomplish user needs. One or more services must be composed which together satisfy the user needs. Therefore, security is the most important concern not only at single service level but also at composition level. Several attacks are possible on SOAP messages communicated among Web Services because of their standardized interfaces. Examples of Web Service attacks are oversize payload, SOAPAction spoofing, XML injection, WS-Addressing spoofing, etc. Most of the existing works provide solution to ensure basic security features of Web Services such as confidentiality, integrity, authentication, authorization, and non-repudiation. Very few of the existing works provide solutions such as schema validation and schema hardening for attacks on Web Services. But these solutions do not address and provide attack specific solutions for SOAP messages communicated between Web Service. Hence, it is proposed to provide solutions for two of the prevailing Web Service attacks. Since new types of Web Service attacks are evolving over time, the proposed security solutions are implemented as APIs that are pluggable in any server where the Web Service is deployed.
 

According to a 2011 survey in healthcare, the most commonly reported breaches of protected health information involved employees snooping into medical records of friends and relatives. Logging mechanisms can provide a means for forensic analysis of user activity in software systems by proving that a user performed certain actions in the system. However, logging mechanisms often inconsistently capture user interactions with sensitive data, creating gaps in traces of user activity. Explicit design principles and systematic testing of logging mechanisms within the software development lifecycle may help strengthen the overall security of software. The objective of this research is to observe the current state of logging mechanisms by performing an exploratory case study in which we systematically evaluate logging mechanisms by supplementing the expected results of existing functional black-box test cases to include log output. We perform an exploratory case study of four open-source electronic health record (EHR) logging mechanisms: OpenEMR, OSCAR, Tolven eCHR, and WorldVistA. We supplement the expected results of 30 United States government-sanctioned test cases to include log output to track access of sensitive data. We then execute the test cases on each EHR system. Six of the 30 (20%) test cases failed on all four EHR systems because user interactions with sensitive data are not logged. We find that viewing protected data is often not logged by default, allowing unauthorized views of data to go undetected. Based on our results, we propose a set of principles that developers should consider when developing logging mechanisms to ensure the ability to capture adequate traces of user activity.