Security

Note on 23 Jul 2002
Why is Security?
  • Authentication (may include authorisation)
  • Integrity
  • Privacy --> can the password easily break
  • Non-repudiation --> dishonest (e.g. buy things from net, endup said never bought)
Threats
  • Eavesdropping
  • Masquerading
  • Message tampering
  • Interuption
  • Replaying
Encryption
  • Most wellknown aspect of security
  • Obsfucate the message via some means of reversibly changing the characters in that message
Simple Cipher
  • Often known as Ceasar ciphers
  • Displace each character by a given amount
  • Very simple - trivial to break
Block ciphers
  • Simple ciphers are to easy
  • Even if the cipher uses a random permutation of key, regularities in English mean that it is easy to break.
  • Better solution is to use a block substuition (e.g. DES)
  • Even better is to do substitution multiple times (e.g. 3DES)
Stream Cipher
  • Problem occurs when data is coming in byte/bit at a time (e.g. streaming data)
  • Can buffer and use block or use a stream cipher
  • Stream cipher works similar to block cypher, but can not allow multiple encodings.
  • Cipher still needs to be able to perturb two characters that are the same, to diiferent values
Symetric encryption
  • The same key is used to encrypt and decrypt the information
  • Tp=Dk(Ek(Tp))
  • Can be done as a block or stream cipher
  • Quick
  • Problem of key distribution
  • One time pad
Asymetric encryption
  • Main problem with symetric key is key distribution
  • One solution to this is to have 2 keys
    • public key - used for encryption, can be freely distributed
    • private key - used for decryption, must be kept secure
  • Known as public key, or asymetric key
  • Relies on a trap-door function to maintain security
  • NB Keyspace for asymetric keys is generally much smaller than keyspace for symetric keys
Session keys
  • Problem is asymetric is slow, symetric is insecure
  • Possible to combine both to give best of both worlds.
    • encrypt message with symetric key
    • encrypt symetric key with asymetric key
    • append ciphertext of symetric key to message
  • Symetric key is then known as a session key
  • If coomunication is in the context of a dialogue, it maybe possible/desirable to re-use session key.
Key distribution
  • How do we distribute public keys?
  • Need some way of preventing "Man in the middle" attacks
  • Use of
    • Key Signing
    • Certification Authorities
    • Web of trust
  • Must have some way of revoking a key
Man-in-the middle attack
Digital signatures
  • Way of marking a document so that it other people can verify who "signed" it
  • Problem of copying - must tie signature to document
  • Common way is to use private key to produce a hash (e.g MD5 SHA) of the document
  • Hash is then encryped with signers private key
Certification Authorities & Wed of trust
  • Web of trust
    • Alice knows Bob and knows that this key is Bob's, so Alice signs Bob's key
    • Cindy knows and trusts Alice
    • Cindy sees Alice's signature on Bob's key and trusts that this is Bob's key
    • David knows Alice, but doesn't think that she is very reliable
    • David sees Alice's signature on Bob's key and trusts that it probably came from Bob, but has some doubt
  • Large key signers are known as Certificate Authorities, or Trusted Third Parties (e.g. Verisign, Thawte)
PGP/GPG
  • Commercial system - Pretty God Privacy - Phil Zimmermann
  • Open Source - Gnu Privacy Guard
  • Very commmon Asymetric encryption system
  • Uses
    • 3DES, CAST, AES/Rinjndeal, Blowfish or Twofish foe session key
    • DSA & RSA for public key
  • Integrates with many email clients, web browsers, etc
  • PGP has facility to secure a TCP connection
Replay attack
Preventing the replay attack
  • Cannot rely on timestamp produced by sender (why not?)
  • Need to have
    • Trusted timestamp
    • Timestamp encoded in the message
  • Trusted timestamp is normally produced by trusted third party and contains
    • Signed hash of the document with current time
    • Details of previous document
    • Identifier of next timestamp
  • Timestamps are published periodically to public domain
Secure Channels
  • In distributed computing, interest is often not in securing messages, but in securing channels
  • Cannot use pure asymetric (too low) or pure symetric (key distribution) - need to use session keys
  • Need authentication of both sides of the communication
TCP/IP security
  • IPv4 has security option, but never used
  • IPv6 has security option which will be used, but is not yet implemented
  • IP is insecure - easy to fake IP addresses
  • TCP is often insecure (ISN's are often not random enough)
  • None of the TCP/IP protocol's ensure confidentiality
The Mitnick Attack
SSL
  • Go back to ISO model and introduce a Session Layer
  • Session Layer handles authentication and (en/de)cryption of information
  • Most commonly used is Secure Socket Layer
  • SSL provides for
    • Server Authentication
    • Client Authentication(if necessary)
    • Secure communication channel
  • Can use RSA, KEA or SKIPJACK for key exchange
  • Can use DES, 3DES, DEA, MD5, RC2, RC4 & SHA-1 for encryption & signing
  • Limited by US export laws
SSL handshake
  • The client sends the server the client's SSL version number, cipher settings, randomly generated data, and other information the server needs to communicate with the client using SSL.
  • The server sends the client the server SSL verion number, cipher settings, randomly generated data, and other information the client needs to communicate with the server over SSL. The server also sends its own certificate and if the client is requesting a server resources that requires client authentication, requests the client's certificate.
  • The client uses some of the information sent by the server to authenticate the server (see Server Authenticate for details). If the server cannot be authenticated, the user is warmed of the problem and informed that an encrypted and authenticated connection cannot be established. If the server can be successfully authenticated, the client goes on to Step 4.
  • Using all data generated in the handshake so far, the client (with the cooperation of the server, depending on the cipher being used) creates the premaster secret for the session, encrypts if with the server's public key (obtained from the server's certificate, sent in Step 2), and sends the encrypted premaster secret to the server.
  • If the server has requested client authentication (an optional step in the handshake), the client also signs another piece of data that is unqiue to this handshake and known by both the client and server. In this case the client sends both the signed data and the clients own certificate to the server along with the encrypted premaster secret.
  • If the server has requested client authentication, the server attempts to authenticate the client (see Client Authentication for details). It the client cannot be authenticated, the session is terminated. It the client can be successfully authenticated, the server uses its private key to decrypt the premaster secret, then performs a series of steps (which the client also performs, starting from the same premaster secret) to generate the master secret.
  • Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchange during the SSL session and to verify its integrity-that is, to detect any changes in the data between the time it was sent and the time it is received over the SSL connection
  • The client sends a message to the server informing if that future messages from the client will be encrypted with the session key. It then send a separate (encrypted) message indicating that the client portion of handshake is finished
  • The server send a message to the client informing it that future messages from the server will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the server portion of the handshake is finished.
  • The SSL handshake is now complete, and the SSL session has begun. The client and the server use the session keys to encrypt and decrypt the data they send to each other and to validate its integrity.
SSL with multiple connections
  • SSL needs to be setup for every single TCP connection
  • Not ideal for constant internet traffic
  • Need mechanism for encoding all information coming out of machine
VPN
  • Virtual Private Networks
  • All traffic through VPN is encrypted, and then tunnelled over IP based protocols
  • Main protocols are
    • SSL over PPP
    • PPTP
    • IPSEC
    • FWZ
  • Normally used on gateway routers of sites
Tunneling
SSL over PPP
  • Only one channel used
  • SSL is used to create a secure channel (often using SSH)
  • PPP is used to funnel all information through SSL communication
  • Easy to setup, but not optimised for large amounts of traffic
  • Harder to run in split site mode
PPTP
  • Point to Point Tunneling Protocol
  • Next step up from SSL over PPP
  • Optimised for LAN traffic
  • Uses 2 channels
    • TCP 1723 for line management, connection setup, etc.
    • GRE (Generic encapsulation protocol) for data
  • Known security issues
IPSec
  • Most common form of enterprise VPN
  • Uses 2 (or more) channels
    • UDP 500 for key exchange
    • one or more AH (RFC 2402) or ESP (RFC 2406) channels for data
  • Problems with IP masquerading
  • Easily(ish) implemented in hardware
DOS & DDOS
  • Denial of service - often exploits bugs to crash services
  • Need to make sure that
    • no bugs
    • Resurection script
  • Distributed Denial of Service - lots of demands on service
  • Difficult to distinguish between legitimate load and DDOS (slashdot affect)
  • Needs to be taken care of by undelying network
Issues
  • Is underlying hardware secure?
  • Is underlying software secure?
  • Is underlying network secure?
  • Will access to your code defeat security?
  • Client authentication
  • Cost
Summary
  • Need encryption to preserve privacy
  • Signatures can provide us with authentication, integrity and non-repudiation
  • Signatures also facilitate a web of trust and help prevent man in the middle attacks
  • Symetric key is fast, but key distribution is a big issue
  • Asymetric key is slower, but gives better key distribution
  • Session keys give us the best of both worlds
  • Time stamping is essential tp prevent replay attacks
  • TCP/IP is not secure - can use SSL to secure individual connection, or VPN's to secure network links

Comments

Post a Comment

Popular posts from this blog

The Network Layer

Image
Note on 22 Jul 2002 Properties and Services The network layer normally offers one of the following services to the transport layer Connection-oriented Connectionless Network layers are designed with the following goals in mind To provide services independent of subnet technology To shield the transport layer from the number, type & topology of the subnets present To use a uniform addressing scheme across both LAN & WAN Virtual Circuits Used in connection oriented services Whenever two machines wish to communicate - a route from source to receiver is setup and remembered Advantages easy congestion control quick to parse subsequent packets Disadvantages setup time vulnerable to crashes Datagrams Used in connectionless oriented services Everytime a packet is sent out, a new route maybe chosen Advantages robust no initia
Read more

The Transport Layer

Image
Note on 22 Jul 2002 Services provided Goal of the transport layer is to provide efficient reliable & cost effective service to higher levels (normally applications) Normally provides connection oriented & connectionless services Functions in a similar manner to network layer QoS Another way of looking at transport layer is that it's primary function is to enhance the "Quality of Service" of the network layer What exactly good is, is best left up to the user Connection establishment delay Connection establishment failure probability Throughput Transit delay Residual error ratio Protection Priority Resilience Transport Service primitives Many programs & programmers use transport layer so primitives must be easy to use and understand Primitive PDPU sent Meaning LISTEN none Block until some process tries to connect CONNECT CONNECTION REQ. Ac
Read more