Seurity in Computing-Module 4

Download

Kerberos

Kerberos is a secure method for authenticating a request for a service in a computer network. Kerberos was developed in the Athena Project at the Massachusetts Institute of Technology (MIT). The name is taken from Greek mythology; Kerberos was a three-headed dog who guarded the gates of Hades. Kerberos lets a user request an encrypted "ticket" from an authentication process that can then be used to request a particular service from a server. The user's password does not have to pass through the network.

The three heads of Kerberos comprise the Key Distribution Center (KDC), the client user and the server with the desired service to access. The KDC is installed as part of the domain controller and performs two service functions: the Authentication Service (AS) and the Ticket-Granting Service (TGS). As exemplified in Figure 1, three exchanges are involved when the client initially accesses a server resource:

1.      AS Exchange

2.      TGS Exchange

3.      Client Server(CS) Exchange

Source : www.microsoft.com

1.1 AS Exchange

When initially logging on to a network, users must negotiate access by providing a log-in name and password in order to be verified by the AS portion of a KDC within their domain. The KDC has access to Active Directory user account information. Once successfully authenticated, the user is granted a Ticket to Get Tickets (TGT) that is valid for the local domain. The TGT has a default lifetime of 10 hours and may be renewed throughout the user's log-on session without requiring the user to re-enter his password. The TGT is cached on the local machine in volatile memory space and used to request sessions with services throughout the network.

 

1.2 TGS Exchange

The user presents the TGT to the TGS portion of the KDC when desiring access to a server service. The TGS on the KDC authenticates the user's TGT and creates a ticket and session key for both the client and the remote server. This information, known as the service ticket, is then cached locally on the client machine.

The TGS receives the client's TGT and reads it using its own key. If the TGS approves of the client's request, a service ticket is generated for both the client and the target server. The client reads its portion using the TGS session key retrieved earlier from the AS reply. The client presents the server portion of the TGS reply to the target server in the client/server exchange coming next.

1.3 Client/Server Exchange

Once the client user has the client/server service ticket, he can establish the session with the server service. The server can decrypt the information coming indirectly from the TGS using its own long-term key with the KDC. The service ticket is then used to authenticate the client user and establish a service session between the server and client. After the ticket's lifetime is exceeded, the service ticket must be renewed to use the service.

2. X.509

A public-key certificate is a digitally signed statement from one entity, saying that the public key (and some other information) of another entity has some specific value. Now a Certification Authority (CA) can act as a Trusted Third Party. CAs are entities that are trusted to sign (issue) certificates for other entities. It is assumed that CAs will only create valid and reliable certificates as they are bound by legal agreements. There are many public Certification Authorities, such as VeriSign, Thawte, Entrust, and so on.

The main inputs to the certificate creation process are:

• Matched public and private keys, generated using some special tools.Only the public key is ever shown to anyone else. The private key is used to sign data.
• We need to provide information about the entity being certified. This normally includes information such as name and organizational address.

The X.509 standard defines what information can go into a certificate, and describes how to write it down (the data format). All X.509 certificates have the following data, in addition to the signature:

Version

This identifies which version of the X.509 standard applies to this certificate, which affects what information can be specified in it. Thus far, three versions are defined.

Serial Number

The entity that created the certificate is responsible for assigning it a serial number to distinguish it from other certificates it issues. This information is used in numerous ways, for example when a certificate is revoked its serial number is placed in a Certificate Revocation List (CRL).

Signature Algorithm Identifier

This identifies the algorithm used by the CA to sign the certificate.

Issuer Name

The X.500 name of the entity that signed the certificate. This is normally a CA. Using this certificate implies trusting the entity that signed this certificate.

Validity Period

Each certificate is valid only for a limited amount of time. This period is described by a start date and time and an end date and time, and can be as short as a few seconds or almost as long as a century. The validity period chosen depends on a number of factors, such as the strength of the private key used to sign the certificate or the amount one is willing to pay for a certificate. This is the expected period that entities can rely on the public value, if the associated private key has not been compromised.

Subject Name

The name of the entity whose public key the certificate identifies. This name uses the X.500 standard, so it is intended to be unique across the Internet. This is the Distinguished Name (DN) of the entity, for example,

    CN=Java Duke, OU=Java Software Division, O=Sun Microsystems Inc, C=US

(These refer to the subject's Common Name, Organizational Unit, Organization, and Country.)

Subject Public Key Information

This is the public key of the entity being named, together with an algorithm identifier which specifies which public key crypto system this key belongs to and any associated key parameters.

X.509 Version 1 has been available since 1988, is widely deployed, and is the most generic.

X.509 Version 2 introduced the concept of subject and issuer unique identifiers to handle the possibility of reuse of subject and/or issuer names over time. Most certificate profile documents strongly recommend that names not be reused, and that certificates should not make use of unique identifiers. Version 2 certificates are not widely used.

X.509 Version 3 is the most recent and supports the notion of extensions, whereby anyone can define an extension and include it in the certificate

 Email Security Enhancements

 

Following is the security enhancements for email

•confidentiality

–protection from disclosure

•authentication

–of sender of message

•message integrity

–protection from modification

•non-repudiation of origin

–protection from denial by sender

 

3.1 PGP

(For diagrams refer text book- William Stallings)

PGP is an  official email security system. It was developed by Phil Zimmermann.PGP is available on Unix, PC, Macintosh and Amiga systems. It is originally free, now have commercial versions available also

3.1.1 How PGP works

Authentication

1.The sender creates a message

2.SHA-1 used to generate 160-bit hash code of message

3.The hash code is encrypted with RSA using the sender's private key, and result is attached to message.

4.The receiver uses RSA or DSS with sender's public key to decrypt and recover hash code

5.The receiver generates new hash code for message and compares with decrypted hash code, if match, message is accepted as authentic

Confidentiality

1. The sender generates message and random 128-bit number to be used as session key for this message only.

2.The message is encrypted, using CAST-128 / IDEA/3DES with session key.

3.The session key is encrypted using RSA with recipient's public key, then attached to message.

4.The receiver uses RSA with its private key to decrypt and recover session key.

5.The session key is used to decrypt message.

 

Authentication & Confidentiality

1. Create signature & attach to message

2. Encrypt both message & signature

3. Attach RSA encrypted session key

Compression

By default PGP compresses message after signing but before encrypting and can store uncompressed message & signature for later verification. It uses ZIP compression algorithm.

Email- Compatibility

When using PGP we will have binary data to send (encrypted message etc).However email was designed only for text. Hence PGP must encode raw binary data into printable ASCII characters. For this it uses radix-64 algorithm, which maps 3 bytes to 4 printable characters and also appends a CRC

3.2 S/MIME

S/MIME is the name given to Secure MIME or Secure encryption of attachments when they are added to email messages. S/MIME requires a both a private and public key. The public key is stored and made available to those who wish to send users an encrypted message. So to send a message via S/MIME the sender must look up the public key in a global directory or already have it available. Once the key has been found, the sender must encrypt the message/attachment and forward it to the destination server.

In order for the message to be read, the encrypted message must be decoded by the mail client or by the mail server. There are issues with either of these solutions:

• Decryption by the mail client. At the current time, not many mail clients support S/MIME decryption. Further there is the issue of configuring the mail client with the correct private key so that decryption works OK. Since messages are stored encrypted, if the key becomes compromised at any point in the future and must be changed, there is the risk that the messages will become unavilable in the future.
• Decryption by the mail server. This requires the server to hold both the encryption and decryption key for each user. Clearly there will be additional load on the server as it manages each message and messages are likley to be stored unencrypted on the server itself (there is no point in them being encrypted since the key is available on the server).

4. Secure Socket Layer

The Secure Sockets Layer protocol is a protocol layer which may be placed between a reliable connection-oriented network layer protocol (e.g. TCP/IP) and the application protocol layer (e.g. HTTP). SSL provides secure communication between client and server by allowing mutual authentication, the use of digital signatures for integrity, and encryption for privacy. The protocol is designed to support a range of choices for specific algorithms used for cryptography, digests, and signatures. Choices are negotiated between client and server at the start of establishing a protocol session.

Version:	Source:	Description:
SSL v2.0	Vendor Standard (from Netscape Corp.)	First SSL protocol for which implementations exists
SSL v3.0	Expired Internet Draft (from Netscape Corp.)	Revisions to prevent specific security attacks, add non-RSA ciphers, and support for certificate chains
TLS v1.0	Proposed Internet Standard (from IETF)	Revision of SSL 3.0 to update the MAC layer to HMAC, add block padding for block ciphers, message order standardization and more alert messages.

There are a number of versions of the SSL protocol, as shown. SSL 3.0 is the basis for the Transport Layer Security protocol standard, currently in development by the Internet Engineering Task Force (IETF).

4.1 Session Establishment

 

The SSL session is established by following a handshake sequence between client and server. This sequence may vary, depending on whether the server is configured to provide a server certificate or request a client certificate. Though cases exist where additional handshake steps are required for management of cipher information, this article summarizes one common scenario: see the SSL specification for the full range of possibilities. Once an SSL session has been established it may be reused, thus avoiding the performance penalty of repeating the many steps needed to start a session. For this the server assigns each SSL session a unique session identifier which is cached in the server and which the client can use on forthcoming connections to reduce the handshake.

The elements of the handshake sequence, as used by the client and server, are listed below:

1. Negotiate the Cipher Suite to be used during data transfer
2. Establish and share a session key between client and server
3. Optionally authenticate the server to the client
4. Optionally authenticate the client to the server

The first step, Cipher Suite Negotiation, allows the client and server to choose a Cipher Suite supportable by both of them. The SSL3.0 protocol specification defines 31 Cipher Suites. A Cipher Suite is defined by the following components:

• Key Exchange Method
• Cipher for Data Transfer
• Message Digest for creating the Message Authentication Code (MAC)

These three elements are described in the sections that follow.

 

4.2 Key Exchange Method

The key exchange method defines how the shared secret symmetric cryptography key used for application data transfer will be agreed upon by client and server. SSL 2.0 uses RSA key exchange only, while SSL 3.0 supports a choice of key exchange algorithms including the RSA key exchange when certificates are used, and Diffie-Hellman key exchange for exchanging keys without certificates and without prior communication between client and server. One variable in the choice of key exchange methods is digital signatures -- whether or not to use them, and if so, what kind of signatures to use.

 

4.3 Cipher for Data Transfer

SSL uses the conventional cryptography algorithm (symmetric cryptography) described earlier for encrypting messages in a session. There are nine choices, including the choice to perform no encryption:

• No encryption
• Stream Ciphers
• RC4 with 40-bit keys
• RC4 with 128-bit keys
• CBC Block Ciphers
• RC2 with 40 bit key
• DES with 40 bit key
• DES with 54 bit key
• Triple-DES with 168 bit key
• Idea (128 bit key)

4.4 SSL Record Protocol - Architecture

HTTP	FTP		SMTP
SSL handshake protocol		SSL change cipher spec protocol	SSL alert protocol
SSL Record Protocol
TCP
IP

SSL Record Protocol takes care of the data transmission. SSL Record Protocol provides two services, confidentiality and integrity. Confidentiality uses symmetric encryption with a shared secret key defined by Handshake Protocol and integrity uses a MAC with shared secret key.SSL is used to transfer application and SSL Control data between the client and server. It possibly fragments the data into smaller units, compress the data, attach signatures and encrypt these units before transmitting them.

5. IPSec

IPSec is a group of protocols developed by IETF. The group includes the Authentication Header (AH), which addresses authentication for IP traffic, and the Encapsulating Security Payload (ESP), which defines encryption for IP data. AH ensures that the packet has not been altered during transmission. It can be used in combination with ESP or it simply just use to verify the authenticity of a regular IP packet. The AH also allows the receiver to verify the identity of the sender. IPSec provides these at the IP layer and its often nowadays build on the networks card from the beginning. IPSec can be used to protect one or more data flows between a pair of hosts, gateways and between both gateways and hosts.

 Key management for IPsec: ISAKMP and IKE

ISAKMP (Internet Security Association and Key Protocol Management) is designed to negotiate, establish, modify and delete security associations and their attributes.

ISAKMP is a generic framework which does not dependent on the mechanisms in favor of which the negotiation takes place.

IKE is used to handle negotiation of protocols and algorithms that are based on local policy that generate the encryption and the authentication. Some of these is DES,

MD5, AH and SHA. IKE provides a authentication of the IPSec peers and establishes the IPSec key.

DES (The Data Encryption Standard) is used to encrypt the packet data. DES use cipher block chaining to initialize a vector to start the encryption.

SHA (Secure Hash Algorithm) and MD5 (Message Digest 5) are hash algorithms and these are used to authenticate the data.

ESP (Encapsulating Security Payload) is the protocol that handles encryption of IP data. It uses symmetric, or secret key, cryptographic algorithms like Data Encryption Standard (DES), and triples DES to encrypt the payload. The default method is 56-bit DES.

5.1 Encapsulating Security Payload

 

ESP includes several parts, the first of which is the control header that contains the SPI and the sequence number field. The SPI and sequence number serve the same purpose as in the AH. The SPI indicates which security algorithms and keys were used for a particular connection, and the sequence number keeps track of the order in which packets are transmitted. The payload data can be of any size because it's the actual data being carried by the packet. Along with the payload data, the ESP also contains 0 bytes to 255 bytes of padding, which ensures the data, will be of the correct length for particular types of encryption algorithms. This area of the ESP also includes the pad length, which tells how much padding is in the payload, and the next header field, which gives information about the data and the protocol used. Authentication data is the field that contains a digital signature that has been applied to everything in the ESP except the authentication data itself.

5.2 Authentication Header

Authentication Header is a security protocol that provides authentication and optional replay-detection services. AH is embedded in the data to be protected AH can be used either by itself or with Encryption Service Payload (ESP). The first field in the AH is the next header field; this is an 8-bit field that tells which higher-level protocol (such as UDP, TCP, or ESP) follows the AH. The payload length is an 8-bit value that indicates the length of the authentication data field in 32-bit words. The Security Parameters Index is a 32-bit number that tells the packet recipient which security protocols the sender is using. This information includes which algorithms and keys are being applied by the sending device. The sequence number tells how many packets with the same parameters have been sent. This number acts as a counter and is incremented each time a packet with the same SPI is bound for the same address. Authentication data is a digital signature for the packet. To authenticate users, the AH can use either Message Digest 5 algorithm or the Secure Hash Algorithm.

5.3  Operating modes

There are two different modes in IPsec, transport mode and tunnel mode.
In Transport mode, only the data from the upper-layer protocol and the data transported by the IP datagrams are protected. This mode is usable only on final equipment.
In tunnel mode, the IP header is also protected (authentication, integrity and/or confidentiality) and is replaced by a new header. This new header is used to transport the packet to the end of the tunnel, where the original header is restored. Tunnel mode is usable either on final equipment or on security gateways. This mode makes it possible to ensure a more significant protection against traffic analysis.

6. Firewalls

A firewall is simply a group of components that collectively form a barrier between two networks. A firewall is a piece of hardware and/or software which functions in a networked environment to prevent some communications forbidden by the security policy.

6.1 Terminologies

Bastion host.

A general-purpose computer used to control access between the internal (private) network (intranet) and the Internet (or any other untrusted network).

Router.

A special purpose computer for connecting networks together. Routers also handle certain functions, such as routing , or managing the traffic on the networks they connect.

Access Control List (ACL).

Many routers now have the ability to selectively perform their duties, based on a number of facts about a packet that comes to it. This includes things like origination address, destination address, destination service port, and so on. These can be employed to limit the sorts of packets that are allowed to come in and go out of a given network.

Demilitarized Zone (DMZ).

The DMZ is a critical part of a firewall: it is a network that is neither part of the untrusted network, nor part of the trusted network. But, this is a network that connects the untrusted to the trusted. The importance of a DMZ is tremendous: someone who breaks into your network from the Internet should have to get through several layers in order to successfully do so. Those layers are provided by various components within the DMZ.

Proxy.

This is the process of having one host act in behalf of another. A host that has the ability to fetch documents from the Internet might be configured as a proxy server, and host on the intranet might be configured to be proxy clients. All hosts on the intranet are able to access resources on the Internet without having the ability to direct talk to the Internet.

6.2 Types of Firewalls

Application Gateways

The first firewalls were application gateways, and are sometimes known as proxy gateways. These are made up of bastion hosts that run special software to act as a proxy server. This software runs at the Application Layer of the ISO/OSI Reference Model, hence the name. Clients behind the firewall must be proxitized (that is, must know how to use the proxy, and be configured to do so) in order to use Internet services. Traditionally, these have been the most secure, because they don't allow anything to pass by default, but need to have the programs written and turned on in order to begin passing traffic.

Packet Filtering

Packet filtering is a technique whereby routers have ACLs (Access Control Lists) turned on. By default, a router will pass all traffic sent it, and will do so without any sort of restrictions. Employing ACLs is a method for enforcing security policy with regard to what sorts of access you allow the outside world to have to your internal network, and vice versa. There is less overhead in packet filtering than with an application gateway, because the feature of access control is performed at a lower ISO/OSI layer (typically, the transport or session layer). Due to the lower overhead and the fact that packet filtering is done with routers, which are specialized computers optimized for tasks related to networking, a packet filtering gateway is often much faster than its application layer.

7. Security Mechanisms in Java Platform

Java applets are far more powerful than the usual HTML code served up on the Web. When not restricted by applet-security measures, Java is a complete and powerful programming language capable of sending information over the network; reading, altering, or deleting files; using system resources; and so on. This is powerful stuff, and in the hands of a malicious programmer. Java should restrict itself such that the full power and potential of the Java language is not misused. Java applets we retrieve from the Web have been written by someone else, we cannot trust them to perform with integrity. Java downloaded from the Net is automatically considered untrusted code. In order to ensure that untrusted code does nothing mischievous, it is important to limit what that untrusted code can do.

Following are the basic categories of potential attacks Java applets could facilitate:

ATTACK CLASS	EXPLANATION AND CONSEQUENCES	JAVA DEFENSE
System Modification	The most severe class of attacks. Applets that implement such attacks are attack applets. Consequences of these attacks: severe.	Strong
Invasion of Privacy	If you value your privacy, this attack class may be particularly odious. They are implemented by malicious applets. Include mail forging. Consequences of these attacks: moderate.	Strong
Denial of Service	Also serious but not severely so, these attacks can bring a machine to a standstill. Also implemented by malicious applets. May require reboot. Consequences of these attacks: moderate.	Weak
Antagonism	Merely annoying, this attack class is the most commonly encountered. Implemented by malicious applets. May require restart of browser. Consequences of these attacks: light to moderate.	Weak

7.1 Java Sandbox Architecture

The default sandbox is made of three interrelated parts: the Verifier, the Class Loader, and the Security Manager. If any of the three parts breaks, the entire security system breaks. The Verifier is built in to the VM and cannot be accessed by Java programmers or Java users. In most Java implementations, when Java code arrives at the VM and is formed into a Class by the Class Loader, the Verifier automatically examines it. The Verifier checks byte code at a number of different levels. The simplest test makes sure that the format of a code fragment is correct. If the Verifier discovers a problem with a class file, it throws an exception, loading ceases, and the class file never executes. The verification process, in concert with the security features built into the language and checked at runtime, helps to establish a base set of security guarantees. The Verifier also ensures that class files that refer to each other preserve binary compatibility. There are rules of compatibility that govern the ability to change use of classes and methods without breaking binary compatibility. For example, it is okay to add a method to a class that is used by other classes, but not okay to delete methods from a class used by other classes. The Verifier enforces compatibility rules. Once byte code passes through verification, the following things are guaranteed:

·         The class file has the correct format

·         Stacks will not be overflowed or under flowed

·         Byte code instructions all have parameters of the correct type.

·         No illegal data conversions (casts) occur

·         Private, public, protected, and default accesses are legal

The Verifier acts as the primary gatekeeper in the Java security model. It ensures that each piece of byte code downloaded from the outside plays by the rules. That way, the Java VM can safely execute byte code that may not have been created by a Java compiler. When the Verifier finds a problem in a class, it rejects the malformed class and throws an exception. This is obviously a much more reasonable behavior than running buggy or malicious code that crashes the VM.

All Java objects belong to classes. Class loaders determine when and how classes can be added to a running Java environment. Part of their job is to make sure that important parts of the Java runtime environment are not replaced by impostor code. Class loaders perform two functions. First, when the VM needs to load the byte code for a particular class, it asks a class loader to find the byte code. Each class loader can use its own method for finding requested byte code files: It can load them from the local disk, fetch them across the Net using any protocol, or it can just create the byte code on the spot. This flexibility is not a security problem as long as the party who wrote the code that is being loaded trusts the class loader. Second, class loaders define the namespaces seen by different classes and how those namespaces relate to each other. Namespace is a set of unique names of classes loaded by a particular Class Loader and a binding of each name to a specific class object. Applet Class Loaders, which are typically supplied by the browser vendor, load all applets and the classes they reference, usually getting the classes from HTTP servers. When an applet loads across the network, its Applet Class Loader receives the binary data and instantiates it as a new class. Under normal operation, applets are forbidden to install a new Class Loader

Summary

Each Java class begins as source code. This is then compiled into byte code and distributed to machines anywhere on the Net. A Java-enabled browser automatically downloads a class when it encounters the tag in an HTML document. The Verifier examines the byte code of a class file to ensure that it follows Java's strict safety rules. The Java VM interprets byte code declared safe by the Verifier. The Java specification allows classes to be unloaded when they are no longer needed, but few current Java implementations unload classes.

Java's ability to dynamically load classes into a running Java environment is fraught with security risks. The class-loading mechanisms mitigate these risks by providing separate namespaces set up according to where mobile code originates. This capability ensures that essential Java classes cannot be spoofed (replaced) by external, untrusted code. The Applet Class Loader in particular is a key piece of the Java security model.

7.2 Security Manager

The third part of the base Java security model is the Security Manager. This part of the security model restricts the ways an applet uses visible interfaces (Java API calls). The Security Manager implements a good portion of the entire security model and is the part of the security model most often encountered (in terms of a SecurityException) by Java applet developers.

The job of the Security Manager is to keep track of who is allowed to do which dangerous operations. A standard Security Manager will disallow most operations when they are requested by untrusted code, and will allow trusted code to do whatever it wants.

The Security Manager is a single Java object that performs runtime checks on dangerous methods. Code in the Java library consults the Security Manager whenever a potentially dangerous operation is attempted. The Security Manager can veto the operation by generating a SecurityException. Decisions made by the Security Manager take into account the origin of the requesting class. Obviously, built-in classes are usually given more privilege than classes loaded across the Net. The Security Manager makes the final decision as to whether a particular operation is permitted or rejected. The Java API provides all calls necessary to interface to the operating system, thus making isolation of all required security checks possible within the API. When a dangerous call is made to the Java library, the library queries the Security Manager. These queries use a set of methods that check access.

Each VM can have only one Security Manager installed at a time, and once a Security Manager has been installed it cannot be uninstalled (except by restarting the VM). Java-enabled applications such as Web browsers install a Security Manager as part of their initialization, thus locking in the Security Manager before any potentially untrusted code has a chance to run.

Source : www.securingjava.com

7.3 What the Security Manager Is Set Up to Do for Untrusted Applets

The Security Manager has the following duties:

• Prevent installation of new class loaders. The job of class loaders is to keep the namespaces properly organized. Because security checks are requested by classes in the Java library, applets must be prevented from spoofing the library classes.
• Protect threads and thread groups from each other.
• Control the execution of other application programs.
• Control the ability to shut down the VM.
• Control access to other application processes.
• Control access to system resources such as print queues, clipboards, event queues, system properties, and windows.
• Control file system operations such as read, write, and delete. Access to local files is strictly controlled.
• Control network socket operations such as connect and accept.
• Control access to Java packages (or groups of classes), including access to security enforcement classes.

Download