Encryption and Secure Computer Networks

Brady ChenAndriy BaranskyyTrevor Owen

(11.07.2006)

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

Needham-Schröder Model of a Conventional Key Algorithm

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

Model of Public Key Algorithm

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