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 ing 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 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 applications: S/MIME PGP Determine which protocol to use based on the 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 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 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 . Determine whether the partners of the Defense Department and A. Datum Corporation use PGP or S/MIME for their packages.

Planning Encryption of Transmitted Data Planning secure encryption Planning application-level encryption with Secure Sockets Layer/Transport Layer Security (SSL/TLS)

Planning Secure Encryption Contents of messages are vulnerable to inspection. Digital signing does not prevent someone from inspecting messages during transmission across the network. Simple Mail Transfer Protocol (SMTP) is the default protocol used for sending messages. SMTP does not include any extensions for the encryption of .

Encryption Process

Encryption Levels for 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 Encryption Choose between S/MIME and PGP for the encryption protocol. Encryption protocols for cannot be mixed.

Making the Decision: Deploying Encryption Determine all approved applications that are in use. Determine who can use secure . 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 Encryption for Fabrikam Inc. Require encryption of sent to the Defense Department and between project members on the Sonar System project. The same infrastructure that is required for digitally signing messages works for encrypting 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

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 encryption Planning application-level encryption with SSL/TLS