Otway–Rees protocol

About: Otway–Rees protocol is a research topic. Over the lifetime, 1975 publications have been published within this topic receiving 40569 citations.

Cryptanalysis on “ESEAP: ECC-Based Secure and Efficient Mutual Authentication Protocol Using Smart Card”

Abstract: AbstractVery recently, ESEAP mutual authentication protocol was designed to avoid the drawbacks of Wang et al. protocol and highlights that the protocol is protecting all kind of security threats using informal analysis. This work investigates the ESEAP protocol in security point of view and notices that the scheme is not fully protected against stolen verifier attack and does not provide user anonymity. Furthermore, the same protocol has user identity issues, i.e., the server cannot figure out the user identity during the authentication phase. Later we discuss the inconsistencies in the security analysis of ESEAP presented by RESEAP.KeywordsCryptanalysisUser anonymityStolen verifier attack

A Non-interactive Dual-channel Authentication Protocol for Assuring Pseudo-confidentiality.

Abstract: We introduce a non-interactive dual channel authentication protocol and apply it to long distance communication for assuring pseudo-confidentiality, a criteria that prevents a malicious agent from exfiltrating information to unauthorized destinations Unlike previously proposed protocols that assume a manual (human-aided) or equivalent authenticated channel, our protocol utilizes a non-manual authenticated channel We analyze the security properties for a possible realization of this protocol and develop a prototype Through a Raspberry-Pi implementation, we show how the incorporation of the proposed scheme into the future design of keyboard interfaces may impact authentication practices 1 Non-interactive dual channel authentication protocols Non-interactive dual channel authentication protocols employ two channels and authenticate information r1 received through one presumably insecure channel using a piece of brief information r2 (computed from r1) received through the other presumably authenticated channel To remain lightweight these protocols employ one way communication from a message sender, Alice, to a message recipient, Bob It can be shown that in these protocols, imposters cannot authenticate themselves if, (i) only one of the channels is compromised or (ii) both channels are compromised but attacks on them are not coordinated Existing literature describes a family of non-interactive message authentication protocols (eg, [1, 2, 4, 3, 5]), known as NIMAPs, that use a manual (human-aided) authenticated channel In these protocols, a hash value for each message being sent is generated Alice then transmits This work is supported by AFOSR Grants FA9550-09-1-0479 and FA 9550-09-1-0165 the message and hash over the insecure and authenticated channels respectively to Bob In some protocols, a key is applied to the hash function when generating the hash value and this key is sent with the message over the insecure channel [3, 5] or with the hash value over the authenticated channel [2] NIMAPs assume that the authenticated channel is human-aided hence adversarial influence on this channel is significantly limited This assumption is sufficient for short distance communications requiring infrequent authentication of messages However, this limits their application in long distance communications (eg, over the internet) where frequent authentication is required and a human-aided authenticated channel is unrealistic and/or infeasible 2 Proposed protocol Replacement of the human-aided authenticated channel in NIMAPs erodes the security benefit assured by such a channel This exposes them (NIMAPs) to channel spoof attacks where an adversary, Eve, could spoof the identity of the authenticated channel when sending her authentication messages to Bob Because of the non-interactive nature of Figure 1 Proposed protocol (Generic) the protocol, Bob has no way to know whether these authentications are sent by Alice hence, he will accept a message if its authentication is valid (ie, it authenticates the message sent through the insecure channel) We address this issue by introducing the following: (i) we assign the task of Alice to a small hardware attachment that we assume not to be affected by a channel compromise, and (ii) we assume that it is difficult for the adversary, Eve to compute r2 given r1 Figure 1 presents the proposed generic protocol In this protocol, Alice is a hardware attachment to the keyboard with the following properties: (i) She has processing capabilities to parse typed keystrokes and apply a method generate to identify r1 and to compute r2 from r1; (ii) She only receives input from the keyboard; (iii) She sends output to Bob using two different channels (one is insecure that runs through the host and the other is authenticated that bypasses the host) Bob is a verifier program located in a remote computer In Figure 1 (and in subsequent protocol figures), the “′” added to information received by Bob indicates that the sent and received values might be different and the insecure and authenticated channels are represented by “→” and “⇒” respectively The protocol is designed based on the following assumptions: (i) an r2 can verify the associated r1; (ii) an adversary can generate an r1 or snoop the r1 generated by Alice but it is difficult for her to compute the associated r2 from a given r1; (iii) Bob can compute r2 from r1; (iv) r′ 1 is accepted only if (r′ 1, r′ 2) is consistent ie, r2b (the expected r′ 2 computed by Bob for the r′ 1 he received) is the same as r′ 2 Alice generates r1 and r2 from the keystrokes typed by a user and sends r1 through the possibly compromised host using the insecure channel and r2 directly to Bob using the authenticated channel When Bob receives r1 and r2 from Alice, he accepts r′ 1 only if (r′ 1, r′ 2) is consistent To defeat this protocol, Eve either; (i) waits for Alice to transmit an r1 and replaces r1 with r1eve and expects that it will be verified by the associated r2 (generated and transmitted by Alice), or; (ii) estimates an r2eve for her r1eve and transmits both of them to Bob pretending that the r2eve is transmitted over the authenticated channel (by spoofing the authenticated channel’s identity) Existing NIMAPs do not make assumption (ii), perhaps because of the challenge involved with its realization Instead, they assume that Eve cannot successfully use (or masquerade to be using) the manual authenticated channel These protocols can be defeated if the manual channel is replaced by a non-manual physical channel since Eve then can compute the right r2eve for her r1eve and masquerade as Alice 3 A hash based realization for assuring pseudo-confidentiality The exfiltration of information by a malicious agent from a compromised host to an external adversary can be restricted by blocking all access from the host to unauthorized destinations We refer to an authorized destination as a domain name/IP that: (i) has been typed at least once by a human user (establishing consent/approval), or (ii) has been returned in a response packet from an authorized destination We define pseudo-confidentiality as the security property satisfied when an adversary cannot exfiltrate information to unauthorized destinations Figure 2 Hash based realization A hash based realization of the proposed protocol assuring pseudo-confidentiality is shown in Figure 2 In this realization, the generate function used by Alice produces components rv and h rv is the destination (IP/domain name) of a request being made and h = HK(rv) is the hashed value of the requested destination This realization works in two phases as described below: (i) Initialization phase This is a one step setup process required prior to the establishment of the rest of the protocol During this phase, a human operator (i) informs Bob of the functions H and Ĥ used by Alice and (ii) initializes a K for Alice and Bob During the protocol phase, function H uses K as a parameter to produce h and function Ĥ is used to update K by both Alice and Bob Due to some failure or interruption in communication, if Alice and Bob do not have the same updated K, all destination requests will be rejected and the value of K will have to be re-initialized (ii) Protocol phase In this phase, components rv and h are transmitted from Alice to Bob via the insecure and authenticated channels respectively When Bob receives both r′ v and h′, he computes his own h using his K ie, h = HK(r v) and considers (r′ v, h ′) to be consistent if the received h′ = h The value of K is updated by both Alice and Bob using another function Ĥ Alice updates her K after sending h to Bob and Bob updates his K every time he receives an h′ #= ∅ from Alice and accepts r′ v Ĥ(K) transforms the value of K based on the current value of K to produce a new K During experimentation, we relax the definition of consistent by accepting requests to destinations that are (i) nontyped but had been authorized before and (ii) received in response to requests to authorized destinations, to improve the usability of the solution Security Analysis Bob accepts r′ v if (r′ v, h) is consistent for the current K (that Bob has knowledge of) Bob can be made to accept a request from Eve in the following cases: Case 1: Channel spoof attack A malicious agent, Eve, residing in the host, can no longer launch a channel spoof attack simply by sending her own rv and h to Bob if the K she uses for computing h (at a certain instance) is not what Bob is expecting Alice to use Since our assumption is that Eve has no knowledge of K, Alice can only expect that the K she is using matches with the K Bob is expecting For an n-bit K, the probability of such a match is 2−n Case 2: Second preimage Attack Eve can replace the destination rv generated by Alice with her own destination reve and expect that there exists a K ′′ such that H(rv,K) = H(reve,K ′′) A second preimage resistant hash function is relevant in our case because for a second preimage resistant hash function, given an input rv , it should be difficult for an adversary to find another input reve #= rv such that H(reve) = H(rv) If H is !s second preimage resistant (ie, !s is the probability of H(reve) = H(rv) occurring), then the probability of a successful attack is !s

A Design of User Authentication Protocol using Biometric in Mobile-cloud Environments

Abstract: Recently, usage of mobile cloud services has been increasing. In particular, beyond the constraints of a single cloud computing service, studies on the multi-cloud have been actively pursued. A user must authenticate multiple cloud service providers to use additional cloud services in a multi-cloud. In previous studies, an authentication method using single sign-on (SSO) was not available in all cloud services. Cloud services will not be available when the SSO server is not available due to malicious attacks, because all authentication is done via the SSO server. Additionally, using a broker, there is a vulnerability that can expose authentication information for the service provider to a user who did not sign up. In this paper, we propose a secure user authentication protocol using biometric authentication that does not expose user information when using additional cloud services. The proposed protocol can use a single biometric authentication for multi-cloud services without storing authentication information in each cloud service. In terms of key stability (to ensure stability through the key agreement process and the key area), by disabling various attack methods, such as man-in-the-middle attacks and replay attacks, we provide secure mobile cloud services.

Digital watermarking protocol security analysis based on Kailar logic

Abstract: As a security protocol, the security of watermarking protocol also requires formal analysis. After carefully studied an enhanced buyer-seller watermarking protocol, we improved its process for assurance of accountability. Then, according to Kailar Logic, we show that the improved protocol to achieving accountability. At last, complete proof results show that the formal methods of security protocol can successfully integrated into analyzing process for watermarking protocol.