CT30A8800 Secured communications

Pekka Jäppinen

• 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

• 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.

• Protocol relies on arbitrator e.g. Trusted third party
  • Example protocol: Kerberos
• Arbitrator should:
  • 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.

• Arbitrated solution:

1. A gives keys to abritrator (e.g. lawyer, T)
2. B gives check to A
3. A stores the check
4. 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

• How to find Trusted thirt party
  • Authentication required
  • Mutually trusted party
• Cost of arbitration
• Delay from arbitration
• Arbitrator have to deal every transaction
  • Bottleneck
  • Single point of failure
  • Target for attacker

• Arbitration is used only on special cases
• Protocol can be divided into two subprotocols
  • Nonarbitrated protocol
  • Arbitrated protocol, which is called in special circumstances, adjudicator acts as arbitrator
• Adjudicator
  • Party that has no own interest on issue
  • Not directly involved in protocol
    • called only to resolve whether protocol was performed fairly.

• Example:
  • A and B create a contract and sign it
  • When problem arises
  1. A and B go to adjudicator
  2. Both show their evidence
  3. 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

• 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

• Used algorithm and primitives
  • Encryption algorithm, hash function
• Used security technique
  • Random number generation.
• Implementation of algorithms
• Protocol itself

• 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

• Lars Knudsen PhD thesis 1994

1. Total Break
   • Attacker finds Key k so that
2. Global Deduction
   • Cryptoanalyst finds another algorithm that can be used instead of the original one
3. Instance Deduction
   • Analyst can find the plaintext from an instance but not the key
4. Information deduction
   • Analyst gets some information about key or the plaintext.

• Unconditionally secure
  • 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
• Computationally secure
  • Cannot be broken with available resources, now or in the future.
    • unless something ground breaking happens in computing
  • Currently used algorithms are computationally secure

• Data complexity
  • How much data is required to conduct the attack
• Prosessing complexity
  • Time needed to breaking the system
  • required amount of work
• Memory requirements
  • 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
  • e.g. email

• 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)

• Eavesdropping
  • 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
  • Headers
  • Traffic analysis

• Goal is to change the protocol behaviour for attackers benefit
• Adding a new message in communication
  • Removing/deleting messages
  • Substituting messages
• 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
• Man-In-the-middle attack
  • 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)
• Active attack
  • 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.

• 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.