Presentation on theme: "The Agent Based Crypto Protocol The ABC-Protocol by Jordan Hind MSE Presentation 1."— Presentation transcript:
The Agent Based Crypto Protocol The ABC-Protocol by Jordan Hind MSE Presentation 1
Agenda ● Agents Agents Agents! ● The security of agents. ● Project Overview A high level view of the protocol. ● Requirements ● Project Planning ● Software Quality Assurance Plan ● The prototypes, and why they might be interesting.
Agents Agents Agents! ● Security agents are a new look at an old idea (daemons). A widely used security architecture. Usually running checks (often as root) and reporting back to a centralized location. Most use either Secure Socket Layer or a custom protocol.
Agents Agents Agents! Part 2 ● Mobile Ad-hoc Networks Being used in real life military applications. ● Mobile Agents. Mobile devices becoming used in everyday life. Inter-mobile device communication isnt a mobile ad-hoc network...yet. Agent to Agent communications are frequently insecure (PCS to PCS for example). Very often done with custom protocols.
The Security Of Agents ● They all have very similar requirements. Agent to Agent Communications Agent to Server Communications ● If these communications are not secure... Security agents are running commands as root! Evil hackers can insert their own commands. Military Catastrophy. Personal Identifiable Information (PII) is the new Identity Theft. Buying anything with your cellphone? Finding vulnerabilities is worth money!
Security Of Agents Part 2 ● Cryptography is hard to implment correctly in a protocol. Remember SSH protocol problems? Remember WEP protocol problems. Its not a simple add-on. ● Existing solutions like openSSL are great...but Something easier to use should exist. To offer realiable security, SSL is very conservative.
Project Overview ● An Application layer crypto protocol. We can offer security services up and down the stack.
Project Overview ● 3 Layers – Secure the session, authenticate, encrypt and send the data.
Requirements ● Agent type behavior was abstracted into the following.
Use Case 3.1.1 ● 3.1.1 Use Case 1: Transfer Data to an Agent ● Description – An agent may transfer large amounts of data to another agent. ● Specific Requirement – That the data be transferred without loss to a specific destination agent with a guarantee of privacy and authentication. ● Precondition – The data to be transmitted is pre-buffered, discrete and the destination is known and routable. ● Trigger – A function is called from the library.
Requirements Part 2 ● The student has only designed a few cryptographic applications. ● The student has attacked many. ● Let us use the attacks as requirements, and the mitigation of the attacks as the security requirements.
Mis-Use Case 3.2.1 ● 3.2.1 Misuse Case 1: Brute Force Key Search (Critical) ● Description: A brute force key search is an attacker attempting to decrypt information from the channel by attempting decryption keys in a volume fashion until a correct key is found. This is the default attack of any cryptographic system and by deterring other attacks it is the hope to push attackers into brute force searches. This is a defining point in the security guarantee, meaning that an attacker must perform an exhaustive key search over the field of the key length. This is a security algorithm’s best case scenario and an attacker’s worst case scenario.
Mis-Use Case 3.2.2 ● 3.2.2 Misuse Case 2: Eves Dropping (Critical) ● Definition – Eves dropping is simply an attacker listening on the channel. Any information the attacker can harvest about the data or applications in the channel defines the attacker’s success. ● Specific Requirements – Eves Dropping on the ABC-Protocol channel should not reveal any information about the application layer within the limits of the security guarantee.
Mis-Use Case 3.2.3 ● 3.2.3 Misuse Case 3: Man In The Middle Attack (Critical) ● Description – A man in the middle attack is defined by an attacker performing a proxy service to data flows from both hosts, replacing security negotiation information with its own information on both sides of the channel. By placing themselves in the middle of every security negotiation the attacker gains necessary keys to learn something about the underlying data or applications. ● Specific Requirements – A “man in the middle” attack should not reveal any information about the application layer, and should not have greater likelihood of success than an exhaustive search of the authentication key space.
Mis-Use Case 3.2.4 ● 3.2.4 Misuse Case 4: Replay Attack (Critical) ● Description – A replay attack is defined by an attacker recording a valid session and replaying the valid session against the receiving host at a later time. The receiving agent will accept the session data because the session is (was) valid in all respects. This is particularly damaging to agents receiving commands. ● Specific Requirements – No replay attacks should be successful with greater probability than a brute force attempt at the keys involved.
Mis-Use Case 3.2.5 ● 3.2.5 Misuse Case 5: Impersonation (Critical) ● Description – An impersonation attack is an attempt by a foreign agent to authenticate to an agent with invalid credentials. ● Special Requirements – No impersonation attack should be possible with greater probability than a brute force of the authentication key space.
Use Case 3.5.1 ● 3.5.1 Library Use Case (Critical) ● Description – A Use Case to describe the use of the deliverable development libraries and not the protocol within. The libraries will be compiled into agent based application and protocol code bases. ● Special Requirements 1– The library must offer a minimal set of functions to decrease mistakes during its use. ● Special Requirements 2– The library must provide an abstract interface to allow for backwards compatibility. ● Special Requirements 3- The library must provide the cryptographic and security functions transparent to the developer using the library.
Other Constraints Worthy of Mention. ● Exporting Strong Cryptography and cryptographic tools to sensitive countries is an exportation of munitions. (ksu.edu mirror ?) ● The security guarantee (in bits). ● The libraries should be built with free tools.
Cost Estimations... ● As discussed in the project plan (http://www.hick.org/~jhind/phase1/projectP lan.doc) a variety of COCOMO tools were used.http://www.hick.org/~jhind/phase1/projectP lan.doc Was 3 KLOC optimistic thinking ? ● If testing code is included, just one platform prototype has $ cat `find.` | wc -l 723 All the tools predicted an effort of about 6 months. ● One tool, sunset.usc.edu, even suggested a schedule which was useful in making the gant chart.
SQAP ● Documentation ● Reviews and audits. ** ● Tests ● Tools, Techniques and Methodologies. ● Clearly defined deliverables.
Prototypes ● One Linux prototype, one windows prototype. ● Both demonstrate the lowest and highest classes in the network stack. Low level network functions. The class the devoper will use is the highest class. The security properties take place between these, none of them exist yet.
Prototypes Continued ● Both compiled with g++ using make. The windows prototype requires the cygwin environment to do this, it does not require the cygwin dll to run. It can be freely copied to any windows box and linked against. ● Demo