Cryptography and Network Security - Module 4: Network Security
User Authentication
Authentication functions are developed to support application-level authentication and digital signatures.
Kerberos: A private-key authentication service.
X.509: Directory authentication service.
Kerberos
Developed as part of Project Athena at MIT.
Addresses the problem of securing access to services in an open distributed environment.
Servers restrict access to authorized users and authenticate service requests.
Workstations are not trusted to correctly identify users to network services.
Threats Addressed by Kerberos
User impersonation at a workstation.
Alteration of workstation network address for impersonation.
Eavesdropping and replay attacks.
Kerberos Function
Provides a centralized authentication server to authenticate users to servers and vice versa.
Relies exclusively on symmetric encryption.
Kerberos Requirements
Secure: Prevents eavesdroppers from obtaining information to impersonate a user.
Reliable: Highly reliable with a distributed server architecture for backup.
Transparent: User authentication should be seamless, requiring only a password.
Scalable: Capable of supporting large numbers of clients and servers.
Kerberos 4 Overview
Basic third-party authentication scheme.
Authentication Server (AS):
Users negotiate with AS to identify themselves.
AS provides a non-corruptible authentication credential (Ticket Granting Ticket - TGT).
Ticket Granting Server (TGS):
Users request access to other services from TGS based on their TGT.
Kerberos 4 Process
User logs on to workstation and requests service.
AS verifies user access rights, creates a ticket-granting ticket (TGT) and session key, encrypted using a key derived from the user's password.
Workstation prompts user for password to decrypt the incoming message, then sends ticket and authenticator to TGS.
TGS decrypts ticket and authenticator, verifies request, and creates ticket for requested application server.
Workstation sends ticket and authenticator to host.
Host verifies ticket and authenticator, grants access to service, and may return an authenticator for mutual authentication.
Kerberos Version 5
Developed in the mid-1990s.
Provides improvements over version 4 addressing:
Environmental shortcomings like encryption algorithm, network protocol, byte order, ticket lifetime.
Technical deficiencies like double encryption, non-standard mode of use and password attacks.
Specified as Internet standard RFC 1510.
Public Key Infrastructure (PKI)
A set of policies, processes, server platforms, software, and workstations for administering certificates and public-private key pairs.
Includes the ability to issue, maintain, and revoke public key certificates.
Objective of PKI
To enable secure, convenient, and efficient acquisition of public keys.
PKI Architectural Model Components
End entity: End users or devices identified in a public-key certificate.
Certification authority (CA): Issues certificates and certificate revocation lists (CRLs), and supports administrative functions.
Registration authority (RA): Optional component that handles administrative functions from the CA.
CRL issuer: Optional component delegated by CA to publish CRLs.
Repository: Stores certificates and CRLs for retrieval by end entities.
PKI Management Functions
Registration: User makes themselves known to a CA (directly or through an RA).
Initialization: Installing key materials for secure client system operation.
Certification: CA issues a certificate for a user’s public key.
Key pair recovery: Recovering key pairs for digital signature or encryption.
Key pair update: Regularly replacing key pairs and issuing new certificates.
Revocation request: Requesting certificate revocation due to an abnormal situation.
Cross certification: CAs exchange information to establish cross-certificates.
Email Security
Email is a widely used network service, but message contents are often insecure.
Messages may be inspected in transit or by privileged users on the destination system.
Email Security Enhancements
Confidentiality: Protection from disclosure.
Authentication: Verification of the sender of the message.
Message integrity: Protection from modification.
Non-repudiation of origin: Protection from denial by the sender.
Pretty Good Privacy (PGP)
Widely used de facto secure email standard.
Developed by Phil Zimmermann.
Integrates best available cryptographic algorithms into a single program, that is available on multiple platforms.
Notation
= session key used in symmetric encryption scheme
= private key of user A, used in public-key encryption scheme
= public key of user A, used in public-key encryption scheme
= public-key encryption
= public-key decryption
= symmetric encryption
= symmetric decryption
= hash function
= concatenation
= compression using ZIP algorithm
PGP Authentication Only
Sender creates a message (M).
The message is compressed using ZIP ().
A hash of the compressed message is computed ().
The hash is encrypted with the sender's private key () using public-key encryption ().
The encrypted hash is concatenated with the compressed message, .
PGP Confidentiality Only
A message () is compressed ().
A random session key () is generated for symmetric encryption.
The compressed message is encrypted with the session key using symmetric encryption, .
The session key is encrypted with the recipient's public key, .
The encrypted session key is concatenated with the encrypted message, .
PGP Confidentiality and Authentication
Combines both authentication and confidentiality.
The message is compressed, then signed, then the message and signature are encrypted.
PGP Operation – Authentication
Sender creates a message.
SHA-1 is used to generate a 160-bit hash code of the message.
Hash code is encrypted with RSA using the sender's private key and attached to the message.
Receiver uses RSA or DSS with sender's public key to decrypt and recover hash code.
Receiver generates new hash code for message and compares with decrypted hash code.
If match, message is accepted as authentic.
PGP Operation – Confidentiality
Sender generates a message and a random 128-bit number to be used as session key for this message only.
Message is encrypted, using CAST-128 / IDEA/3DES with session key.
Session key is encrypted using RSA with recipient's public key, then attached to message.
Receiver uses RSA with its private key to decrypt and recover session key.
Session key is used to decrypt message.
PGP Operation – Compression
PGP compresses message after signing but before encrypting.
Uses ZIP compression algorithm.
PGP Operation – Email Compatibility
PGP encodes raw binary data into printable ASCII characters using radix-64 algorithm.
Radix-64 maps 3 bytes to 4 printable characters and appends a CRC.
PGP also segments messages if too big.
PGP Session Keys
Need a session key for each message.
Sizes vary: 56-bit DES, 128-bit CAST or IDEA, and 168-bit Triple-DES.
Generated using ANSI X12.17 mode.
Uses random inputs taken from previous uses and from keystroke timing of user.
PGP Public & Private Keys
Key identifier is used to identify the key used to encrypt the session key in a message.
Key identifier is the least significant 64-bits of the key.
Key ID is also used in signatures.
S/MIME (Secure/Multipurpose Internet Mail Extensions)
S/MIME is a security enhancement to the MIME Internet email format standard based on technology from RSA Data Security.
S/MIME Operational Description
S/MIME provides for four message-related services:
Authentication
Confidentiality
Compression
Email compatibility
S/MIME Authentication
Provided by means of a digital signature.
Most commonly RSA with SHA-256 is used.
The sender creates a message.
SHA-256 is used to generate a 256-bit message digest of the message.
The message digest is encrypted with RSA using the sender’s private key, and the result is appended to the message. Also appended is identifying information for the signer, which will enable the receiver to retrieve the signer’s public key.
The receiver uses RSA with the sender’s public key to decrypt and recover the message digest.
The receiver generates a new message digest for the message and compares it with the decrypted hash code. If the two match, the message is accepted as authentic.
S/MIME Services
Function | Typical Algorithm | Typical Action |
|---|---|---|
Digital signature | RSA/SHA-256 | A hash code of a message is created using SHA-256. This message digest is encrypted using SHA-256 with the sender’s private key and included with the message. |
Message encryption | AES-128 with CBC | A message is encrypted using AES-128 with CBC with a one-time session key generated by the sender. The session key is encrypted using RSA with the recipient’s public key and included with the message. |
Compression | unspecified | A message may be compressed for storage or transmission. |
Email compatibility | Radix-64 conversion | To provide transparency for email applications, an encrypted message may be converted to an ASCII string using radix-64 conversion. |
S/MIME Confidentiality
S/MIME provides confidentiality by encrypting messages.
The sender generates a message and a random 128-bit number to be used as a content-encryption key for this message only.
The message is encrypted using the content-encryption key.
The content-encryption key is encrypted with RSA using the recipient’s public key and is attached to the message.
The receiver uses RSA with its private key to decrypt and recover the content-encryption key.
The content-encryption key is used to decrypt the message.
S/MIME Email Compatibility
When S/MIME is used, at least part of the block to be transmitted is encrypted.
If only the signature service is used, then the message digest is encrypted (with the sender’s private key).
If the confidentiality service is used, the message plus signature (if present) are encrypted (with a one-time symmetric key).
S/MIME Compression
S/MIME also offers the ability to compress a message.
This has the benefit of saving space both for email transmission and for file storage.
Simplified S/MIME Functional Flow
Sender signs, then encrypts message.
Receiver decrypts message, then verifies sender's signature.
S/MIME Message Content Types
S/MIME uses the following message content types, which are defined in RFC 5652.
Data: Refers to the inner MIME-encoded message content, which may then be encapsulated in a SignedData, EnvelopedData, or CompressedData content type.
SignedData: Used to apply a digital signature to a message.
EnvelopedData: This consists of encrypted content of any type and encrypted-content encryption keys for one or more recipients.
CompressedData: Used to apply data compression to a message.
IP Security (IPsec)
IP-level security incorporates three functional areas: authentication, confidentiality, and key management.
The authentication mechanism assures that a received packet was, in fact, transmitted by the party identified as the source in the packet header.
In addition, this mechanism assures that the packet has not been altered in transit.
The confidentiality facility enables communicating nodes to encrypt messages to prevent eavesdropping by third parties.
The key management facility is concerned with the secure exchange of keys.
IP Security Policy
Fundamental to the operation of IPsec is the concept of a security policy applied to each IP packet that transits from a source to a destination.
IPsec policy is determined primarily by the interaction of two databases, the security association database (SAD) and the security policy database (SPD).
Security Association (SA)
A key concept that appears in both the authentication and confidentiality mechanisms for IP is the security association (SA).
An association is a one-way logical connection between a sender and a receiver that affords security services to the traffic carried on it.
If a peer relationship is needed for two-way secure exchange, then two security associations are required.
Security Association Database
In each IPsec implementation, there is a nominal Security Association Database that defines the parameters associated with each SA.
Security Policy Database
IP traffic is related to specific SAs (or no SA in the case of traffic allowed to bypass IPsec) is the nominal Security Policy Database (SPD).
In its simplest form, an SPD contains entries, each of which defines a subset of IP traffic and points to an SA for that traffic.
In more complex environments, there may be multiple entries that potentially relate to a single SA or multiple SAs associated with a single SPD entry.
IP Traffic Processing
IPsec is executed on a packet-by-packet basis.
When IPsec is implemented, each outbound IP packet is processed by the IPsec logic before transmission, and each inbound packet is processed by the IPsec logic after reception and before passing the packet contents on to the next higher layer (e.g., TCP or UDP).
Encapsulating Security Payload (ESP)
ESP can be used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and (limited) traffic flow confidentiality.
The set of services provided depends on options selected at the time of Security Association (SA) establishment and on the location of the implementation in a network topology.
ESP can work with a variety of encryption and authentication algorithms, including authenticated encryption algorithms such as GCM ( Larger Databases – Integrity and authentication Check).
Encapsulating Security Payload Format
Security Parameters Index (SPI) (32 bits): Identifies a security association.
Sequence Number (32 bits): A monotonically increasing counter value; this provides an anti-replay function, as discussed for AH.
Payload Data (variable): This is a transport-level segment (transport mode) or IP packet (tunnel mode) that is protected by encryption.
Padding (0–255 bytes): Padding field is used to expand the plaintext (consisting of the Payload Data, Padding, Pad Length, and Next Header fields) to the required length.
Pad Length (8 bits): Indicates the number of pad bytes immediately preceding this field.
Next Header (8 bits): Identifies the type of data contained in the payload data field by identifying the first header in that payload (e.g., an extension header in IPv6, or an upper-layer protocol such as TCP).
Integrity Check Value (ICV) (variable): A variable-length field (must be an integral number of 32-bit words) that contains the Integrity Check Value computed over the ESP packet minus the Authentication Data field.
Web Security
Web now widely used by business, government, individuals.
Internet & Web are vulnerable.
Variety of threats exist, including integrity, confidentiality, denial of service and authentication.
Need added security mechanisms.
SSL (Secure Socket Layer)
Secure Socket Layer (SSL) provides security services between TCP and applications that use TCP.
The Internet standard version is called Transport Layer Service (TLS).
SSL/TLS provides confidentiality using symmetric encryption and message integrity using a message authentication code.
SSL/TLS includes protocol mechanisms to enable two TCP users to determine the security mechanisms and services they will use.
SSL Architecture
SSL is designed to make use of TCP to provide a reliable end-to-end secure service.
SSL is not a single protocol but rather two layers of protocols.
The SSL Record Protocol provides basic security services to various higher layer protocols.
In particular, the Hypertext Transfer Protocol (HTTP), which provides the transfer service for Web client/server interaction, can operate on top of SSL.
Three higher-layer protocols are defined as part of SSL: the Handshake Protocol, The Change Cipher Spec Protocol, and the Alert Protocol.
These SSL-specific protocols are used in the management of SSL exchanges.
SSL Concepts
SSL session: An association between a client and a server, created by the Handshake Protocol, which defines a set of cryptographic security parameters that can be shared among multiple connections.
SSL connection: A transport that provides a suitable type of service, such as peer-to-peer relationships, that are transient and associated with one session.
SSL Record Protocol
The SSL Record Protocol provides two services for SSL connections:
Confidentiality: The Handshake Protocol defines a shared secret key that is used for conventional encryption of SSL payloads.
Message Integrity: The Handshake Protocol also defines a shared secret key that is used to form a message authentication code (MAC).
SSL Record Protocol Operation
The Record Protocol takes an application message to be transmitted, fragments the data into manageable blocks, optionally compresses the data, applies a MAC, encrypts, adds a header, and transmits the resulting unit in a TCP segment. Received data are decrypted, verified, decompressed, and reassembled before being delivered to higher-level users.
SSL Change Cipher Spec Protocol
The Change Cipher Spec Protocol is one of the three SSL- specific protocols that use the SSL Record Protocol, and it is the simplest.
This protocol consists of a single message which consists of a single byte with the value 1.
The sole purpose of this message is to cause the pending state to be copied into the current state, which updates the cipher suite to be used on this connection.
SSL Alert Protocol
The Alert Protocol is used to convey SSL-related alerts to the peer entity.
As with other applications that use SSL, alert messages are compressed and encrypted, as specified by the current state.
Each message in this protocol consists of two bytes.
The first byte takes the value warning (1) or fatal (2) to convey the severity of the message.
If the level is fatal, SSL immediately terminates the connection.
SSL Handshake Protocol
Allows server & client to:
Authenticate each other.
Negotiate encryption & MAC algorithms.
Negotiate cryptographic keys to be used.
Comprises a series of messages in phases.
Establish Security Capabilities - Phase 1
Server Authentication and Key Exchange - Phase 2
Client Authentication and Key Exchange - Phase 3
Finish - Phase 4
Transport Layer Security (TLS)
One of the most widely used security services.
TLS is an Internet standard that evolved from a commercial protocol known as Secure Sockets Layer (SSL).
TLS Architecture
TLS is designed to make use of TCP to provide a reliable end-to-end secure service.
The TLS Record Protocol provides basic security services to various higher layer protocols.
In particular, the Hypertext Transfer Protocol (HTTP), which provides the transfer service for Web client/server interaction, can operate on top of TLS.
Three higher-layer protocols are defined as part of TLS: the Handshake Protocol; the Change Cipher Spec Protocol; and the Alert Protocol.
These TLS specific protocols are used in the management of TLS exchanges.
A fourth protocol, the Heartbeat Protocol, is defined in a separate RFC.
TLS Record Protocol
The TLS Record Protocol provides two services for TLS connections:
Confidentiality: The Handshake Protocol defines a shared secret key that is used for conventional encryption of TLS payloads.
Message Integrity: The Handshake Protocol also defines a shared secret key that is used to form a message authentication code (MAC).
Change Cipher Spec Protocol
The Change Cipher Spec Protocol is one of the four TLS- specific protocols that use the TLS Record Protocol, and it is the simplest.
This protocol consists of a single message which consists of a single byte with the value 1.
The sole purpose of this message is to cause the pending state to be copied into the current state, which updates the cipher suite to be used on this connection.
Alert Protocol
The Alert Protocol is used to convey TLS-related alerts to the peer entity. Handshake Protocol
The most complex part of TLS is the Handshake Protocol.
This protocol allows the server and client to authenticate each other and to negotiate an encryption and MAC algorithm and cryptographic keys to be used to protect data sent in a TLS record.