encryption and secure computer networks brady chen andriy baranskyy trevor owen (11.07.2006)
Post on 21-Dec-2015
221 views
TRANSCRIPT
Introduction: Distributed Computing & its Threats <--
Encryption Algorithms System Authentication Key Management Levels of integration Encryption Protocols Case Study: Process Level Network Mail Digital Signatures
Number and diversity of networks is rising Number and diversity of applications is rising Want to guarantee:
Privacy, Integrity, Security
Need Encryption
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
Two major challenges: Develop suitable string encryption algorithms Integrate encryption methods into O/S
But, what are the threats?
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.
Introduction: Distributed Computing & its Threats Encryption Algorithms <-- System Authentication Key Management Levels of integration Encryption Protocols Case Study: Process Level Network Mail Digital Signatures
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
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
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)
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
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.
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
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)
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
Introduction: Distributed Computing & its Threats Encryption Algorithms System Authentication <-- Key Management Levels of integration Encryption Protocols Case Study: Process Level Network Mail Digital Signatures
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
Introduction: Distributed Computing & its Threats Encryption Algorithms System Authentication Key Management <-- Levels of integration Encryption Protocols Case Study: Process Level Network Mail Digital Signatures
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
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)
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
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
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
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
Introduction: Distributed Computing & its Threats Encryption Algorithms System Authentication Key Management Levels of integration <-- Encryption Protocols Case Study: Process Level Network Mail Digital Signatures
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
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
Introduction: Distributed Computing & its Threats Encryption Algorithms System Authentication Key Management Levels of integration Encryption Protocols <-- Case Study: Process Level Network Mail Digital Signatures
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
Encryption Protocols
Fortunately the encryption channel can be managed independently of the communication channel;as a result many protocol questions can be ignored
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
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
Introduction: Distributed Computing & its Threats Encryption Algorithms System Authentication Key Management Levels of integration Encryption Protocols Case Study: Process Level <-- Network Mail Digital Signatures
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.
Case Study: Process-Process Level
U1 U2 Un NM
Processes
Software Kernel
Hardware
Processes
Software Kernel
Hardware
NM’ U’1U’2U’n
Encryption Unit
Encryption Unit
Network Interface
Network Interface
Data flow in process-to-process encrypted channels
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)
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.
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.
U1 U2 Un NM
Software Kernel
NM’ U’1U’2U’n
Encryption Unit
Encryption Unit
Network Interface
Network Interface
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
U1 U2 Un NM
Software Kernel
NM’ U’1U’2U’n
Encryption Unit
Encryption Unit
Network Interface
Network Interface
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
U1 U2 Un NM
Software Kernel
NM’ U’1U’2U’n
Encryption Unit
Encryption Unit
Network Interface
Network Interface
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
Introduction: Distributed Computing & its Threats Encryption Algorithms System Authentication Key Management Levels of integration Encryption Protocols Case Study: Process Level Network Mail <-- Digital Signatures
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
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
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
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
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
Introduction: Distributed Computing & its Threats Encryption Algorithms System Authentication Key Management Levels of integration Encryption Protocols Case Study: Process Level Network Mail Digital Signatures <--
Digital Signatures Problems with DS:
A central authority is needed by the recipient for aid in deciphering the first message received from any given author
The central authority must keep all old values of public keys in a reliable way to properly adjudicate conflicts over old signatures (consider the relevant lifetime of a signature on a real estate deed)
The author of signed messages can effectively disavow and repudiate his signatures at any time, merely by causing his secret key to be made public or compromised
Digital Signatures Network-Registry-Based Signatures:
The author authenticates with a local component of the network registry, creates a message, and hands the message to the NR together with the recipient identifier and an indication that a registered signature is desired
The NR computes a simple characteristic function of the message, author, recipient, and current time; encrypts the result with a key known only to the NR; and forwards the resulting “signature block” to the recipient. The NR only retains the encryption key employed
The recipient, when the message is received, can ask the NR if the message was indeed signed by the claimed author by presenting the signature block and message
Digital Signatures Notary-Public & Archive-based solutions:
Public-key algorithm, provide safe signature methods
There can be a number of independently operating notary public machines attached to the network
When a signed message has been produced, it can be sent to several of the notary public machines by the author after the author has signed the message himself
Digital Signatures Notary-Public & Archive-based solutions:
The notary public machine time-stamps the message, signs it itself, and returns the result to the author
The author can then put the appropriate cleartext information around the doubly signed correspondence and send it to the intended receiver
Receiver checks the notary’s signature by decoding with the notary’s public key, then decodes the message using the author’s public keying his secret key to be made public or compromised