1 / 54

Encryption and Secure Computer Networks Brady Chen Andriy Baranskyy Trevor Owen (11.07.2006)

Encryption and Secure Computer Networks Brady Chen Andriy Baranskyy Trevor Owen (11.07.2006). Introduction: Distributed Computing & its Threats <-- Encryption Algorithms System Authentication Key Management Levels of integration Encryption Protocols Case Study: Process Level

feo
Download Presentation

Encryption and Secure Computer Networks Brady Chen Andriy Baranskyy Trevor Owen (11.07.2006)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Encryption and Secure Computer Networks Brady Chen Andriy Baranskyy Trevor Owen (11.07.2006)

  2. Introduction: Distributed Computing & its Threats <-- • Encryption Algorithms • System Authentication • Key Management • Levels of integration • Encryption Protocols • Case Study: Process Level • Network Mail • Digital Signatures

  3. Number and diversity of networks is rising • Number and diversity of applications is rising • Want to guarantee: • Privacy, Integrity, Security • Need Encryption

  4. Distributed computing has grown • Protection & Security of central systems =>Networks: • Lines are not secure • Switches not secure • Encryption for sending and storing data over unsafe media

  5. Two major challenges: • Develop suitable string encryption algorithms • Integrate encryption methods into O/S • But, what are the threats?

  6. Threats: • Tapping lines [loss of privacy] • Introduction of spurious messages [message is delivered as if its genuine] • Retransmission of previously transmitted valid messages • Prevention of delivery of valid messages • e.g. Military command comms, funds transfer.

  7. Introduction: Distributed Computing & its Threats • Encryption Algorithms <-- • System Authentication • Key Management • Levels of integration • Encryption Protocols • Case Study: Process Level • Network Mail • Digital Signatures

  8. Conventional Encryption: • E=F(D,K) • D=F'(E, K) • E cannot be understood without K • Alg. is known and used by everyone • Matched text – cannot deduce the key

  9. Strong Encryption Algorithms: • F masks statistical properties of cleartext • probability of any character- same • flat n-gram probability, even though there is a skewness in the cleartext • if a bit altered in cleartext, the p(ciphered alteration)=1/2 and vice versa. • Strength: length of key/length of data

  10. Public Key Encryption: • E=F(D,K), K-publicly known • D=F'(E,K'), K≠K' • Key generator => K & K' based on some input • F & F' are inverses (digital signatures & key management)

  11. Error Detection & Correction • Error detection vs correction – long stored data • Redundancy: p(unnoticed error)=1/2^k • Natural language text- redundancies already • Redundancy: error correction codes, but it can be deleted • Need high quality recovery algorithms

  12. Duplicate & Missing Blocks • Deliberate or Irregularity • Sequence #s • Block chaining: • receiver can check whether blocks arrived in proper order • if check fails, can't tell how many blocks missing • Need to get authentication protocol to choose new valid sequence # to restart block chaining.

  13. Block vs Stream Ciphers • Stream: can use entire preceding portion of message, key and current bits • Block: only have current bits and key • Stream encryption is stronger • BUT: updating portions of messages is easier with block encryption. Need to re-encrypt everything afterwards with stream ciphers • IBM - Lucifer (reasonably strong block cipher – precursor to DES). Demonstration>Demon>Lucifer

  14. Minimal trusted mechanism & minimum central mechanism. • Limitations of encryptions: • Revocation (re-encryption=> redistribution) (investigate more) • Modification not correction • Key management (many separate keys) • Processing of cleartext (decryption in CPU vs homomorphic encryption)

  15. Homomorphism • f(x•y)=f(x)•f(y) • Very useful! • Voting (able to cast vote secretly) • Private Information Retrieval (db) • Still no strong Algs => undesirable • Goldwasser-Micali (GM) Public Key encryption scheme

  16. Introduction: Distributed Computing & its Threats • Encryption Algorithms • System Authentication <-- • Key Management • Levels of integration • Encryption Protocols • Case Study: Process Level • Network Mail • Digital Signatures

  17. System Authentication • identification of one member of communication to the other in a reliable, unforgeable way • method for O/S to determine identity of user who is trying to log in: pwwd. Machine can identify itself • Mutual communication: cannot send passwords to each other • Pre-determined key value and timestamp is used: • A-->Ka • B-->K'a

  18. Introduction: Distributed Computing & its Threats • Encryption Algorithms • System Authentication • Key Management <-- • Levels of integration • Encryption Protocols • Case Study: Process Level • Network Mail • Digital Signatures

  19. Key Management • Matching key pairs are necessary for two or more participants to communicate securely in a network conversation • A matched pair of logical keys forms a logical channel • Two types of key distribution methods discussed; conventional and public key encryption systems

  20. Conventional Key Algorithm • A single secret key is used to encode/decode by all nodes involved in the secure communication • Keys must be distributed over the same channel as the data • Circularity is broken with limited prior distribution of a small number of keys by secure means • Typically done by designating a host machine or set of machines to play the role of the Key Distribution Centre (KDC)

  21. Centralized Key Control • The simplest distribution method using a single KDC for the entire network • If communication with the KDC becomes impossible; then further establishment of any further secure communication channels is not possible • Solution; redundant KDC’s in case of failure in the main facility • Other methods; Fully Distributed Key Control, Hierarchical Key Control

  22. Needham-Schröder Model of a Conventional Key Algorithm

  23. Public Key based Distribution Algorithms • Two Keys are used K and K’; K’ is not derived from K • Once a user A obtains a key pair <K, K’>, they can publicize K, K’ is used to decipher the encoded message • In a typical communication User B can send a message to A by using the publically available key K • A then uses its key K’ to decipher B’s message • Then A replies to B, using B’s public Key

  24. Public Key based Distribution Algorithms • This method appears not to need any central authority • This is incorrect, there must be an authority to look after bookkeeping of all the keys • Maintaining public key records must constantly be updated as keys change; due to a key being compromised or replaced after an extended period of time

  25. Model of Public Key Algorithm

  26. Comparison of Public and Conventional Key Distribution for Private Communication • Both protocols can establish a secure channel with a similar amount of overhead; this difference is trivial when considering the number of messages passed in a typical connection • The safety of these methods depends on the safety of the secret keys • The authors feel that there is a great deal of similarity between implementing these protocols

  27. Introduction: Distributed Computing & its Threats • Encryption Algorithms • System Authentication • Key Management • Levels of integration <-- • Encryption Protocols • Case Study: Process Level • Network Mail • Digital Signatures

  28. Levels of Integration • In a packet switched network one could encrypt each line between to switches separately from all other lines • This is a low level choice often called link encryption • Alternatively ends of the encryption channels could be chosen at higher architectural levels-at the host machines that are connected to the network • Here a msg is encrypted once it is sent through the network

  29. Levels of Integration • There could be an even higher level where individual processes are the endpoints • This method is known as end-to-end encryption

  30. Introduction: Distributed Computing & its Threats • Encryption Algorithms • System Authentication • Key Management • Levels of integration • Encryption Protocols <-- • Case Study: Process Level • Network Mail • Digital Signatures

  31. Encryption Protocols • Desirable characteristics of a protocol include: • Permitting channels to be dynamically opened and closed • Allows the traffic flow rate to be controlled • Provide reasonable error handling • All with a minimum of mechanism upon which the security of which the network depends • Should integrate well with the network protocols affecting them as little as possible

  32. Encryption Protocols • Fortunately the encryption channel can be managed independently of the communication channel;as a result many protocol questions can be ignored

  33. Confinement • To confine a program means to render it unable to communicate other than through the explicitly controlled paths • In computer networks confinement poses a difficult problem to solve; Since cleartext information is likely to be passed at some point during the network transfer; the information is susceptible to unauthorized access

  34. Confinement • Solutions to this problem; secure networks and software • Some confinement problems hard to solve because of the nature of the communication between processes, it is not always certain that an authorized party is dealing with the data

  35. Introduction: Distributed Computing & its Threats • Encryption Algorithms • System Authentication • Key Management • Levels of integration • Encryption Protocols • Case Study: Process Level <-- • Network Mail • Digital Signatures

  36. Case Study: Process-Process Level • Goal:Proved secure communication that does not involve application software in the security facilities, as well as to minimize amount of trusted bases. • Required: A protocol provides process-to-process channels and guarantees that it is not possible for application software running within the process to cause cleartext to be transmitted onto the network.

  37. Case Study: Process-Process Level U1 U2 Un NM NM’ U’n U’2 U’1 Processes Processes Software Kernel Software Kernel Hardware Hardware Network Interface Network Interface Encryption Unit Encryption Unit Data flow in process-to-process encrypted channels

  38. Case Study: Process-Process Level • Responsibilities of Software: • Establishing communications channels • Supporting retransmission when errors are detected • Controlling data flow rates • Multiplexing multiple logical channels on the single physical network connection • Assisting or making routing decisions • The modules which provide these functions are called the Network Manager (NM)

  39. Case Study: Process-Process Level • Encryption Unit: The operating system nucleus in each case has been augmented with new calls: • - Encrypt( channel name, data) • - Decrypt( channel name, data destination) • Whenever a process wishes to send an encrypted block of data, it issues the Encrypt call. The nucleus takes the data, causes them to be encrypted in the Encryption Unit.

  40. U1 U2 Un NM NM’ U’n U’2 U’1 • Case Study: Process-Process Level • Whenever a process wishes to send an encrypted block of data, it issues the Encrypt call. The nucleus takes the data, causes them to be encrypted in the Encryption Unit. Software Kernel Network Interface Network Interface Encryption Unit Encryption Unit

  41. U1 U2 Un NM NM’ U’n U’2 U’1 • Case Study: Process-Process Level • The Encryption Unit sends the encrypted text to the NM. If we assume that the NM knows what destination site is intended, it then can place a cleartext header on the encrypted block and send it out onto the network, to the another side of the NM. • The cleartext header is essential so that switching computers which typically make up a network can route the block appropriately Software Kernel Network Interface Network Interface Encryption Unit Encryption Unit

  42. U1 U2 Un NM NM’ U’n U’2 U’1 • Case Study: Process-Process Level • When the block arrives at the destination host computer, the network manager reads it in and strips off the header. It then tells the kernel the process for which the block is intended. • The kernel informs the process, which can issue a Decrypt call in Encrypted Unit, causing the data to be decrypted with the key previously arranged for that process Software Kernel Network Interface Network Interface Encryption Unit Encryption Unit

  43. Case Study: Process-Process Level • Possible Failures: • The network software in either of the host fails or decides not to open the channel, no kernel calls are involved and standard protocols operate • An Open function (Encryption Unit) may fail because the name x supplied was already in use • An protection policy check was not successful • The kernel table was full

  44. Introduction: Distributed Computing & its Threats • Encryption Algorithms • System Authentication • Key Management • Levels of integration • Encryption Protocols • Case Study: Process Level • Network Mail <-- • Digital Signatures

  45. Network Mail • Issues: • May often be short messages • Delivered as soon as possible to the recipient site and stored there • Mails have to be delivered even if the intended receiver is not currently logged in

  46. Network Mail • Basic Flow: • A user at one site wishes to send a message to a user at another site • A system process (sometimes called a “daemon”) is used to receive the mail and deliver it to the user’s “mailbox” • The daemon process not require access to the cleartext form of the mail. It must be able to receive the messages in encrypted form and put the data directly into the mailbox • The user can decrypt the data when he signs on to read his mail

  47. Network Mail • Conventional Key Case: • The last two messages, those which exchange an identifier to ensure that the channel is current, must be dropped (since the recipient may not be present) • The sender requests and gets a key K and a copy of K encrypted with the receiver’s secret key • The sender appends the encrypted mail to the encrypted K and sends both to the receiver • The receiving mail daemon delivers the mail and key (both encrypted) • The intended recipient can decrypt and read it at his leisure

  48. Network Mail • Public Key Case: • The sender retrieves the recipient’s public key via an exchange with the repository • The sender encrypts the mail with the public key and sends it to the receiving site • The mail daemon delivers the encrypted mail, which can be read later by the recipient since he knows his private key • The authentication part of the public-key must be dropped • The intended recipient can decrypt and read it at his leisure

  49. Network Mail • Pros: • Both mechanisms outlined in the previous slides do guarantee that only the desired recipient of a message will be able to read it. Thus the security of the mail is achieved • Cons: • The recipient is not guaranteed the identity of the sender • The idea of digital signatures is needed

  50. Introduction: Distributed Computing & its Threats • Encryption Algorithms • System Authentication • Key Management • Levels of integration • Encryption Protocols • Case Study: Process Level • Network Mail • Digital Signatures <--

More Related