Security Protocol

Home Up Security Protocol Secure Key Exchanges Architecture Overview

Table of Contents

 1.      Introduction

2.      Overview

3.      Requirements of the Protocol

4.      Conclusion






1. Introduction

                                     This document is intended to set the requirements for a generic security protocol by means of which two parties can communicate with each other securely and privately, ensuring the integrity of the messages passed.

The document only sets down the requirements of such a desired robust protocol: it does not describe any such protocol itself.  The ground for the scenario is described and hence the capabilities of the attacker.

2. Overview

 2.1 Purpose of the Protocol

                       The intention of the protocol is its usage in lieu of wireless networks for secure mutual authentication. However, it is expected that the protocol, when designed / modified from an existing one, shall be as useful in the wired domain as in the wireless domain. The reason for mentioning the purpose of the protocol is that the protocol shall be specifically tailored for the wireless domain.

2.2 Situation under consideration

                       In particular, the context in which the protocol shall be deployed assumes a scenario in which there are a number of wireless devices in the network under consideration. Most of these devices are initially assumed to be Laptop devices were wireless Ethernet cards are expected to provide connectivity. Te utility of the protocol is to provide the user with a secure channel to communicate to another location, be it another wireless device or the main hub itself.  Te extension comes about by addition of wireless devices that aren’t prone to direct user interaction. Examples of such wireless devices are wireless cameras, projectors and other resources. The protocol requirements take no notice of such distinctions: it shall in fact encompass all possible devices.

2.3 Wireless Devices Implication

                       Stated below are the implications of having wireless devices of varying CPU and battery power in the network.  There are quite a few differences between the wired and the wireless domain. This section is more on the type of the wireless device rather than the fact that they are wireless: a difference, which should practically make no difference when the protocol is designed and deployed.

2.3.1 CPU power: Most of the Wireless devices are expected to have a very low CPU computing power. The implication of this is that these devices can’t really be expected to perform huge RSA type calculations very fast. The protocol design has to ensure the availability and proper usage of the wireless device. Hence, the protocol may, for instance mandate a certain very strong cryptographic scheme for a certain device and a relatively weak one for another device.

2.3.1.a Example: Here strong and weak have implications in the sense of usage and time constraint. A Laptop may engage in a session that is a few hours long and a wireless camera in a session that is a few minutes long. Hence, the “weak” cryptographic scheme may have key reusability duration of an hour or so, which is however safe enough for the wireless camera.

 2.3.2 Battery Power: The battery power of these devices is also limited: hence the devices are expected to be off and on intermittently (sleeping mode). This is closely related to the requirement with CPU power in the context of the protocol providing a differing message exchange scheme and/or cryptographic scheme (amongst other things ) dependent on the device.

2.4 Security Properties to be considered

2.4.1 Confidentiality

2.4.2 Integrity (and closely related Authenticity)

2.4.3 Availability: Apart from 2.4.1 and 2.4.2 that are generic and the most common properties, availability is made a “property” in the wireless domain. With “2.3 Wireless Devices Implication” in mind, this simply means that the wireless device shall be in full utility with the protocol in place as it would have been without. On the design scale, the implication is that the protocol shall not impose a load on the device so much as to reduce its functionality.


2.5 Conventions and symbols used

                         As is usual in most papers, we say that Alice and Bob are the parties, which communicate, and Eve in the attacker in the middle. Further conventions and symbols shall be introduced as and when the need arises.

 3. Requirements of the Protocol

The section below now represents the situation in which the protocol has to operate. The single line statement of the protocol requirements is “To ensure the satisfaction of all the security properties in face of such a situation”.


3.1 Communication Model

           The following communication model is assumed for the underlying layer. Alice and Bob communicate over and insecure channel that, for all practical purposes shall be controlled by Eve. Eve has at her disposal al the facilities that Alice and Bob posses.

3.1.1 Channel control: Eve can read all the messages that pass through the channel (Messages in the sense of the underlying bits or the information that is actually traversing the channel)

3.1.2 Message modification / Delay: Eve can modify the messages traversing the channel or delay them by any time scale as is needed to subvert any clock granularity that is in use.

3.1.3 Message generation: Eve can of course generate and send any message to Alice and Bob as and when she wishes.

The primary requirement of the protocol shall be to ensure secure and reliable communication in spite of Eve having all the control(s) described above.

3.2 State of Alice and Bob

3.2.1 Zero Knowledge Systems

                       Alice and Bob shall have no knowledge of each other initially. This is not to say that Alice and Bob do not know each other. They haven’t met before to have a shared secret between them. (Note that this state is true only of 2 parties trying to communicate with each other in the presence of a third part: this scenario mostly applies to two wireless users communication with each other without knowing each others credentials)

3.2.2 Parallel Sessions

                       Alice and Bob, as expected are mostly computers / devices. Eve shall be able to open multiple sessions with both Alice and Bob simultaneously. Also, these multiple sessions of Alice and Bob cannot communicate with each other. Eve shall be able to engage them into any protocol conversation, with the possibility of using the information obtained in one session in another. (Note that the actual protocol may not allow this, but it is required of the protocol design that despite a possibility of multiple sessions, security concerns are met)

3.3 Stand Alone Protocol Requirements

3.3.1 Other Protocol Interactions

                       Eve shall be able to convince Alice and Bob to engage in other stand Alone safe protocols, in as many sessions as is possible/required.  This raises the possibility of a chosen protocol attack. It is expected of the protocol to withstand such attacks: A reference is given for the design principles for avoiding the “chosen protocol attack”.

3.3.2 Perfect Forward Secrecy

                       This simply means that the disclosure of a password does not in any way compromise or reveals prior recorded conversations.  This is a requirement in the extreme case of an inadvertent password disclosure that may occur beyond the protocol interactions. Hence the protocol is expected to ensure forward secrecy i.e. the disclosure of a password shall not reveal previous conversations.

3.3.3 Password guessing Attacks

                       The protocol shall protect itself from any password guessing attacks (Plain cipher text attacks and offline guessing attacks). It shall also hopefully protect itself from database exposure attacks (as in Lamports hash Algorithm), although it is recognized that database exposure isn’t actually the function of the protocol itself strictly.

3.3.4 Transitivity of Trust

                       The protocol shall not allow any transitivity of Trust. By Transitivity of Trust, it is meant that a user can engage in a session with another user, but a third party has to go through the normal process of a protocol interaction. The third party, on the basis of an interaction with one of the two parties currently in a session shall not automatically engage into a session with the other party in the established session.

3.3.5 Transient Security

                       This is more in the context of the wireless devices mentioned before. It is required of the protocol to enable all the security properties when the devices / users are intermittently on and off. This is more in the context of saving power and recognizing the fact tat the CPU power on the devices is limited. This assumes significance as the protocol can’t assume a 10-message exchange for mutual authentication and later have the session expire in 10 seconds.

5.   Conclusion

The document has presented the requirements of a security protocol to be used in lieu of a wireless network. This is a precursor to the other requirements, specifications and design documents for the protocol and other issues needed to make the entire wireless domain