Security protocols define how Security primitives are used in order to accomplish a secure channel between two or more communicating partners
Goal is more than just encrypting the data
Computers require formal rules in order to operate.
Protocol consists of several steps.
There is beginning and end for protocol
Protocol has to be unambiguous
Each step in protocol has to be defined
Protocol has to be complete
There has to be specific action for all possible situations
All participants in the protocol has to know it and follow it.
Formalized protocols can be analyzed and testes for security flaws
test of different inputs in different steps and see reactions
Goals for security protocols
Eavesdropping should be prevented
None of the participants should not be able to cheat
Participants should not be able to do anything else than what has been defined in protocol
Participants should not learn about each other more than what protocol states
If protocol is designed to provide real anonymity, there shouldn't be any long term identifiers.
Players in protocols
Protocol relies on arbitrator e.g. Trusted third party
Example protocol: Kerberos
not have any own interest on the matter.
be trusted in all cases at the protocol.
be trusted by everyone.
Real world example:
A is selling car to B whom he do not know at all. B wants to pay car with check.
Problem: A do not trust keys to B before the check is validated and B do not trust check to A without getting car keys.
A gives keys to abritrator (e.g. lawyer, T)
B gives check to A
A stores the check
When check is validated T gives keys to B
If check is invalid, A proves this to T and T gives keys back to A
Problems in arbitrated protocols
How to find Trusted thirt party
Mutually trusted party
Cost of arbitration
Delay from arbitration
Arbitrator have to deal every transaction
Single point of failure
Target for attacker
Arbitration is used only on special cases
Protocol can be divided into two subprotocols
Arbitrated protocol, which is called in special circumstances, adjudicator acts as arbitrator
Party that has no own interest on issue
Not directly involved in protocol
called only to resolve whether protocol was performed fairly.
A and B create a contract and sign it
When problem arises
A and B go to adjudicator
Both show their evidence
Adjudicator makes decision
Adjudicated protocol do not prevent cheating but it allows way to detect it.
There is trust that both parties are honest
In good protocol Adjudicator can determine also who cheated
Self enforcing protocols
Best type of protocol
The protocol itself quarantees fairness and security
No need for arbitrator or trusted parties
No disputes to settle
If one party tries to cheat the other party notices it and protocol stops
Not possible to create for all cases
Targets of attacks against protocols
Used algorithm and primitives
Encryption algorithm, hash function
Used security technique
Random number generation.
Implementation of algorithms
Shannon definition of good encryption algorithm (1949)
1 The amount of secrecy needed should determine the amount of labor appropriate for the encryption and decryption
Even simple cipher may be strong enough to deter the casual interceptor for a short time
2 The set of keys and the enciphering algorithm should be free from complexity
The algorithm should not restrict the selection of key
All keys should be equally secure
The algortihm should not give restrictions to plaintext either
3 The implementation of the process should be as simple as possible
It is easier to make mistakes when implementation is complex (this was especially important when encryption was mostly done by hand)
Complex algorithms will easily slow down the operation
4 Errors in ciphering should not propagate and cause corruption of further information in the message
This was important rule on time when encryption and decryption was done by hand.
Currently this is important on time critical communication systems, where retransmissions are not feasible e.g. live interviews.
5 The size of the enciphered text should be no larger than the text of the original message
Encrypted message does not carry more information than original message, but longer message gives more data for cryptoanalyst to analyse
Knudsen classification for algorithm break
Lars Knudsen PhD thesis 1994
Attacker finds Key k so that
Cryptoanalyst finds another algorithm that can be used instead of the original one
Analyst can find the plaintext from an instance but not the key
Analyst gets some information about key or the plaintext.
cannot be broken no matter how much ciphertext the cryptoanalyst can obtain
OTP is only unconditionally secure algorithm
all the others can be broken by Brute-force
Cannot be broken with available resources, now or in the future.
unless something ground breaking happens in computing
Currently used algorithms are computationally secure
Measuring the hardness of breaking
How much data is required to conduct the attack
Time needed to breaking the system
required amount of work
How much processing memory is required
How much other storage space is required
Basic assumption is that encryption algorithm is known
1. Ciphertext-only attack
Analyst sees only the ciphertext and tries to find out key and plaintext
Protocol should be designed so that the cryptoanalyst is forced for this type of attack
not always possible
Some sources use cipher-text only attack as an attack where even the encryption algorithm is not known
2. Known-plaintext attack
Cryptoanalyst knows something about the encrypted plaintext
Goal is to find the key that is used for encryption of several documents
Headers, templates or even whole documents
3. Chosen-plaintext attack
Attacker can select what will be encrypted and uses that for analysis
4. Adaptive-chosen-plaintext attack
Attacker can make smaller changes to data that will be encrypted based on the result
No-one is looking whether the data that will be encrypted makes sense
5. Chosen ciphertext attack
Cryptoanalyst can select the data that will be decrypted and see the result
tamperproof hardware solutions
works mainly on asymmetric cryptography
6. Chosen-key attack
cryptoanalyst has some knowledge about the relationship between generated keys
7. Rubber-hose cryptoanalysis
Threaten, blackmail, bribe (purchase key)
Passive attacks against protocol
Follow the protocol behavior in order to get additional informatio
e.g. Password sniffing
Hard to notice
Preventing easier than detecting in many cases.
Hard to decide which information requires protection
Active attacks against protocol
Goal is to change the protocol behaviour for attackers benefit
Adding a new message in communication
Resending earlier message or repeating same message several times
Breaking communications links
Changing stored data.
Pretend to be someone else in protocol
Outsider pretends to be A
A pretends to be T
M pretends to be A to B and B to A
Legal partner on protocol
Do not follow the protocol as the protocol states
Passive attacker tries to get more information with protocol than he is allowed to
e.g. attack against zero knowledge protocols (see authentication lectures)
Sending illegal messages
Co-operation of two partners against third one
Even if the protocol and used algorithms are secure the implementation may open up flaws.
Most of the security vulnerabilities are in fact due bad implementation and not a flaw in protocol or algorithm.
Transmitted data not verified
e.g. SQL injection attack
Automatic encryption or signing of any data
Flaw in generated authentication key
Key is not really random
Netscape 1.1. generated 128 bit encryption key, which entropy was equal to 20 bit key, due bad implementation
Key is based on lesser entropy source
password based keys: while 8 bits is used to describe one letter, the entropy is far from the 8 bits. (you can produce roughly 100 different values from keyboard, while full 8 bit can be used to represent 256 different values)
misuse of primitive
CBC-MAC used as hash via publishing key.
use of common IV rather than random one.
Assumptions on security and trust
Protocols have usually designed to have some assumptions that has to be filled for being secure
e.g. If there is no authentic time available, then protocols based on authentic times are not secure.
Secure as long as no-one has access to hardware
Secure as long as no-one is able to get to harddrive and change the keys
Secure as long as Trent can be fully trusted.
Or administrator is trustworthy
or communicating partners are trustworthy
Secure as long as no-one can eavesdrop the communication
Closed systems may rely that their fiber cannot be eavesdropped.
Secure as long as the public keys are authentic
Protocol may not define authentication of public keys, so that has to be done separately.'
Wireless communication have different requirements than wired
Think what assumption you can make in your intended environment and what can you trust on.