Securing Data at the Application Layer

Planning Authenticity and Integrity of Transmitted Data

Planning Encryption of Transmitted Data

Planning Authenticity and Integrity of Transmitted Data

Providing authenticity and integrity of transmitted data

Planning Server Message Block (SMB) signing Planning digital signing

Two Methods That Provide Authenticity and Integrity of Transmitted Data at the Application Layer SMB signing Secure/Multipurpose Internet Mail Extensions

(S/MIME) and Pretty Good Privacy (PGP)

Planning SMB Signing SMB signing is also known as Common Internet File

System (CIFS). SMB signing ensures the authenticity and integrity of

packets transmitted between a client and a server. Each packet is signed as it is transmitted and then

verified at the recipient computer. SMB signing is implemented in high-security

networks to prevent impersonation of clients and servers.

SMB signing authenticates the user and the server hosting the data.

If authentication fails on either side, data transmission will not take place.

SMB Signing Process

Message Digest v5 (MD5) Algorithm

MD5 is used to create the key that is used to create the digest.

The MD5 algorithm breaks the data into 512-bit blocks and produces a 128-bit message digest for each 512-bit block of the data.

The key is computed from the session key established between the client and the server and the initial response sent by the client to the server's challenge.

When to Use SMB Signing

Use SMB signing in networks that implement both Microsoft Windows 2000–based clients and down-level Windows clients.

IPSec Authentication Headers (AH) are supported only in a pure Windows 2000 network.

SMB signing is supported by Windows 2000, Microsoft Windows NT 4.0 (Service Pack 3), and Microsoft Windows 98–based clients.

Windows 95–based clients do not support SMB signing.

Deployment of SMB Signing

SMB Signing: Windows 2000–Based Clients

Workgroup environment Deploy the security template file by using the

Secedit command. Copy the completed security template locally to each

computer. Create a batch file that calls the Secedit command,

using the /configure option to apply the security template

SMB Signing: Windows 2000–Based Clients (Cont.)

Domain environment

SMB Signing: Windows 2000–Based Clients (Cont.)

Choosing domain or workgroup settings depends on

The role of the Windows 2000–based computer The security requirements for SMB signing defined

for the network

SMB Signing: Windows NT 4.0–Based Clients Windows NT 4.0 introduced support for SMB signing in

Service Pack 3 (SP3). Requires editing of the registry. Create a custom template file and apply the settings with

the System Policy Editor. If Windows NT 4.0 is operating in a domain environment,

apply the settings to a Ntconfig.pol configuration file. Registry key for clients functioning as a server

HKEY_LOCAL_MACHINE \System\CurrentControlSet\Services\LanManServer\Parameters

Registry key for clients functioning as a client HKEY_LOCAL_MACHINE \System\CurrentControlSet\Services\Rdr\Parameters

SMB Signing: Windows 98–Based Clients

Windows 98 includes an updated version of the SMB protocol.

Requires editing of the registry. Deploy these settings by e-mailing a .reg file

containing the desired settings. Registry key for clients

HKEY_LOCAL_MACHINE \System\CurrentControlSet\

Services\VxD\Vnetsup

Making the Decision: Planning SMB Signing Security

Require that all communications to a server use SMB signing.

Allow SMB signing to fall back to unsigned communications.

Deploy SMB signing configuration for Windows 2000–based clients.

Deploy SMB signing configuration for Windows NT 4.0–based clients.

Deploy SMB signing configuration for Windows 98–based clients.

Applying the Decision: Planning SMB Signing Security for Fabrikam Inc.

Implement SMB signing for the Radar System project, using different methods depending on the computer's OS.

The HELIOS server Windows 2000 clients Windows NT 4.0 clients Windows 98 clients

SMB signing is not required for the Sonar System project.

Applying the Decision: Proposed OU Structure for Windows 2000–Based Clients for Fabrikam Inc.

Planning Digital Signing

Digital signatures ensure the authenticity and integrity of e-mail messages between clients.

Public Key Infrastructure (PKI) is required to deploy the necessary public/private key pairs to participating clients.

Digital signatures function by applying a digest function to the contents of the message to create a message digest.

If the contents of the message are modified, the message digest output will also change.

Digital Signature Process

Determining Protocol Choices for Digital Signing

Two protocols provide digital signatures for e-mail applications:

S/MIME PGP

Determine which protocol to use based on the e-mail application deployed.

Deploying Public Keys

Ensure the availability of public keys when implementing digital signatures.

Without a public key, the digest encrypted with the sender's private key cannot be decrypted to verify message integrity.

The digital certificate must be issued by a Certificate Authority (CA) that the recipient trusts.

The Certificate Revocation List (CRL) must be accessible to any recipients so the revocation status of the digital certificate can be verified.

If the CRL cannot be accessed, the certificate is assumed to be revoked.

Ensuring the Availability of Public Keys

Configure e-mail clients to include their certificate with all signed messages.

Implement the Key Management Service (KMS) in Microsoft Exchange Server 5.5 or Microsoft Exchange 2000 Server.

Making the Decision: Digital Signature Design

Choose which protocol to use for digitally signing e-mail messages within the organization.

Ensure that important messages are digitally signed.

Ensure that digital signatures are validated. Limit which users can use digital signatures.

Applying the Decision: Digital Signature Design for Fabrikam Inc.

Provide the ability to digitally sign messages. Defense Department price quotes The Radar System project The Sonar System project

Determine which users need to acquire certificates for digitally signed e-mail.

Determine whether the partners of the Defense Department and A. Datum Corporation use PGP or S/MIME for their e-mail packages.

Planning Encryption of Transmitted Data

Planning secure e-mail encryption Planning application-level encryption with

Secure Sockets Layer/Transport Layer Security (SSL/TLS)

Planning Secure E-Mail Encryption

Contents of e-mail messages are vulnerable to inspection.

Digital signing does not prevent someone from inspecting e-mail messages during transmission across the network.

Simple Mail Transfer Protocol (SMTP) is the default protocol used for sending e-mail messages.

SMTP does not include any extensions for the encryption of e-mail.

E-Mail Encryption Process

Encryption Levels for E-Mail

Algorithms supported in Microsoft Outlook 2000 Rivest's Cipher v2 (RC2) Data Encryption Standard (DES) Triple DES (3DES)

Encryption import and export laws RC2 (128 bit) and 3DES require the Windows 2000

High Encryption Pack to be installed. The Windows 2000 High Encryption Pack is subject to

import and export laws. The United States allows the export of the high

encryption to nonembargoed nations.

Protocol Choices for E-Mail Encryption

Choose between S/MIME and PGP for the encryption protocol.

Encryption protocols for e-mail cannot be mixed.

Making the Decision: Deploying E-Mail Encryption

Determine all approved e-mail applications that are in use.

Determine who can use secure e-mail. Determine where the private/public keys will be

acquired. Establish guidelines for the distribution of public

keys to recipients outside the organization. Establish an external public point for CRLs if

using an internal CA. Train users on when to encrypt messages.

Applying the Decision: Deploying E-Mail Encryption for Fabrikam Inc. Require encryption of e-mail sent to the Defense

Department and between project members on the Sonar System project.

The same infrastructure that is required for digitally signing e-mail messages works for encrypting e-mail messages.

It is recommended that Mail certificates be acquired from a public CA, or ensure that the CAs have their CRLs available on the Internet.

The users in the two projects should be trained on how to encrypt messages when the messages are sent to recipients in other companies.

The process may require that a digitally signed message is first sent between the two users who require encrypted mail.

The public key of the recipient is used to encrypt messages sent to that recipient.

Application-Level Encryption with SSL/TLS

Secure Sockets Layer (SSL)

SSL provides encryption services by using public and private keys to encrypt data transmitted between a server and a client.

SSL is commonly associated with Web browsers. The application must be programmed to support

SSL. SSL is implemented between the TCP and

application layer. SSL-enabled applications listen for client

connections on a different port than the usual port.

SSL Provides Encryption Services to Other Protocols

Lightweight Directory Access Protocol (LDAP) Network News Transfer Protocol (NNTP) Post Office Protocol v3 (POP3) Internet Message Access Protocol v4 (IMAP4)

Transport Layer Security (TLS)

Similar to SSL in that TLS provides communications privacy, authentication, and message integrity by using a combination of public key and symmetric encryption

Uses different encryption algorithms than SSL Is an IETF draft standard Used by Windows 2000 to encrypt smart card

authentication information transmitted when using Extended Authentication Protocol (EAP)

Supports the option of reverting to SSL support if needed

May replace SSL in the future

Deploying SSL and TLS

The server hosting the application that uses SSL or TLS must acquire a private/public key pair for encrypting the data.

The benefit of using application-level security is that the encryption requires no additional work by the user.

The only noticeable change is https: in the URL rather than http:.

Encryption Process for Web-Based Applications

Making the Decision: Designing Application-Level Encryption Using SSL and TLS Enable secure Web communications. Enable secure Web communications for a public Web

site. Enable secure communications for a private Web site. Secure authentication to a Web site and support any

browser. Define the level of encryption to use for a Web site. Enable strong encryption at a Windows 2000 Web

server. Enable strong encryption at a Windows client. Minimize reduction in performance due to encryption

of transmitted data.

Applying the Decision: Designing Application-Level Encryption for Fabrikam Inc. Ensure that information entered into or

downloaded from Web pages stored on the three separate Web sites is not compromised during transmission.

Defense Department bidding Web site Sonar project time sheet Web site The Sonar System project server

Chapter Summary

Providing authenticity and integrity of transmitted data

Planning SMB signing Planning digital signing Planning secure e-mail encryption Planning application-level encryption with

SSL/TLS