Essential Communication Security Skills

v1.3 | February 2013

| Level 2

Essential Communication Security Skills Self-paced Technical Training

Student Guide and Lab Exercises

Essential Communication Security Skills for Polycom Solutions

Disclaimer Š 2013 Polycom, Inc. All rights reserved.

Polycom, Inc. 4750 Willow Road Pleasanton, CA 94588-2708 USA No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Polycom, Inc. Under the law, reproducing includes translating into another language or format.

As between the parties, Polycom, Inc., retains title to and ownership of all proprietary rights with respect to the software contained within its products. The software is protected by United States copyright laws and international treaty provision. Therefore, you must treat the software like any other copyrighted material (e.g., a book or sound recording).

Every effort has been made to ensure that the information in this manual is accurate.

Polycom, Inc., is not responsible for printing or clerical errors. Information in this document is subject to change without notice.

Page 2 of 229

Essential Communication Security Skills for Polycom Solutions

Course Flow............................................................................................................................... 7 Course Objectives ...................................................................................................................... 8 Part 1: Introduction to Cryptography........................................................................................... 9 Vulnerabilities ........................................................................................................................10 Threat ....................................................................................................................................10 Risks .....................................................................................................................................12 Security Principles ....................................................................................................................13 ISO 7498-2 ............................................................................................................................13 Information Assurance...........................................................................................................14 Trust ......................................................................................................................................14 Terms used in Cryptography .....................................................................................................15 Encryption Techniques..............................................................................................................16 Substitution ...........................................................................................................................16 Transposition .........................................................................................................................16 Algorithms and Keys .................................................................................................................17 Symmetric .............................................................................................................................17 Asymmetric ...........................................................................................................................17 Symmetric Technology..............................................................................................................18 Advantage .............................................................................................................................18 Disadvantage ........................................................................................................................18 Symmetric Cryptography Scenarios ......................................................................................19 Symmetric Mechanisms ............................................................................................................23 Symmetric Encryption Algorithms ..........................................................................................25 Lab Figure.................................................................................................................................26 Lab 1.1: Install CrypTool ...........................................................................................................27 Lab 1.2: Symmetric Encryption/Decryption using AES ..............................................................28 Asymmetric Technology ............................................................................................................31 Security Services Provided by Public Keys ............................................................................32 Asymmetric Encryption Algorithms ........................................................................................33 Asymmetric Cryptography Scenarios .....................................................................................34 Authentication of Data (i.e. proof-of-origin) ............................................................................40 Question: Issues with this Procedure .....................................................................................43 Answer: Issues with this Process...........................................................................................44

Page 3 of 229

Essential Communication Security Skills for Polycom Solutions

Lab 2.1: Asymmetric Encryption/Decryption ..............................................................................45 Message Digest/Hashing ..........................................................................................................47 Message Digest Scenarios ....................................................................................................50 Question: Issue with this Process ..........................................................................................54 Answer: Issue with this Process ............................................................................................55 Lab 3.1: Hashing Algorithms .....................................................................................................56 Digital Signatures ......................................................................................................................57 Signing a Message ................................................................................................................59 Digital Signature Scenarios ...................................................................................................60 Verify a Digital Signature (part 1) ...........................................................................................62 Verify a Digital Signature (part 2) ...........................................................................................64 Hash-Keyed Message Authentication Code ..............................................................................66 HMAC Scenarios ...................................................................................................................68 Lab 4.1: Hash-Keyed Message Authentication Code (HMAC) Algorithms .................................72 Hybrid Encryption/Decryption ....................................................................................................74 Lab 5.1: Digital Envelopes ........................................................................................................76 Part 1: Summary .......................................................................................................................78 Part 2: Public Key Infrastructure (PKI) Overview .......................................................................79 Digital Certificates .....................................................................................................................81 Certificate Attributes ..............................................................................................................82 PKI Standards and Protocols ....................................................................................................85 X.509 Overview.........................................................................................................................88 Version 1 ...............................................................................................................................88 Version 2 ...............................................................................................................................89 Version 3 ...............................................................................................................................89 Special Certificate Types ..........................................................................................................95 Wildcard ................................................................................................................................95 Self-Signed ............................................................................................................................97 Certification Authorities ...........................................................................................................100 Authenticate Requestors .....................................................................................................101 Issue Certificates .................................................................................................................101 Revoke Certificates .............................................................................................................101 Other Services.....................................................................................................................101

Page 4 of 229

Essential Communication Security Skills for Polycom Solutions

Hierarchical Trust Model .........................................................................................................102 Lab Figure...............................................................................................................................105 Lab 6.1: Examine Digital Certificates.......................................................................................106 Lab 7.1: Install Standalone CA ................................................................................................110 Certificate Stores ....................................................................................................................112 Trusted Root Certification Authorities ..................................................................................113 Certificate Trust Chain .........................................................................................................118 Certificate Signing Requests (CSRs) ......................................................................................122 Generate CSR .....................................................................................................................123 Signing a CSR .....................................................................................................................125 Distinguished Name (DN) ....................................................................................................126 Lab 8.1: Configure the Web Server .........................................................................................127 Lab 8.2: Generate a Certificate for the Web Server .................................................................128 Lab 8.3: Signing of the Certificate Signing Request by the CA ................................................130 Lab 8.4: Install and Configure Web Server Certificate .............................................................132 Certificate Revocation and Suspension ...................................................................................135 Revocation Reasons ...........................................................................................................135 Suspension .........................................................................................................................136 Determining Certificate Revocation .....................................................................................136 Expiration, renewal and destruction .....................................................................................141 Certificate Validation ...............................................................................................................142 Verify Digital Certificate Integrity ..........................................................................................143 Check Digital Certificate Attributes ......................................................................................145 Check Certificate Revocation Status ...................................................................................147 Part 2: Summary .....................................................................................................................148 Lab 9.1: Install Wireshark packet capture tool .........................................................................149 Lab 9.2: Use Wireshark to Perform Packet Capture ................................................................150 Lab 9.3: Perform Wireshark packet capture on a Secure Connection .....................................151 Lab 9.4: Analyze key stages involved in the establishment of a secure connection using TLS 154 Part 3: Secure Sockets Layer (SSL) and Transport Layer Security (TLS) ...............................156 Overview .............................................................................................................................156 Versions ..............................................................................................................................158 Architecture .........................................................................................................................160

Page 5 of 229

Essential Communication Security Skills for Polycom Solutions

Pre-requisite Configuration ..................................................................................................163 SSL/TLS Handshake Sequence ..........................................................................................165 Alert Protocol .......................................................................................................................173 SSL/TLS Mutual Authentication ...........................................................................................175 Implementation ....................................................................................................................178 Applications .........................................................................................................................178 Part 3: Summary and Lab 10 ..................................................................................................179 Lab Figure...............................................................................................................................180 Lab 10.1: Install Sub-ordinate CA............................................................................................181 Lab 10.2: Root CA Signing Sub-Ordinate CA Certificate Request ...........................................183 Lab 10.3: Install the Sub-Ordinate CA Certificate ....................................................................185 Lab 10.4: Place the Root CA in an Off-line State.....................................................................188 Lab 10.5: Configure the Sub-Ordinate Certification Authority ..................................................189 Lab 10.6: Generate a new Certificate Request for the Web Server .........................................190 Lab 10.7: Use the Sub-Ordinate CA to Sign a New Certificate Request for Web Server .........191 Lab 10.8: Install new Certificate on Web Server and Verify the Configuration .........................193 Lab 10.9: Revoke Web Server Certificate ...............................................................................196 Labs 11 - 14 ............................................................................................................................200 Lab Figure...............................................................................................................................201 Lab 11.1: Configure a Linux-based Web Server to support Secure SSL/TLS Connections .....202 Lab 12.1: Demonstrate the Importance of Securing Servers and Private Keys .......................212 Lab 13.1: Configure a Linux-based Web Server to require Mutual SSL/TLS Connections .......217 Lab 14.1: Scenarios on the Apache Web Server for Packet Capture using Wireshark ............226

Page 6 of 229

Essential Communication Security Skills for Polycom Solutions

Course Flow

This course will provide an overview of cryptographic techniques used to provide the key security services of; confidentiality, integrity and authentication (i.e. proof of origin). In addition, it will cover the Public Key Infrastructure (PKI) used to generate, distribute and maintain digital certificates which provides the element of Trust. Finally it will discuss the implementation of a popular communication security technology known as Secure Sockets Layer and the more recently developed Transport Layer Security (TLS) which use the cryptographic techniques and the PKI to secure communication over IP networks.

Page 7 of 229

Essential Communication Security Skills for Polycom Solutions

Course Objectives

Course Objectives • Explain the importance of the security services • List the cryptographic techniques used to provide confidentiality, integrity and authentication • Understand and build a Public Key Infrastructure

• Implement and analyze SSL/TLS communication between client and server

©

Polycom, Inc. All rights reserved.

3

Page 8 of 229

Essential Communication Security Skills for Polycom Solutions

Part 1: Introduction to Cryptography

One of the most important functions of security is to maintain the confidentiality of data and communication. The science of cryptography studies the use of mathematics to encrypt and subsequently decrypt data.

Encryption is an ancient technique for transforming information into an unreadable form using a specific process (i.e. algorithm and key) - the person wishing to understand the information must possess special knowledge (i.e. algorithm and key) to reverse the process. The encryption of sensitive data allows it to be transmitted over public networks (e.g. the Internet) with the assurance that only the intended recipient can decrypt the message and read the content. Similar encryption techniques may be used to protect locally stored data on disks; for example, Microsoft’s Encrypting File System (EFS) and Kilgetty.

Although providing confidentiality is a common requirement of cryptographic techniques, there are other cryptographic services which are of significant importance which include; proof of sender identity and verification that the content has not been altered. These services are known as authentication and integrity and a definition of these is included later in this section.

Unified Communications (UC) provided by Polycom can be considered as just another set of data and protocols using communication based on IP networks. Consequently, from a security perspective, the same best practice technologies and methods should be utilized to protect these services as any other IP data service. The first stage in securing IP communication over a network is to identify the risks faced by the network.

Page 9 of 229

Essential Communication Security Skills for Polycom Solutions

Vulnerabilities The term vulnerability refers to the limitations of a system, or the way in which it is used, that would allow an attack to be successful.

In UC communications a significant risk comes from eavesdropping. The main vulnerabilities which expose this risk are as follows: 

The sending of plaintext authentication credentials across a network (e.g. providing logon credentials to access the administration user-interface of a device)



The transmission of unencrypted voice/video communication across a network



The transmission of other sensitive information (e.g. meeting content)

Threat The main threat to UC network communication comes from Network Analyzers/Packet Capture Tools which can allow capture of video traffic by unauthorized people.

Network Analysers/Packet Capture Tools Packet Capture Tools (e.g. Wireshark) are potentially the most damaging tool employed by malicious hackers. They originally arose out of the need for a tool to debug networking problems. Consequently, they are designed to capture, and store for later analysis, frames traversing a network. For the convenience of the engineer, these tools often allow this procedure to be automated.

Unfortunately, the friendly use of these capture tools has been subverted over the years to perform duties for malicious hackers. If a packet capture tool is located anywhere on the path taken by the data it makes the data vulnerable.

Packet Capture Tool Operation A Packet Capture Tool is software that works in combination with the network interface to collect all traffic passing the listening system, rather than just traffic addressed to the listening system. This is known as operating in promiscuous mode. Packet capture logs can contain megabytes of data so the hacker needs to extract the useful information. Filtering and sorting techniques include: 

disregard anonymous connections



sort log entries by host/site



selecting the destination (for example to capture user accounts/passwords used for a server)

Packet Capture Tools are only able to operate within a single collision domain. A legacy Ethernet system using hubs will have all devices on the same collision domain, whereas a fully switched Ethernet system will only ever have two devices in a collision domain. The

Page 10 of 229

Essential Communication Security Skills for Polycom Solutions

ideal location to place a capture tool varies depending on the information sought. For example, the type of information captured from a standard port on a departmental network will differ significantly from that captured on a backbone link. Some switches include a special port known as a Span Port. This can be used to send a copy of all network packets to a switch port for the purpose of network monitoring.

The Process of Password Capture Packets sent at the start of a session are of particular interest because they may contain login information. For example, a File Transfer Protocol (FTP) session would record information in a packet capture log that may look like this: Computer A => Computer B [FTP] USER smith PASS openSesame ----[END]---The log shows that someone made an FTP connection to an account on computer B using Smith's user name and password. The person reading the log could infer that Smith may also have an account on computer A and that it is likely that Smith uses the same password on that system.

The key to this interception is that the sniffer is able to monitor the communication channel and that Smith's password travels in cleartext. The use of encryption for passwords is an essential part of network security (i.e. cleartext passwords should never be sent across networks).

Page 11 of 229

Essential Communication Security Skills for Polycom Solutions

Risks The key risks to Unified Communications data as it traverses a network are as follows: 

capture of authentication credentials



interception of voice/video traffic and other sensitive information

This captured information can then be used maliciously by the attacker.

Security Response The use of cryptographic techniques can help mitigate (i.e. reduce) this risk. In particular, encryption provides a long-term solution to the threat of network eavesdropping. An example of this is the AES encryption supported by Polycom endpoints. and UC devices can be configured to use encryption when available.

Note: Organizations that require higher security can configure UC devices to always use encryption, however, under these conditions legacy or third party devices that do not support encryption will not be able to participate in UC conferences.

Page 12 of 229

Essential Communication Security Skills for Polycom Solutions

Security Principles

The focus of this course is to consider the techniques that may be used to secure the communication of computer systems across IP networks. However, before considering the specifics, it is important to understand the principles that underpin system security. These principles have been enshrined in both international and national standards such as ISO 7498-2 (Security Services) and X.800 Security architecture for Open Systems Interconnection.

ISO 7498-2 The Security Services described in ISO 7498-2 (Security Services) are highly applicable to a UC communication environment. It defines five tenets or principles of information security: 

Confidentiality



Integrity



Authentication



Non-repudiation



Access Control / Authorization

Confidentiality Maintaining confidentiality prevents the disclosure of information to unauthorized individuals or systems. For example encryption may be used to protect a user name and password used to connect to a resource over a public network. This prevents the use of packet capture tools

Page 13 of 229

Essential Communication Security Skills for Polycom Solutions

to view the user credentials. Encryption may also be used to protect information in its storage location and prevent unauthorized disclosure if someone gains access to the system.

Integrity Maintaining data integrity ensures that information cannot be modified or altered through malicious or accidental means. This service verifies and maintains the accuracy and consistency of the data and prevents/detects unauthorized changes. For example, data integrity procedures can be used to provide assurance that a website download, device driver or software application is genuine.

Authentication Authentication allows the user’s identity to be unequivocally proven. For example, digital certificates may be required in order to identify a network user for the purposes of auditing.

Non-repudiation Non-repudiation techniques are used to provide proof-of-origin and consequently prevent a person from denying ownership of a transaction or document (i.e. accountability).Effective use of non-repudiation techniques makes it possible for electronic information to be used in business / legal transactions. For example, these services are mandatory in order for a Stockbroker to action instructions to buy the shares of a particular company.

Access Control / Authorization Access Control is used to determine the resources a user may use, view, or change. For example, the use of Access Control Lists (ACLs) to determine the rights and privileges a user or group have on a file.

Information Assurance Information assurance is defined as the process of protecting systems and their information by providing the security services (i.e. confidentiality, integrity, non-repudiation, authentication and authorization) by implementing specific security mechanisms which are discussed later in this course.

Although each of the tenets is important, different types of organization will place varying levels of importance on each element. For example, the military would typically place the highest emphasis on confidentiality while a law firm might place more emphasis on nonrepudiation. Each organization must determine an appropriate balance between these services. Risk-aware organizations may choose to implement, operate and maintain their security controls using a security management framework such as ISO 27001 / 2.

Trust The term trust is used to describe the level of confidence placed on a system (i.e. computer or organization). This term is used instead of secure in recognition of the fact that an absolutely secure system is impossible to achieve.

Page 14 of 229

Essential Communication Security Skills for Polycom Solutions

Any entity providing or accessing secure mechanisms should be considered trustworthy.

The goal should be a high enough level of trust in a system to make it suitable for the given application. For example, a user may choose to trust the security implemented by their online banking web site because it requires encrypted communication and a certificate is used to show the web site is genuine.

Terms used in Cryptography Now that we have defined the tenets of security we will return to a consideration of cryptography to see how this can assist with securing communication. In the same way that understanding the basics of IP networking helps with design and troubleshooting so it is important to understand the building blocks of cryptography. Cryptography uses a number of terms which are described below.

Term Plaintext or Cleartext Ciphertext Encryption Decryption Algorithm or Cipher

Key Key Size

Crypto Library

Initialization vector (IV)

Description Data that can be read and understood without any special measures.

Unreadable content.

The method of disguising plaintext in such a way as to hide its substance.

The process of reverting ciphertext to its original plaintext.

A mathematical function used in the encryption and decryption process which defines how data is transformed. The same algorithm must be used for both encryption and decryption.

A word, number or phrase used as an input for the algorithm to encrypt the plaintext and decrypt the ciphertext.

Although keys (e.g. for wireless networks) are entered as alpha numeric text in fact these are used in their binary format so the key length is referred to in bits (e.g. 128-bits). For a given algorithm, the larger the key size the more secure or stronger the encryption.

Various cryptographic techniques (e.g. algorithms and protocols) are bundled into libraries which can be used by applications when a particular cryptographic service is required. Popular implementations used by Programmers include OpenSSL, GnuTLS for SSL/TLS functionality and the CryptoAPI package in Microsoft Windows environments. This simplifies their use by application developers.

A sequence of random bytes appended to the front of the plaintext before encryption. Adding a random initialization vector eliminates the possibility that the initial ciphertext block is the same for more than one message. The mathematicians at Bletchley Park were able to break the Enigma code using a large number of standard format weather reports transmitted to submarines.

Page 15 of 229

Essential Communication Security Skills for Polycom Solutions

Encryption Techniques As mentioned above encryption is used to disguise plain text. To achieve this there are two common techniques: 

substitution



transposition

Substitution This technique takes the original information and substitutes alternate characters to create the ciphertext. Most substitution techniques involve a complex algorithm for determining how the letters are transformed, but a very early example used by Julius Caesar illustrates the idea. The Caesar cipher replaced each letter with the letter 3 positions further into the alphabet.

The message MEET AT MIDNIGHT becomes PHHW DW PLGQLJKW

Transposition The mechanism takes the letters of plaintext and re-orders them to create the ciphertext. For example, a technique known as columnar transpositions take plain text written horizontally and re-orders the letters reading vertically.

For example, the message:

Most modern ciphers use complex algorithms which combine these techniques to produce the ciphertext. The ciphertext results from combining the algorithm and the key. A key is combined with the algorithm to make the ciphertext unique and prevent a simple reversal of the algorithm.

The key provides the special knowledge part of the process and consequently ensures that only the intended recipient is able to decrypt the message. For example the key used in the Caesar algorithm is the number of positions in the alphabet that should be moved to find the substitute letter. For the Roman alphabet this can be any number between up to 25.

Page 16 of 229

Essential Communication Security Skills for Polycom Solutions

Algorithms and Keys

The requirement for secure electronic communication has produced two distinct forms of cryptographic technique:

Symmetric In this technique, the same key (known as a shared key or secret key) is used for both encryption and decryption processes. The key must be distributed securely to the recipient so they can reverse the encryption and re-generate the original plaintext. A method to solve the problem of securely providing the recipient with the key will be discussed in the following pages.

Asymmetric This technique utilizes two mathematically related keys (known as a keypair) comprising a public key and a private key which are used in the encryption and decryption processes.

Typically, the private key is held by a single entity (e.g. user, computer) whilst the public key can be distributed freely to anyone wishing to communicate with them. Often the public key is distributed by use of a digital certificate, which includes identification information. This mechanism provides assurance to the recipient that the public key is genuine (i.e. it belongs to the owner named on the certificate). Digital Certificates will be discussed extensively later on in this course.

Page 17 of 229

Essential Communication Security Skills for Polycom Solutions

Symmetric Technology

Symmetric cryptography is the traditional method using the same key to encrypt and decrypt the message. It offers the cryptographic service of confidentiality (i.e. privacy).

Advantage The main advantage of this technique is speed. Compared to asymmetric algorithms, symmetric algorithms are between 100 and 10,000 times faster. The simplicity and short key lengths of these algorithms (40-256 bits compared with typical lengths of 1024 and 2048 bits) mean far better performance when encrypting large amounts of data and consequently symmetric encryption is the preferred mechanism to provide bulk data encryption (i.e. amounts of data larger than a few kilobytes).

Disadvantage The main vulnerability of this mechanism is during the distribution of the key between sender and recipient. There is a risk that if the key is not securely distributed (i.e. it is intercepted intransit between the two parties) then all information encrypted with that key will be at risk.

A solution for this key distribution issue is provided by Asymmetric or Public/Private Key Technology which is described in detail later in this course.

Page 18 of 229

Essential Communication Security Skills for Polycom Solutions

Symmetric Cryptography Scenarios The following scenarios describe the processes of symmetric encryption and symmetric decryption: Note: Before symmetric encryption/decryption can take place the two parties (i.e. sender and recipient) must possess a copy of the same secret key (i.e. a shared secret). The key distribution mechanism is not specified, however, it must be secure. The key may need to be distributed out-of-band (i.e. not over the Internet) or in an encrypted format.

Symmetric Encryption An explanation of each of the stages of symmetric encryption and decryption is included on the following pages.

A Crypto Library resides on the sender’s computer and provides cryptographic services to applications.

Symmetric Key Encryption

Page 19 of 229

Essential Communication Security Skills for Polycom Solutions

1. Sender chooses to encrypt the plaintext using a symmetric algorithm (i.e. AES) and an appropriate key (i.e. 256-bit)

2. Crypto Library receives request from Sender and requests the AES algorithm to generate ciphertext from the plaintext and key provided. The ciphertext is returned to the Sender.

3. The encrypted message can be sent securely to the Recipient across insecure networks such as the Internet

Page 20 of 229

Essential Communication Security Skills for Polycom Solutions

Symmetric Decryption

Symmetric Key Decryption

1. Recipient receives message containing ciphertext

Page 21 of 229

Essential Communication Security Skills for Polycom Solutions

2. Recipient chooses to decrypt the ciphertext by specifying the appropriate key and cipher

3. Crypto Library requests the AES algorithm to decrypt the ciphertext using the specified key.

The plaintext output is returned to the Sender

Page 22 of 229

Essential Communication Security Skills for Polycom Solutions

Symmetric Mechanisms Symmetric Mechanisms • Stream Ciphers • Block Ciphers − Electronic Code Book Mode (ECB) − Cipher Block Chaining Mode (CBC)

• Symmetric Encryption Algorithms − − − − −

©

DES / 3DES AES IDEA RC4 GOST

Polycom, Inc. All rights reserved.

9

There are two different approaches to symmetric encryption:

Stream Ciphers These algorithms encrypt data one bit at a time. To provide greater security each plaintext digit is combined with a pseudo-random number and then the combination is encrypted using the selected cipher and key. The pseudo-random number generator (PRNG) used in this process is so called because although the numbers it generates are statistically random the process that generates them is not.

This encryption process means that the ciphertext output is always the same length as the original plaintext.

Stream ciphers are typically faster than the block ciphers discussed next but offer less security. Attempts to break stream ciphers usually focus on weaknesses in the PRNG. An example of such a weakness was discovered in the implementation of Wired Equivalent Privacy (WEP) which used PRNGs to create the Initialization Vector (IV) for the RC4 algorithm. If an attacker captured sufficient wireless traffic it was possible to crack 40-bit WEP keys in a few minutes by identifying a pattern of repetition in the IVs.

Block Ciphers In contrast to the bit-by-bit Stream ciphers, these ciphers encrypt blocks of data with a typical block size of 64 bits.

A variety of different methods or modes can be used to encrypt these blocks but the two most common modes are:

Page 23 of 229

Essential Communication Security Skills for Polycom Solutions

Electronic Code Book Mode (ECB) This is considered the weaker format in which each block is encrypted in sequence. This means that matching blocks of plaintext will generate matching blocks of ciphertext. A Cryptanalyst can exploit the repetition in the ciphertext as a basis for breaking the encryption.

Note: A cryptanalyst studies ciphers and ciphertext in order to find patterns that will allow retrieval of the plaintext from the ciphertext, without necessarily knowing the key or the algorithm. This is known as breaking the cipher.

Cipher Block Chaining Mode (CBC) ECB can be strengthened by providing a feedback mechanism so that the encrypted output of a previous block is fed into the encryption of the current block. This means that each block of ciphertext is dependent on both the original plaintext and the sum of all the preceding ciphertext blocks. The feedback mechanism ensures that matching plaintext blocks do not produce matching ciphertext blocks.

However, it should be noted that messages starting with identical texts will produce the same ciphertext up until the first difference.

Initialization Vectors (IVs) The use of random data known as an Initialization Vectors (IVs) inserted into the first block of text to be encrypted can overcome the problem of multiple messages that start with the same sequence.

Padding The length of data encrypted by block ciphers must be a multiple of the cipher's block size.

Typically the plaintext will not be an exact multiple of the block size (e.g. a plaintext length of 60 bits to be encrypted using a 64 bit block cipher) and in such cases the plaintext must be padded (i.e. a 4 bit pad must be appended). The actual text used for padding can vary widely from all zeros to random bits to pre-defined sequences of bits. Some encryption standards actually specify the precise padding scheme that must be utilized.

In summary, stream ciphers are usually consider most appropriate for situations in which the amount of data is either unknown, or continuous (i.e. network streams). Block ciphers are more appropriate when the quantity of data is known (i.e. a file or HTTP request).

Page 24 of 229

Essential Communication Security Skills for Polycom Solutions

Symmetric Encryption Algorithms The table below shows the characteristics of some of the common symmetric algorithms: Acronym

Name

DES

Data Encryption Standard

3DES

Triple DES

Block Cipher 168-bits

AES

Advanced Encryption Standard

Block Cipher 128 to 256-bits

IDEA

International Data Encryption Algorithm

Block Cipher 128-bits

RC4

Rivest Cipher 4 (part of RC family)

Stream Cipher 40 to 128-bits

GOST

Type / Key Size Block Cipher 56-bits

256-bits

Description Up until the 90s, this was used as an official standard by the US government.

Now considered to be too insecure for most applications mainly due to the small key size Superseded DES when it was considered to be vulnerable. A relatively simple variation of the DES algorithm in which the key length was increased without requiring a complete re-design of the algorithm Recently replaced 3DES as the official US government standard. AES uses the Rijndael algorithm.

As mentioned earlier this algorithm can be used to encrypt communication to and from Polycom endpoints.

Originally intended as a replacement for DES. Used in Pretty Good Privacy (PGP).

One of a family of algorithms that offer a range of security levels. Most commonly implemented stream cipher used in Secure Sockets Layer (SSL) and WEP (i.e. secure wireless networks).

GOST is a cryptographic algorithm from Russia. It is an equivalent of DES with a similar structure.

Note: Russian legislation requires special regulations to be met with respect to the development and implementation of the information security solutions. One of the key requirements is certification of the information security solutions which is conditional on the implementation of Russian national cryptographic algorithms. As a result of this legislation many organizations disable the cryptographic capabilities of their solutions when selling to the Russian market.

Page 25 of 229

Essential Communication Security Skills for Polycom Solutions

Lab Figure

Page 26 of 229

Essential Communication Security Skills for Polycom Solutions

Lab 1.1: Install CrypTool Objective In this lab to you will install CrypTool which is an open-source Windows program for cryptography and cryptanalysis. It will be used in subsequent labs to demonstrate various cryptographic techniques.

Steps 1. Connect to the Entry machine using procedure documented in the Getting-Started Guide 2. On the Entry machine, double-click the CLI01 shortcut and when prompted log on using the CLI01 credentials from the Delegate Sheet provided 3. On CLI01, click Start, Run‌ 4. Enter the following path:

\\entry\software 5. Click the OK button 6. When the Software share window opens, double click the SetupCrypTool_1_4_30_en.exe file 7. When prompted with the Security Warning dialog, click the Run button 8. At the Welcome to CrypTool 1.4.30 Setup Wizard dialog, click Next 9. Click I Agree to the License Agreement 10. Keep the default destination folder and click the Install button 11. When the Installation Complete dialog is shown, click Next 12. Remove the tick to Show Readme and click the Finish button - CrypTool should now start 13. Click the Close button on the How to Start dialog 14. Minimize CrypTool 15. Close the Software share window 16. Minimize the CLI01 - Remote Desktop Connection dialog

Page 27 of 229

Essential Communication Security Skills for Polycom Solutions

Lab 1.2: Symmetric Encryption/Decryption using AES Objective In this lab, you will use a symmetric key algorithm (i.e. AES) to demonstrate how a shared secret key can be used with the algorithm to encrypt plaintext to ciphertext and then decrypt the ciphertext back to plaintext.

Pre-Requisite Before using a Symmetric Key algorithm, both parties must possess a shared secret key. This shared key must have been exchanged using a secure mechanism.

Steps 1. Restore the CLI01 – Remote Desktop Connection 2. Restore CrypTool 3. From the File menu, chose the Close - the startingexample-en.txt dialog closes 4. Click File menu, New and type the following phrase: Now you see it and now you don't 5. Click File menu, Save as‌ 6. Specify a File Name of plaintext.txt 7. Click the Save button 8. Click View menu, Show As HexDump 9. Count the number of bytes which represent the plaintext message and record the answer here: ______bytes Note: The figure below shows the bytes section of the dialog. Each pair of hexadecimal digits represents one byte.

Page 28 of 229

Essential Communication Security Skills for Polycom Solutions

10. From the Encrypt/Decrypt menu, choose Symmetric (modern) and in the submenu select Rijndael (AES) …

11. Keep the key length at 128 bits and type the number 1 32 times to overwrite all the 0s (i.e. 32 x 1) 12. Click the Encrypt button – a new window is displayed which shows the ciphertext generated 13. Count the number of bytes which represent the ciphertext message and record the answer here: ______bytes 14. Explain below why the number of bytes in the ciphertext does not match the number of bytes in the original plaintext? _________________________________________________________________ _______________________________________________________________ Hint: Think of the requirements for the second method used by symmetric ciphers.

15. Ensure the new ciphertext dialog is selected (i.e. it should have a blue titlebar) from the Encrypt/Decrypt menu, select Symmetric (modern) and then in the sub-menu select Rijndael (AES)…

16. Keep the key length at 128 bits and enter a key of all 1s (i.e. 32 x 1s) 17. Click the Decrypt button – a new dialog should open showing a message which matches the original plaintext (i.e. plaintext.txt) 18. Close the new plaintext dialog 19. Repeat steps (16) and (17) using a 128 bit key of all 2s (i.e. type the number 2 32 times to overwrite all the 0s)

Page 29 of 229

Essential Communication Security Skills for Polycom Solutions

20. Click the Decrypt button –is the original plaintext now presented in the new window? (Yes or No) 21. Close the new window 22. Again repeat steps (16) and (17) using a 192 bit key of all 1s (i.e. 48 x 1s) 23. Click the Decrypt button, is the original plaintext now presented in the new window? (Yes or No) 24. Close the new dialog 25. Close the ciphertext dialog 26. Minimize the plaintext.txt dialog 27. Minimize CrypTool 28. Minimize the CLI01-Remote Desktop Connection 29. Based on the exercises above, when decrypted a message which 3 settings must match those used for encryption? 

1.

____________________________________________________



2.

____________________________________________________



3.

____________________________________________________

Page 30 of 229

Essential Communication Security Skills for Polycom Solutions

Asymmetric Technology

As discussed above, the main issue with symmetric techniques revolves around secure transfer of the key from sender to recipient. In a groundbreaking 1976 paper, Whitfield Diffie and Martin Hellman proposed the idea of public-key (also called asymmetric key) cryptography. Instead of a single key this uses a pair of different but mathematically linked keys. This solved the problem of secure key distribution because the public key could be distributed while the private key was protected. Although these two keys are mathematically linked, it is practically impossible to compute one from the other. It is possible to use either the public key or the private key to encrypt plaintext. The following rules apply:  



whichever key is used for encryption the other part of the key pair must be used to decrypt in most cases the Public Key is used by the sender to encrypt the plaintext and the recipient uses their associated Private Key to decrypt it. This is the typical approach for ensuring confidentiality. if the Private Key is used for encryption, the associated Public Key must be used for decryption. This approach can be used to prove the identity of the sender.

The security of the private key is very important. This is the property of a single user or computer and should be protected from unauthorized access.

Page 31 of 229

Essential Communication Security Skills for Polycom Solutions

Public Key Distribution In most cases knowledge of the public key does not provide a means to decrypt the message. This means it can be distributed to anyone wishing to send secure data to the owner of the private key. Public keys can be distributed in a wide variety of ways including: 

USB key



E-mail



A key server – these can be located within an organisation or on the Internet and mean there is no need for direct contact with the sender in order to receive encrypted information from them.

Important: A public key does not provide any identification for its owner. It is therefore important when to confirm that the key has been supplied by the intended recipient and that they hold the matching private key. Techniques such as a spoofed email could be used by an attacker to provide a false public key for which they have the private key. The Public Key Infrastructure (PKI) and digital certificates were developed to provide confirmation that a public key is genuine by identifying its owner.

Security Services Provided by Public Keys The cryptographic services that may be offered by asymmetric mechanisms are confidentiality, authentication and non-repudiation. The choice of which key to use for encryption determines which security service is provided:

Confidentiality In order to provide confidentiality, the public key would be used to encrypt the data and the associated private key for data decryption. This means that potentially anyone can encrypt the information but ONLY the holder of the private key can decrypt it.

Asymmetric algorithms are much slower than symmetric but can assist with the problem of key distribution. This process is commonly used to encrypt a secret key (i.e. symmetric key) before distribution.

Authentication/Non-Repudiation Reversing the use of the keys makes it possible to establish proof-of-origin. The private key is used to encrypt some data and the associated public key is used to decrypt the data. This procedure does not provide any confidentiality since any party with a copy of the public key would be able to view the plaintext. This procedure does provide an authentication service.

The successful decryption of the data using the sender’s public key proves that the owner of the private key must have sent the data and this key is only possessed by a single entity (i.e. user or computer).

A Private key must be securely stored and should never be transmitted or shared. Its use is typically protected using a PIN or passphrase so use of the key requires access to the private key and knowledge of the PIN.

Page 32 of 229

Essential Communication Security Skills for Polycom Solutions

Note: This provides a form of security known as two-factor authentication. The key is something you have and the PIN is something you know. The third possible method for authentication is something you are which uses methods such as fingerprints and retina scans.

Note: It is also common for private keys to be protected by the operating system as part of a user's profile. This method is commonly used for private keys stored within Windows.

Asymmetric Encryption Algorithms The table below shows the characteristics of some of the common asymmetric algorithms: Acronym RSA

Name Rivest Shamir Adelman

Key Size 512 to 4096-bits

DH

Diffie-Hellman

n/a

DSA/DSS

Digital Signature Algorithm / Standard

1024-bits

Elgamal

256 to 4096-bits

Description The most commonly used asymmetric algorithm.

It can be used for encryption, key exchange and authentication.

An algorithm specifically designed for key exchange rather than encryption. However, once both parties have a copy of the shared key a symmetric algorithm can be used to provide encryption.

DSA provides an algorithm for digital signatures (i.e. authentication/non-repudiation) based on Elgamal and developed for the Digital Signature Standard (DSS).

Utilizes the DH key exchange to provide encryption (i.e. Elgamal encryption) and digital signatures (i.e. Elgamal signature scheme).

Although, asymmetric and symmetric key sizes are not directly comparable, a rule-of-thumb is that an 80-bit symmetric key has approximately the equivalent strength of a 1024-bit asymmetric key.

The larger asymmetric bit size is necessary because the mathematical link between the private and public keys means that with enough time and processing power it is theoretically possible to derive one from the other. However, the selection of large key sizes makes this brute force attack practically impossible in terms of time and resource. Unfortunately, the large key sizes means the encryption/decryption process is slow and more CPU intensive.

Note: A brute force attack uses a computer to try every possible key until one provides a meaningful response.

Page 33 of 229

Essential Communication Security Skills for Polycom Solutions

Asymmetric Cryptography Scenarios The following show the various scenarios in which asymmetric techniques can be used:

Key Distribution

Bob would like to send confidential bulk data to Alice. The amount of data requires the use of a symmetric key algorithm (i.e. AES). Before a symmetric algorithm can be used, both parties must have a copy of the same secret (i.e. shared) key. The secret key can be distributed securely by using an asymmetric technology such as RSA. Note: A bit of history - Ron Rivest, Adi Shamir and Len Adleman - the R, S and A in RSA Security - introduced Alice and Bob in their public-key cryptosystem paper in 1978 and the couple have been used in public / private key examples ever since.

Page 34 of 229

Essential Communication Security Skills for Polycom Solutions

Key Distribution (Encrypt)

Key Distribution (Encrypt Key)

1. The sender plans to use AES and requests a secret key from Crypto Library.

2. This is generated and returned to the sender.

3. The Crypto Library on the sender’s computer is requested to encrypt the secret key (i.e. the AES key is the plaintext) using the RSA algorithm and needs the public key of the recipient to complete this task.

Note: Typically an application such browser would request the services of the Crypto Library.

Page 35 of 229

Essential Communication Security Skills for Polycom Solutions

4. The Crypto Library requests the RSA algorithm to encrypt the plaintext and provides the public key for the recipient as determined by the key identifier

The ciphertext (i.e. encrypted AES key) is returned to the Sender

5. The ciphertext (containing the secret key), algorithm and key identifier can be sent to the recipient.

Page 36 of 229

Essential Communication Security Skills for Polycom Solutions

Key Distribution (Decrypt)

Key Distribution (Decrypt Key)

1. The recipient receives the ciphertext (see figure below) along with key identifier (i.e. s1@medeatalk.com) and algorithm (i.e. RSA)

2. The recipient (i.e. user or application) requests the Crypto Library to decrypt the ciphertext selecting a key that matches the algorithm used and the key identifier

Page 37 of 229

Essential Communication Security Skills for Polycom Solutions

Note: In the figure above it can be seen that the recipient not only has keys for different algorithms (i.e. RSA and DSA) but also may have multiple keys for the same algorithm (i.e. RSA). It is the responsibility of the key identifier to ensure that the correct private key is used for decryption.

A PIN or phase-phrase may need to be supplied in order to unlock the private key for use.

Page 38 of 229

Essential Communication Security Skills for Polycom Solutions

3. The Crypto Library requests the algorithm to decrypt the ciphertext. The resulting plaintext is returned to the recipient.

Note: RSA uses a block encryption mechanism and as a result the example decrypted ciphertext shows the null characters as the dots at the end of the key.

4. The decrypted key is securely stored ready to be used for decryption of bulk data.

Page 39 of 229

Essential Communication Security Skills for Polycom Solutions

Authentication of Data (i.e. proof-of-origin)

Bob has an important legal document to send to Alice. Alice wishes Bob to send the document in a way which enables her to prove that Bob was the sender (i.e. the cryptographic service of authentication and non-repudiation). Bob encrypts the document using his own private key and sends it to Alice. Alice uses Bob’s public key to successfully decrypt the document and consequently has proof that Bob was the sender. The document would only decrypt successfully if Bob’s private key was used to encrypt it and only Bob has possession of the private key.

Note: Although the document has been encrypted there is no guarantee of confidentiality since any person with a copy of Bob’s public key would be able to decrypt it.

Page 40 of 229

Essential Communication Security Skills for Polycom Solutions

Authenticate Sender

Authenticate Sender (Generate Source)

1. To prove their identity the Sender requests the Crypto Library to encrypt the plaintext using their private key, in this case using the RSA algorithm.

Note: The Sender may need to provide a PIN or pass-phrase to provide access to the private key.

2. The Crypto Library requests the RSA algorithm to encrypt the plaintext using the private key. The resulting ciphertext is returned to the Sender 3. The ciphertext, algorithm and key identifier are sent to the Recipient

Page 41 of 229

Essential Communication Security Skills for Polycom Solutions

Authenticate Sender (Verify Source)

Authenticate Sender (Verify Source)

1. The ciphertext, algorithm and key identifier are received by the Recipient and they request that the Crypto Library decrypts the ciphertext, using the RSA algorithm and the sender’s public key 2. The Crypto Library locates the public key of the Sender using the Key Identifier 3. The Crypto Library decrypts the plaintext and returns this to the Recipient.

Note: A readable plaintext message shows that the private and public keys are part of the same key pair.

Page 42 of 229

Essential Communication Security Skills for Polycom Solutions

Question: Issues with this Procedure

Hint: When answering the question you should consider whether Asymmetric encryption is a good choice to encrypt a confidential video call.

Page 43 of 229

Essential Communication Security Skills for Polycom Solutions

Answer: Issues with this Process

Performance This procedure would require an asymmetric algorithm to perform bulk data encryption/decryption which would be extremely slow compared to a symmetric mechanism.

Assurance Public Key is Genuine The Recipient must ensure that they have the public key for the genuine Sender. This could be achieved by the Recipient and Sender meeting to exchange public keys but this requires prior meeting before a secure exchange can take place. Other means of providing public keys, such as emails, can be exploited by hackers who pretend to be the Sender.

Later in the course the use of digital certificates will be examined, these associate the public key with an owner in a manner which can be verified and trusted.

Page 44 of 229

Essential Communication Security Skills for Polycom Solutions

Lab 2.1: Asymmetric Encryption/Decryption Objective In this lab, you will use the RSA algorithm to examine the process of encrypting and decrypting plaintext using asymmetric techniques.

Remember: One half of the asymmetric key pair, known as the public key, is used to encrypt the plaintext. The other half of the key pair, known as the private key, is used to decrypt the ciphertext. Whilst the public key can be distributed freely to any interested party, the private key must be held by a single entity and it is typically protected by a pass phrase or PIN.

Steps 1. Restore the CLI01 – Remote Desktop Connection

Sub-Task 2.1.1: Generate a key pair using the RSA algorithm 2. Restore CrypTool 3. Restore plaintext.txt window 4. From the Digital Signatures/PKI menu, select PKI and then Generate/Import Keys…

5. In the Generation of Asymmetric Key Pair dialog, ensure RSA is selected 6. In the Bit length drop-down list ensure 1024 bits is selected 7. In the User data section, enter the following information:

Parameter Last name First name Key identifier [optional] Pin Pin Verification

Value One Student s1@medeatalk.com 1234 1234

8. Click the Generate new key pair… button 9. If requested, move the mouse around to generated random data and click OK when finished 10. When prompted with the CrypTool dialog, click OK to acknowledge key pair saved message 11. Click the Close button

Page 45 of 229

Essential Communication Security Skills for Polycom Solutions

Sub-Task 2.1.2: Encrypt the plaintext 1. From the Encrypt/Decrypt menu, select Asymmetric and then RSA Encryption …

2. Highlight the Student One recipient key and click the Encrypt button – ciphertext should now be generated in a new window

Sub-Task 2.1.3: Decrypt the ciphertext 1. Ensure the new ciphertext dialog is selected (i.e. blue titlebar) 2. From the Encrypt/Decrypt menu chose Asymmetric, RSA Decryption …

3. Highlight the Student One secret key 4. Click the Decrypt button 5. Record why does the decryption not proceed? ___________________________________________________________________ 6. Click OK to acknowledge the message 7. In the PIN code text box (bottom right) enter a pin of 1234 8. Click the Decrypt button – a new window should open showing the decrypted ciphertext which should match the original plaintext.txt input 9. Close the new plaintext dialog 10. Ensure the ciphertext dialog is selected 11. From the Encrypt/Decrypt menu, select Asymmetric, RSA Decryption…

12. Choose the Student One key and enter a PIN code of 1111 13. Click the Decrypt button 14. What message is displayed? ___________________________________________________________________ 15. Click OK to acknowledge this message 16. Close the ciphertext window 17. Minimize the plaintext.txt dialog 18. Minimize CrypTool 19. Minimize the CLI01 - Remote Desktop Connection

Page 46 of 229

Essential Communication Security Skills for Polycom Solutions

Message Digest/Hashing

Hashing or Message Digest algorithms are a third type of cryptographic mechanism which is designed to provide assurance of message integrity – in other words that the message has not been altered in transit.

The algorithms are capable of generating a fixed length (e.g. 128-bit) fingerprint from any length of input. The fingerprint or checksums are known as a hash or message digest.

Page 47 of 229

Essential Communication Security Skills for Polycom Solutions

The hashes generated are cryptographically strong which means they are designed to generate a different digest/hash when even the smallest change has been made to the input data.

An example of using Message Digests can often be seen when downloading an application or file from a website. In the figure below, the WinSCP website (winscp.net) download page shows links to the various releases of the WinSCP and also provides a link to the checksums for the package:

The checksums are provided for two different hashing algorithms (i.e. MD5 and SHA1):

A trusted and verified checksum can be used to check that a downloaded package is genuine and un-corrupted. There are many free tools which can be used to create a checksum from a file.

The hash generated by the algorithm should match the checksum provided in the release notes:

Page 48 of 229

Essential Communication Security Skills for Polycom Solutions

If a matching hash is generated (as shown above) then the administrator can be assured that the package has not been altered either through corruption or the insertion of malicious code.

Unlike the algorithms examined earlier, message digest algorithms do not require a key and they only work in one direction (i.e. it is not possible to reverse the process and re-generate the original data).

Common hashing algorithms include the following: Acronym MD5

Name Message Digest 5

Digest Size 128-bits

SHA-1

Secure Hash Algorithm

160-bits

SHA-2

Secure Hash Algorithm series 2

224 to 512-bits

Description It is employed in a wide variety of security applications to check data integrity. It has been known for a long while that it was not collision resistant (see note below) and nowadays it is recommended to use the slightly slower SHA-1 instead Still the most commonly used of the SHA family.

However, in 2005 significant security flaws were discovered and it was recommended to use SHA-2.

This algorithm is used with DSA/DSS (discussed earlier) for digital signatures.

The current recommendation for integrity checking. It is most commonly implemented as SHA-256.

Note: When two different data inputs result in the same hash it is known as a collision.

Hashing algorithms need to be highly collision resistant since if an attacker can manipulate the input to generate the same hash then any integrity assurance is lost.

Page 49 of 229

Essential Communication Security Skills for Polycom Solutions

Message Digest Scenarios The following are scenarios in which hash/message digest techniques can be used:

Generate Hash

Generate Hash

1. Sender requests the Crypto Library generate a hash of the plaintext using a specific algorithm (i.e. MD5) 2. Crypto Library passes the plaintext to the MD5 algorithm and the resulting hash is returned to the Sender

Page 50 of 229

Essential Communication Security Skills for Polycom Solutions

3. The plaintext is sent to the Recipient with an accompanying hash and algorithm selection

Page 51 of 229

Essential Communication Security Skills for Polycom Solutions

Verify Hash

Verify Hash

1. The plaintext is received by the Recipient with an accompanying hash (i.e. hash 1) and algorithm selection 2. Recipient requests the Crypto Library to generate a hash (i.e. hash 2) of the plaintext using the specified algorithm (i.e. MD5) 3. The Crypto Library generates the hash and returns it to the recipient 4. Recipient requests the Crypto Library to compare the hashes – if the hashes match then the Recipient gains integrity assurance, however, if the hashes don’t match then the plaintext has lost integrity (i.e. it may have been corrupted in transit or altered)

Page 52 of 229

Essential Communication Security Skills for Polycom Solutions

In the figure above, a small change has been made to the original plaintext (i.e. a full-stop has been added to the end of the sentence). A subsequent, comparison of the original file hash and the modified file hash show a significant difference between them (i.e. the file has lost integrity).

Page 53 of 229

Essential Communication Security Skills for Polycom Solutions

Question: Issue with this Process

Hint: How could an attacker fool someone into downloading a compromised version of a file and convincing them that it is genuine?

Page 54 of 229

Essential Communication Security Skills for Polycom Solutions

Answer: Issue with this Process

Possible to modify plaintext and associated hash An individual with malicious intent could provide a spoofed download site containing files and their matching hashes. They could also intercept the plaintext and accompanying hash.

They would be in position to modify both the plaintext and the associated hash before forwarding to the Recipient. The Recipient would be unaware that any change to the plaintext had occurred since the accompanying hash matches any hash generated by the Recipient using the specified algorithm. A mechanism to overcome this issue called Digital Signatures is described in the next topic.

Page 55 of 229

Essential Communication Security Skills for Polycom Solutions

Lab 3.1: Hashing Algorithms Objective In this lab, you will use a hashing algorithm (i.e. MD5) to show how data integrity can be provided using cryptographic techniques. These algorithms are designed to show a significant change in the generated hash even if there is only a small change in the input.

Steps 1. Restore the CLI01 – Remote Desktop Connection 2. Restore CrypTool dialog 3. Restore the plaintext.txt dialog 4. From the Indiv. Procedures menu, select Hash and then select Hash Demonstration…

5. In the Selection of hash function section (top left), select MD5 (128 bits) from the dropdown menu Note: CrypTool has copied the text for the plaintext.txt file into the Modified document section.

6. Does the Hash value of the original file match the Hash value of the modified file?

(Yes/No) 7. In the Modified document section, add a full-stop (i.e. a point) at the end of the sentence – the hash in the hash value of the modified file section should now change.

8. In the Difference between the hash values of the original and the modified file section (bottom of dialog), record the number of bits which differ of the 128 bits fingerprint here: ___ of 128 bits 9. Now remove the full stop from the end of the sentence in the Modify document section.

10. Has the Hash value of the modified file now returned to the Hash value of the original file? (Yes or No) 11. Click the Close button - the Hash Demonstration dialog closes 12. Minimise the plaintext.txt dialog 13. Minimise the CLI01 – Remote Desktop Connection for use in a later lab

Page 56 of 229

Essential Communication Security Skills for Polycom Solutions

Digital Signatures

As discussed in earlier in this course, asymmetric algorithms can provide a cryptographic authentication service using the private key to encrypt the data. However asymmetric algorithms are too slow for bulk data encryption/decryption.

This performance issue can be overcome by using a combination of asymmetric and hashing techniques. In addition, the use of the two mechanisms extends the services provided to include both data integrity and non-repudiation. A further benefit of using asymmetric encryption is to prevent the malicious alteration in transit of both plaintext and hash by an attacker.

As the name suggests, a digital signature is the electronic equivalent of a hand-written signature on a document. It serves the same purpose as a handwritten signature (i.e. authentication and non-repudiation), but, unlike a written signature it is almost impossible to counterfeit.

It is created by passing the bulk data (e.g. a document) through a hashing algorithm to generate a hash. This hash can then be protected from modification by encryption using the Private Key of the Sender. This procedure has the following advantages:  

successful decryption of the hash using the Public Key of the Sender proves authenticity asymmetric encryption/decryption is performed on only a small piece of data (i.e. the hash) which means any performance penalty is minimized

Page 57 of 229

Essential Communication Security Skills for Polycom Solutions



if the Recipient creates a hash of the bulk data and this matches the hash from the decrypted signature then they can be assured of both: o data integrity (i.e. no corruption or malicious changes) o non-repudiation (i.e. the Sender cannot claim they didn’t send the document or that the document is not the original)

Note: Any change to a document invalidates the entire signature; if changes are needed, the document needs to be signed again.

Page 58 of 229

Essential Communication Security Skills for Polycom Solutions

Signing a Message

Bob’s crypto library applies a hash function to the message - this creates a message digest.

The system then encrypts the message digest using Bob’s private key. The encrypted message digest – i.e. the digital signature – is then appended to the original message.

Alice’s software decrypts the digital signature using Bob’s public key to obtain the message digest. Alice’s software then performs the same hash function on the original message to create another message digest for comparison - if the message digests do not match then the message has been altered in transit. If the message digest cannot be decrypted then Bob’s private key was not used to encrypt the message digest.

Page 59 of 229

Essential Communication Security Skills for Polycom Solutions

Digital Signature Scenarios The following are scenarios for the use of digital signatures:

Generate Digital Signature

Generate Digital Signature

1. Sender requests Crypto Library to hash the plaintext using a specified hashing algorithm (i.e. MD5).

2. Crypto Library passes plaintext to the MD5 algorithm and the resulting hash is returned to the Sender.

3. Sender requests Crypto Library to encrypt the hash using an asymmetric algorithm (i.e.

RSA), specifies own private key and any associated PIN which may be required.

4. Crypto Library passes hash and Sender’s private key to the RSA algorithm. The resulting digital signature is returned to the Sender.

Note: The steps above may all be combined into a single process (see figure below):

Page 60 of 229

Essential Communication Security Skills for Polycom Solutions

The figure above shows the selection of a hashing algorithm (i.e. MD5), the selection of the Sender’s private key and the specifying of a PIN to decrypt the private key for use.

5. The signed message is sent to the Recipient.

The figure above shows the signed message which includes the following:  Signature  Algorithms  Key identifier  Plaintext

Page 61 of 229

Essential Communication Security Skills for Polycom Solutions

Verify a Digital Signature (part 1)

Verify a Digital Signature (part 1)

1. The Recipient receives the signed message

2. The Recipient requests the Crypto Library to locate the correct public key in the key store using the key identifier

Page 62 of 229

Essential Communication Security Skills for Polycom Solutions

3. Recipient requests Crypto Library to decrypt the digital signature using the specified algorithm (i.e. RSA) and public key obtained in the previous step.

4. Crypto Library passes digital signature and public key to RSA algorithm and the decrypted hash (i.e. hash 1) is returned to the Recipient.

5. Recipient requests Crypto Library to hash the plaintext using the specified algorithm (i.e.

MD5).

6. Crypto Library passes plaintext to MD5 algorithm and the resulting hash (i.e. hash 2) is returned to the Recipient.

Page 63 of 229

Essential Communication Security Skills for Polycom Solutions

Verify a Digital Signature (part 2)

Verify a Digital Signature (part 2)

1. Recipient requests Crypto Library to compare the two hashes returned.

2. Crypto Library compares the hashes (i.e. hash 1 and hash 2) and returns to the Recipient one of two possibilities:



The signature verification passed.

The two hashes match indicating that the Recipient can be assured of both the document integrity, proof-of-sender (i.e. authenticity) and consequently nonrepudiation.



The signature verification failed.

The two hashes don’t match indicating either the document has been altered since it was signed (i.e. no integrity) or the private key of the Sender was not used to

Page 64 of 229

Essential Communication Security Skills for Polycom Solutions

sign the document (i.e. no authenticity).

Heads-Up: Digital Signatures are used in digital certificates to prove the identity of the Certification Authority issuing the certificate. These terms and concepts will be discussed in more detail later in the course.

Page 65 of 229

Essential Communication Security Skills for Polycom Solutions

Hash-Keyed Message Authentication Code

The HMAC versions of hashing algorithms extend the cryptographic services provided by these algorithms to include not only integrity but also authentication.

Unlike digital signatures they do not use private and public keys. The additional service is achieved by combining the plaintext with a shared secret key before using the result as the input for a hashing algorithm. The output hash is known as a Message Authentication Code (MAC).

Page 66 of 229

Essential Communication Security Skills for Polycom Solutions

Note: As with symmetric mechanisms, the secret key must be known to the Sender and Recipient only. The mechanism for distributing the key securely is not prescribed but typically would use an asymmetric mechanism.

The Recipient using a Crypto Library can gain assurance of both integrity and authenticity as follows:  

generate a second MAC by inputting the concatenation (i.e. one after the other) of plaintext and shared secret key into the hashing algorithm compare the newly generated MAC with the original MAC supplied by the Sender along with the plaintext. If the MACs match, then the Recipient can be assured of the following: o the plaintext has not been altered (i.e. integrity) o the same secret was used by the other party (i.e. authenticity since only the Sender possesses knowledge of the secret key) Note: There is no guarantee of non-repudiation since there are two parties (i.e. Sender and Recipient) which have possession of the secret key.

There are HMAC versions of all the common hashing algorithms (e.g. HMAC-MD5, HMACSHA-1, HMAC-SHA-256).

The use of MACs is common in situations where performance must be maximized because the algorithms are extremely fast. For example, they are used during the bulk data transfers in the SSL/TSL protocol (discussed later in this course).

Page 67 of 229

Essential Communication Security Skills for Polycom Solutions

HMAC Scenarios The following are scenarios showing the use of HMACs:

Generate Message Authentication Code

Generate MAC

1. Sender requests Crypto Library to generate a MAC of the plaintext and secret key using a specified hashing algorithm (i.e. HMAC-MD5).

2. Crypto Library passes plaintext and secret key to the HMAC-MD5 algorithm and the resulting MAC is returned to the Sender.

Page 68 of 229

Essential Communication Security Skills for Polycom Solutions

In the figure above, the message (i.e. plaintext) and key have been concatenated together in order to generate the HMAC. 3. The plaintext is sent to the Recipient with an accompanying MAC and algorithm selection

Page 69 of 229

Essential Communication Security Skills for Polycom Solutions

Verify Message Authentication Code

Verify MAC

1. The plaintext is received by the Recipient with an accompanying MAC (i.e. MAC 1) and algorithm selection 2. Recipient requests the Crypto Library to generate a MAC (i.e. MAC 2) of the plaintext and secret key using the specified algorithm (i.e. HMAC-MD5) Note: The Recipient must previously receive a copy of the secret key using a secure key distribution mechanism.

3. Recipient requests the Crypto Library to compare the MACs – if the MACs match then the Recipient gains assurance of both integrity and authenticity. However, if the MACs don’t match then either;

Page 70 of 229

Essential Communication Security Skills for Polycom Solutions



the plaintext has lost integrity (i.e. it may have been corrupted in transit or altered)

In the figure above, the message has changed and consequently a different MAC is generated. 

the authenticity (i.e. origin) of the plaintext cannot be verified since a different key has been used.



In the figure above, the key has changed and consequently a different MAC is generated.

Page 71 of 229

Essential Communication Security Skills for Polycom Solutions

Lab 4.1: Hash-Keyed Message Authentication Code (HMAC) Algorithms Objective In this lab, you will use an HMAC algorithm to demonstrate the use of these algorithms to provide the cryptographic services of integrity and proof-of-origin (i.e. authenticity).

Pre-Requisite Before using an HMAC algorithm, both parties must possess a shared secret key.

This shared key must have been exchanged using a secure mechanism (i.e. this typically means using an asymmetric technology for key exchange).

Steps 1. Restore the CLI01 – Remote Desktop Connection 2. In CrypTool, restore the plaintext.txt window 3. From the Indiv. Procedures menu, select Hash and Generation of HMACs … - the Keyed-Hash Message Authentication Code (HMAC) dialog is opened with the message from the plaintext.txt dialog displayed in the Message section 4. In the HMAC parameter and key section, choose a hash function of MD5 (128 bits) from the drop-down list 5. In the Enter your key (k) textbox, specify a secret key of 1234 6. From the HMAC Variant drop-down list, choose H{k, m}: key in front of message –the Input for outer hash function dialog now shows the concatenation of key and message Note: There are variants of the HMAC which alter the input – for example, an alternative variant would place the message in front of the key.

7. In the HMAC generated from message and key section (at the bottom of the dialog), record the 32-digits of hexadecimal generated below: __________________________________________

Sub-Task 4.1.1: Demonstrate a loss of message integrity 1. In the Message section, place a full-stop (i.e. a point) at the end of the sentence 2. Record the HMAC generated from the message and key on the line below: __________________________________________ 3. Compare the original HMAC generated with the newly generated HMAC. Are they the same? (Yes or No)

Page 72 of 229

Essential Communication Security Skills for Polycom Solutions

4. Remove full stop from the message and verify the HMAC has returned to the original value

Sub-Task 4.1.2: Demonstrate what happens when the sender uses an incorrect shared key (i.e. lose of authenticity) 1. In the HMAC parameter and key section, specify the Enter your key (k) value as 1111 2. Record the newly generated HMAC on the line below: _____________________________________________ 3. Does the newly generated HMAC match the original HMAC? (Yes or No) 4. Return the shared key to 1234 and verify the newly generated HMAC matches the original HMAC again 5. Close the Keyed-hash message authentication code (HMAC) dialog 6. Minimize the plaintext.txt window 7. Minimize the CLI01 – Remote Desktop Connection for use in a later lab

Page 73 of 229

Essential Communication Security Skills for Polycom Solutions

Hybrid Encryption/Decryption

Page 74 of 229

Essential Communication Security Skills for Polycom Solutions

In most applications, symmetric and asymmetric techniques are combined to take advantage of the strengths of each technology.

1. The asymmetric encryption algorithm is used to encrypt a secret key so that the key can be securely distributed to the other party. This minimises any performance loss since only a small amount of data (i.e. the secret key) requires asymmetric encryption which is relatively slow.

2. Once the key has been securely distributed to the other party, the bulk data can be encrypted using a symmetric algorithm and the shared secret key. This maximises performance by using a fast symmetric mechanism for the bulk of the data.

A Hybrid mechanism further optimises this process by transmitting both these elements (i.e. asymmetrically encrypted secret key and symmetrically encrypted bulk data) in a single package known as a Digital Envelope.

In the figure above, the secret key (i.e. encrypted session key), bulk data (i.e. ciphertext), key identifier and hybrid approach can be seen.

On receiving the package, the Recipient uses their private key to decrypt the secret key and then subsequently, they can use the secret key to decrypt the bulk data.

The use of Digital Envelopes is popular in applications offering services such as E-mail.

Page 75 of 229

Essential Communication Security Skills for Polycom Solutions

Lab 5.1: Digital Envelopes Objective In this lab, you will demonstrate the use of both Symmetric algorithms (i.e. AES) and Asymmetric algorithms (i.e. RSA) in order to optimize the cryptographic process.

Remember: This hybrid approach, known as a Digital Envelope, uses the fast symmetric algorithm to encrypt bulk data, a slower asymmetric algorithm for secure distribution of the symmetric shared key and finally, transfers both the encrypted plaintext and encrypted secret key in the same package (i.e. the envelope).

Steps 1. Restore the CLI01 – Remote Desktop Connection 2. In CrypTool, restore the plaintext.txt dialog

Sub-Task 5.1.1: Encrypt the plaintext using hybrid encryption 1. From the Encrypt/Decrypt menu, select the Hybrid sub-menu and then select RSAAES Encryption… - the Hybrid Encryption with RSA-AES dialog is displayed with the plaintext shown 2. Click the red Generate session key action box – the box turns green 3. Click on the blue Session key output box - a randomly generated AES key is displayed at the bottom of the dialog. Record the 32 digit hexadecimal key here: ________________________________________________________________ 4. Click the red Encrypt document symmetr. action box – the box turns green 5. Click on the blue Encrypted document output box - the ciphertext of the document is displayed at the bottom of the dialog 6. Click the red Select asymmetr. key action in the top right 7. Choose the Student One receiver key (i.e. the public key of the recipient) and click OK – the Select asymmetry. Key box turns green 8. Click the blue Asymmetr. key output box – a Public key of: One Student is displayed Note: The public key is comprised of a Modulus and an Exponent whilst the private key shares the same Modulus but has a different Exponent value.

9. Click the Back button to close the dialog 10. Click the red Encrypt session key asymmetr. action box – the box turns green 11. Click on the blue Encrypted session key - the encrypted session key is displayed at the bottom of the dialog

Page 76 of 229

Essential Communication Security Skills for Polycom Solutions

12. Click the yellow Save button – a new ciphertext dialog is now displayed.

Note: With careful examination of the right-hand column of the ciphertext, it is possible to determine use of the key identifier (i.e. Student One), the encrypted session key, the symmetric (i.e. AES) and asymmetric algorithms (i.e. RSA) and the ciphertext.

Sub-Task 5.1.2: Decrypt the hybrid encryption ciphertext 1. Ensure the ciphertext dialog is selected (i.e. blue titlebar) 2. From the Encrypt/Decrypt menu, select the Hybrid sub-menu and choose RSA-AES Decryption… - the Hybrid Decryption with RSA-AES dialog is displayed 3. Read the description for step 1 and click Continue 4. Highlight the Student One private key (i.e. recipient) and enter a pin code of 1234 to unlock the key 5. Click OK 6. Read the description for step 2 and click Continue Note: the value of d is the private key exponent.

7. Read the description for step 3 and click Continue - the 32-digit hexadecimal session key is now displayed 8. Record this 32-digit hexadecimal below: _____________________________________ 9. Does this key match the session key recorded in Sub-Task 1? (Yes/No) 10. Click the Decrypt button – the decrypted ciphertext is now displayed in a new window 11. Does the decrypted ciphertext match the original plaintext? (Yes/No) 12. From the File menu, select the Exit option – CrypTool closes 13. Minimize the CLI01 – Remote Desktop Connection for use in later labs

Page 77 of 229

Essential Communication Security Skills for Polycom Solutions

Part 1: Summary

Part 1: Summary • Introduction to Cryptography − Cryptographic Services − Algorithms − Symmetric − Asymmetric − Hashing

©

Polycom, Inc. All rights reserved.

15

The first part of this course covers the building blocks of cryptography. The algorithms and techniques described in this part are used by the Public Key Infrastructure (PKI) which follows in part 2. They are also used to secure communication using protocols such as SSL and TLS, which are discussed in part 3.

Page 78 of 229

Essential Communication Security Skills for Polycom Solutions

Part 2: Public Key Infrastructure (PKI) Overview

The Public Key Infrastructure (PKI) provides a secure mechanism for information exchange and identification based on public/private key cryptography. The two foundation stones of the PKI are: 

Digital Certificates - electronic identification of objects such as individuals, computers and organizations including an associated public key

Page 79 of 229

Essential Communication Security Skills for Polycom Solutions



Certificate Authority (CA) – organizations that verify identity and issue digital certificates which bind the identity of subject with an associated public key. If a CA is trusted by an organization then any certificates issued by that CA are considered trustworthy.

Page 80 of 229

Essential Communication Security Skills for Polycom Solutions

Digital Certificates

As described in part 1 it is vital that a sender can verify that a public key is owned by the intended recipient and that it is not a fake key posted by an attacker. To remove this risk for the Sender, the public key owner (e.g. user or computer) can register themselves and their associated public key with a central authority known as a Certification Authority (CA). The CA is responsible for checking the identity of the owner using various types of documentation (e.g. an identity card). If the CA can successfully verify the owner is legitimate, it will issue a digital certificate which binds together the owner identification, the associated public key and various additional attributes (e.g. a validity period) into a package. The CA will then use its private key to encrypt a hash of the resulting package (i.e. a digital signature). The digital certificate is comprised of the package and the digital signature of the CA appended to the bottom of the document to provide both integrity and authenticity.

So from the techniques covered in part 1 digital certificates use:   

Asymmetric cryptography – the public key is embedded in the certificate Hash algorithms to ensure the integrity of the certificate A digital signature using the private key of the CA

Page 81 of 229

Essential Communication Security Skills for Polycom Solutions

Certificate Attributes A more detailed examination of a digital certificate shows that it consists of many attributes which include the following: Attribute Version

Description Three versions of X.509 digital certificate standard can be used in a PKI

Serial Number

Certificate serial number or ID. This is a numeric identifier that is unique for each certificate issued by the CA

CA Signature Algorithm

The name of the hashing and asymmetric algorithms used by the CA to sign the contents of a digital certificate

Issuer Name

Name of issuing CA. Typically, the name of the issuer is represented in either X.500 or distinguished name (DN) format

Validity Period

Shows the valid date range for the certificate. The validity period is split into two fields: Valid From and Valid To

Page 82 of 229

Essential Communication Security Skills for Polycom Solutions

Subject Name

The name of the entity (i.e. computer, user, network device or service) which is represented by the certificate. The subject name is typically represented in an X.500 or distinguished name format

Subject Public Key

Public key of entity which owns the digital certificate. The field also includes an algorithm identifier for the public key

Signature Value

Digital signature of CA

Keypairs Asymmetric keypairs can be generated by a variety of cryptographic applications. For example, the OpenSSL tool provides the capability to generate key pairs with a selection of algorithms and key lengths.

In the figure above, the OpenSSL tool is used to generate a 1024-bit RSA keypair in a file called keypair.pem.

Page 83 of 229

Essential Communication Security Skills for Polycom Solutions

In the figure above, the OpenSSL tool is used to examine the contents of the keypair.pem file. The output shows a modulus (n), the public exponent (e) and the private exponent (d).

Note: A public key consists of the modulus (n) and the public exponent (e), whilst the private key comprises the modulus (n) and the private exponent (d).

Key Length and Validity Period There are recommendations which should be considered when deciding on a key size and validity period for a digital certificate. The table below provides recommendations based on research by RSA Labs in which they estimate the period an attacker would take to compromise a certificate using a sophisticated brute-force attack. When completing the labs you may notice that these recommendations may not be followed when using the default values.

Key length 1024-bits 2048-bits 4096-bits

Validity period not greater than 6-12 months not greater than 2 years not greater than 16 years

It can be seen from the table that there is a clear relationship between key length and recommended validity period (i.e. the valid period of a key should be reduced as the key size is reduced).

Whilst the shorter validity periods have the disadvantage of increased maintenance (i.e. more frequent renewals), they have the advantage of more regular re-authentication of owner and also improved performance when the keys are used because of the reduced resource requirement.

Other factors which should also be considered when deciding on the optimal balance of key size to validity period include; some applications may have a maximum supported key size and, a CA cannot issue a certificate with a validity period longer than the amount of time left on its own certificate.

Page 84 of 229

Essential Communication Security Skills for Polycom Solutions

PKI Standards and Protocols

X.509 Standard The content and format of digital certificates are based on the International Telecommunications Union (ITU) X.509 standard. The standard has been through several revisions and although a version 4 has been released, it is the version 3 certificates which are in common use. The same format is also used by certificate revocation lists (CRLs) which are discussed later.

Public Key Cryptography Standards (PKCS) The PKCS specifications were produced by RSA Laboratories in co-operation with software developers around the world. They are intended to assist in the deployment of public key cryptography. Many of the concepts from these documents have been incorporated into both formal and de-facto standards including S/MIME and SSL. Some of the key PKCS documents are listed below: PKCS PKCS #1 PKCS #3 PKCS #7 PKCS #8 PKCS#10 PKCS #12

Description RSA Cryptography Standard Diffie-Hellman Key Agreement Standard Cryptographic Message Syntax Standard (used to sign and/or encrypt messages under a PKI) Private-Key Information Syntax Standard Certification Request Standard (format of messages sent to a Certification Authority to request certification of a public key) Personal Information Exchange Syntax Standard (a file format commonly used to store private keys with accompanying public key certificates, protected with a password-based symmetric key)

Page 85 of 229

Essential Communication Security Skills for Polycom Solutions

X.509 Certificate Filename Extensions and Encodings A number of different encodings are used for storing digital certificates and other PKI information. The table below shows the most common formats and includes the usual filename extensions: Format/Extension Privacy Enhanced Mail (.pem)

Description Base64 encoded certificate, enclosed between "----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----"

Distinguished Encoding Rules (.der)

Binary encoded certificate. The extensions .cer and .crt are also common for this format Most common format for CSRs is the PKCS#10 specification.

Note: Polycom servers are able to generate certificate requests and the file they generate uses this format.

Certificate Signing Request (.csr)

Cryptographic Message (.p7b or .p7c)

The PKCS#7 standard describes a general format to distribute any data that may have cryptography applied to it. The format is general enough to support many different types of object including; digital signatures, digital envelopes, certificate(s) and CRL(s).

Page 86 of 229

Essential Communication Security Skills for Polycom Solutions

Personal Information Exchange (.p12)

Personal File Exchange (.pfx)

This file format is based on the PKCS#12 specification. The binary file is typically used to store a digital certificate with an accompanying private key in an password-protected form (i.e. encrypted with a symmetric key) The PFX format was a predecessor to PKCS#12.

These days a file with the PFX extension usually contains data in the PKCS#12 format.

Page 87 of 229

Essential Communication Security Skills for Polycom Solutions

X.509 Overview

Version 1 The digital certificate attributes described so far cover only those used in X.509 version 1 (see figure below):

Page 88 of 229

Essential Communication Security Skills for Polycom Solutions

Version 2 This version improved on its predecessor by including additional attributes to assist with certificate renewal and issuer name conflicts. For example, the Issuer Unique ID attribute was introduced to provide a unique identifier which allowed CAs with the same name to be distinguished. However, there was very limited uptake of this version and it is the version 3 certificates which are currently the most common.

Version 3 The X.509 version 3 format improves on its predecessor by allowing the inclusion of certificate extensions which address a number of certificate-validation issues.

Note: An example certificate validation is when a browser is used to navigate to a secure web site using HTTPS. A certificate that fails the validation process will result in a warning that there is a problem with the website’s security certificate.

Page 89 of 229

Essential Communication Security Skills for Polycom Solutions

Certificate Extensions Each extension in an X.509 version 3 certificate consists of three parts: Element Identifier Criticality Flag Value

Description An object identifier (OID) that defines the extension including format.

The flag indicates whether the information in the extension is critical The value assigned to the extension

Criticality Flag Any application (such as a browser) processing a certificate must reject the certificate when it encounters an extension, flagged as critical, which either it does not recognize or that it cannot process (e.g. no value is set). However, if the criticality flag is not set, then the application may ignore the extension if it is not recognized, although it must be processed if it is recognized.

Page 90 of 229

Essential Communication Security Skills for Polycom Solutions

Standard Extensions The following is a list of the most common X.509 Standard Extensions:

Key Usage

This extension specifies the security services for which a certificate can be used. The services can be used in any combination and include the following: Service Digital Signature Non-Repudiation Key Encipherment Data Encipherment Key Agreement Encipher Only

Decipher Only

Key Cert Sign CRL Sign

Description The public key can be used to verify signatures.

The public key can be used to validate the signer’s identity.

The public key can be used for key encryption.

The public key can be used to encrypt data directly.

The public key can be used for key distribution (e.g. symmetric key exchange).

An extension to the Key Agreement service which specifies the distributed key can be used only for data encryption.

An extension to the Key Agreement service which specifies the distributed key can be used only for data decryption.

The public key can be used to verify a certificate’s signature.

The public key can be used to verify a CRL’s signature. CRLs are covered later in this course.

Page 91 of 229

Essential Communication Security Skills for Polycom Solutions

Note: An entity can have multiple certificates with each offering a different combination of security services.

Enhanced/Extended Key Usage

This extension gives a more specific indication of how the public key of a certificate can be used compared with the general purpose options available in the Key Usage extension.

Common examples include:    

Server Authentication Client Authentication Code Signing Secure Email

Each option has an associate Object Identifier (OID); for example, Secure Email has the OID of 1.3.6.1.5.5.7.3.4.

This extension is also known as the Application Policy since an application can make the presence of a particular Enhanced Key Usage, which is specific to the function of the application, mandatory.

Page 92 of 229

Essential Communication Security Skills for Polycom Solutions

Subject Alternative Name (SAN)

This extension allows for a list of names to be specified which can be used as alternatives for the subject name on the certificate.

A digital certificate typically only secures one primary service name (e.g. smtp.medeatalk.com). The use of a SAN extension allows additional service names to be added (i.e. 25 or more) on the same certificate (e.g. imap.medeatalk.com and pop.medeatalk.com). This means that a single certificate can support multiple services on one or more hosts. It provides user-friendly names and offers more security compared to a wildcard certificate (discussed later in this course).

Whilst the subject name on a certificate must use an X.500 distinguished name format, SANs allow for a variety of other representations including the following:    

User Principal Name (UPN) E-mail address IP address Fully qualified domain name

Page 93 of 229

Essential Communication Security Skills for Polycom Solutions

Basic Constraints

This extension allows a certificate to be designated as issued to a CA or an End Entity (e.g. user, computer, or service). It also includes a Path Length constraint which limits how many subordinate CAs can exist in the certificate chain between the root CA and the issuing CA. (Subordinate CAs and certificate chains are covered later in the course.)

CRL Distribution Points (CDP) This extension contains one or more URLs indicating where the certificate revocation list (CRL) of the issuing CA is published. If an application needs to check the revocation status of a certificate, it will use the URL to retrieve the latest version of the CRL. The URLs can use a variety of protocols including: Hypertext Transfer Protocol (HTTP), LDAP and File.

Authority Information Access (AIA) This extension contains one or more URLs indicating where the certificate of the issuing CA is published. If an application needs a copy of the CA certificate (i.e. building a certificate chain), it can use the URL to retrieve the CA certificate if it does not have a local copy. The URLs can use a variety of protocols including; Hypertext Transfer Protocol (HTTP), LDAP and File.

Authority Key Identifier This extension provides a mechanism for identifying the public key corresponding to the private key used to sign a certificate. The extension is utilized where an issuer has multiple signing keys (i.e. they have multiple concurrent keypairs or are in the process of a changeover). This extension can contain one of two values:  

the subject and serial number of the CA certificate that issued the certificate a hash of the public key of the CA certificate that issued the certificate

Page 94 of 229

Essential Communication Security Skills for Polycom Solutions

This extension is used to facilitate certification path (i.e. trust chain) construction and it should be included in certificates generated by all CAs with the exception of self-signed certificates (i.e. root CAs)

Subject Key Identifier The extension provides a means of identifying certificates that contain a particular public key.

It is used to facilitate certification path (i.e. trust chain) construction and it should appear in certificates generated by all CAs. The extension contains a hash of the certificate’s public key.

Special Certificate Types

There are some special forms of digital certificate which are sometimes implemented:

Wildcard A Wildcard certificate is a digital certificate that is applied to a domain or subdomain rather than a single entity.

The wildcard notation uses an asterisk in front of the domain name instead of a hostname (see figure below):

Page 95 of 229

Essential Communication Security Skills for Polycom Solutions

The figure shows an Issued To attribute of *.medeatalk.com. This wildcard certificate will allow secure connections to multiple hosts or services including; www.medeatalk.com, mail.medeatalk.com and pop.medeatalk.com.

The advantages of wildcard certificates are that it is cheaper to purchase a single certificate rather than multiple certificates. Also, the use of a single certificate means less and easier administration.

The main disadvantages of wildcard certificates are as follows: 





Less secure - if the certificate/private key is compromised on a host or service then it is compromised on all the other hosts/services which share the certificate. The certificate will need to be revoked and a new certificate installed on all the hosts/services.

Generally, wildcard certificates only support matching on a single level of domain since the name on the certificate must exactly match the name of the host or service.

For example, the *.medeatalk.com wildcard certificate will not allow secure connections to be established with medeatalk.com (i.e. no host name) or mail.emea.medeatalk.com (i.e. subdomains of the domain).

Wildcard certificates may be incompatible or not supported by certain applications.

For example, Microsoft Lync Server does not accept wildcards and some mobile devices cannot accept wildcard certificates.

Page 96 of 229

Essential Communication Security Skills for Polycom Solutions

Self-Signed A Self-Signed certificate is one certificate in which the Issuer Name and Subject Name attributes contain the same value (i.e. a certificate that is certified by the same entity whose identity it certifies).

There are two common situations in which self-signed certificates are used:

Root CAs A top-level CA cannot be certified by an organisation above it in the certification hierarchy since there is no such body, as a consequence, a certificate for a Root CA must be selfsigned. The figure below shows an example of a self-signed root certificate:

Out-of-the-Box Application Deployments Many server applications (e.g. Apache and IIS Web Servers and Polycom’s Resource Manager and DMA) which provide access with secure connections will provide a mechanism (i.e. either automatic or manual) for generating a certificate. Since there is no CA involvement in this process, the certificates generated must be self-signed (see figure below):

Page 97 of 229

Essential Communication Security Skills for Polycom Solutions

These self-signed certificates can be used in most situations in which a signed certificate could be used. The key advantages are that they are free, readily obtained and ideal for testing the service before considering the purchase of a CA-signed certificate.

In most circumstances, it will be necessary to add the certificate to the Trust Root Certification Authorities store of the client in order that a secure connection can be established successfully. This process should be undertaken with caution since the authenticity of the certificate will not be verified by a CA. Therefore, the identity checking procedure must be undertaken by the user before they add the certificate to the Trusted Root store (see figure below):

Page 98 of 229

Essential Communication Security Skills for Polycom Solutions

Page 99 of 229

Essential Communication Security Skills for Polycom Solutions

Certification Authorities

Along with digital certificates, the Certification Authority (CA) is the other essential component of the PKI. In cryptography the major function of the CA is to issue digital certificates. The digital certificate certifies the ownership of a public key by the named subject of the certificate. The Certification Authority may be a neutral & trusted third-party organisation or may be deployed by organisation within their enterprise network. It provides the following facilities:   

Authentication of Requestors Issuing Certificates Revoking Certificates

Page 100 of 229

Essential Communication Security Skills for Polycom Solutions

Authenticate Requestors The CA must validate the identity of the requestor before it can issue a certificate. Identity validation can be based on a number of mechanisms including official documents which accompany the request (i.e. a passport, WHOIS record, certificate of incorporation) or faceto-face interviews. The CA must also ensure that the requestor has the necessary permissions to ask for a specific type of certificate.

The specific PKI role that performs this identity checking is called the Registration Authority (RA).

Issue Certificates Once identity is confirmed, the CA issues the requested type of certificate (e.g. user and computer) to the requestor. The type of certificate requested determines the content of the issued certificate; for example, an enhanced usage attribute of Server Authentication would be issued for a web server.

Revoke Certificates The CA manages certificate revocation (i.e. cancelling a certificate before it reaches the end of its valid period). The CA is responsible for publishing a Certificate Revocation List (CRL) at regularly scheduled intervals. The CRL contains a list of serial numbers of certificates that are revoked and the reason codes for each revocation (e.g. key compromise).

Other Services Another service often provided by a CA is a Certificate Server. These servers (also known as Directory or Key Servers) use the Lightweight Directory Access Protocol (LDAP) to provide organizations and users with the ability to submit and retrieve digital certificates. In addition, these certificate servers typically offer facilities to assist the business in the administration of their certificates.

Page 101 of 229

Essential Communication Security Skills for Polycom Solutions

Hierarchical Trust Model It is common practise to organise CAs in a hierarchy with a Root CA at the top and Subordinate CAs below. The Root CAs role is typically restricted to managing certificates issued to the subordinates and other requests are directed to a subordinate. The CAs have a clearly defined parent-child relationship and a typical example of a hierarchy which consists of a single root CA and several other subordinate CAs is show in the figure below.

CA Hierarchy

There are several advantages to organizing the CAs in to a hierarchy:  

security scalability and delegation

Security The root CAs are the most trusted CAs in the PKI and they hold the certificates from which trust for the whole hierarchy extends. As long as the Root CA is trusted then all certificates issued within its hierarchy may also be trusted (i.e. a transient trust relationship). As a consequence, the root CAs should receive the very highest level of protection and in particular the private key of the CA must remain secure. If the CA’s private key were compromised then not only would the CA’s certificate have to be revoked but every certificate issued by the CA would then also be considered revoked.

It is common to increase security in the CA hierarchy by taking non-issuing CAs (i.e. root CAs) off-line. If root CAs are disconnected from the network then they are completely protected from any form of network-sourced attacks.

Page 102 of 229

Essential Communication Security Skills for Polycom Solutions

Scalability and Delegation To improve scalability, reduce costs and ease administration a CA may delegate some functions to subordinate CAs. Also, it is common within an organisation to delegate the administration of certificates to the appropriate business unit or division.

Roles in the Hierarchy There are several key roles in the hierarchy:

Root CAs The CA at the top of the hierarchy is called a Root CA or Meta-Introducer. As stated above, they hold the root certificates from which trust for the hierarchy extends. Root CAs are selfcertified by using a self-signed CA certificate (i.e. they issue themselves a certificate in which the Issuer Name and Subject Name fields contain same value).

Subordinate CAs A Subordinate or Child CA is issued a certificate (i.e. certified) by the parent CAs. A subordinate CA can perform one of the following roles:  

Intermediate CA Issuing CA

Intermediate CA An Intermediate CA is a CA that is both subordinate to one CA and only issues certificates to other CAs in the certification hierarchy. The intermediate CA can exist at any level in the CA hierarchy except at the root CA level.

Issuing CA Higher level CAs may certify certificates themselves or they may delegate this task to another CA known as an Issuing CA or Trusted-Introducer. These CAs are typically located on the bottom tier of a certification hierarchy; however, they can also exist at higher levels.

Since an Issuing CA is trusted by the root CA, it can issue and revoke the certificates of entities such as users, computers, and network services. The validity of a certificate can always be tracked back along the trusted path to the Root CA.

Certification Path A certification hierarchy forms a trust chain or certification path. The trust chain shows the path which tracks the validity of a certificate back to the root CA. The figure below shows an example of a three-level certification path:

Page 103 of 229

Essential Communication Security Skills for Polycom Solutions

Path Length There is no restriction with regard to the number of levels in the certification hierarchy (i.e. the depth). However, for many organizations, a three-level certification hierarchy (root CA, intermediate CA and issuing CA) meet the typical requirements.

Some applications allow the maximum path length to be specified (e.g. Apache Web Server has the SSLVerifyDepth parameter which determines how deeply to verify the certificate chain before stopping the process and judging the certificate to be invalid.

Page 104 of 229

Essential Communication Security Skills for Polycom Solutions

Lab Figure

Page 105 of 229

Essential Communication Security Skills for Polycom Solutions

Lab 6.1: Examine Digital Certificates Objective In this lab, you will examine a number of sample digital certificates. For each certificate you will be asked to answer questions on various attributes and record values shown for them.

Note: A copy of this Lab is included in the student workbook which can be printed for use during the exercise.

Steps 1. On Entry machine, restore the CLI01 – Remote Desktop Connection 2. Click Start, select Run… in an Open text box 3. Enter the following path: \\entry\software 4. Click the OK button 5. In the software share dialog, double-click the sample1.cer file 6. At the Open File – Security Warning dialog, click the Open button 7. When the certificate is displayed, click on the Details tab 8. Review the attributes of the certificate and complete the blank spaces and questions shown in the table below: Attribute/Field Version

Value

Question What is the name of the Digital Certificate Standard? __________________________

Serial Number Signature Algorithm Issuer Valid From Valid To

Why it is recommended that this certificate should have validity period of no more than one year? ____________________________________________________

Subject

CN=____________

The subject is shown in what naming format? _______________________________________

Public Key Size

______Bits

What other key sizes are commonly used for RSA cryptography? __________________________________

Page 106 of 229

Essential Communication Security Skills for Polycom Solutions

Enhanced Key Usage CRL Distribution Point Key Usage Basic Constraints

Name another common example of enhanced key usage? ____________________________________ URL=

Subject Type=______

9. Click OK to close the Certificate dialog 10. In the software share dialog, double-click the sample2.cer file and when prompted click Open – after ~30s the Certificate will open 11. When the certificate is displayed, click on the Details tab 12. Review the attributes of the certificate and complete the blank spaces and questions shown in the table below:

Attribute/Field Issuer Subject

Value

Question

What is the term for a certificate issued by the subject? __________________________

Enhanced Key Usage Public Key Length Valid From Valid To

What is the validity period and does it meet recommendations? __________________________

Key Usage

13. Click OK to close the Certificate dialog 14. In the software share dialog, double-click the sample3.cer file and when prompted click Open – after ~30s the Certificate will open 15. When the certificate is displayed, click on the Details tab

Page 107 of 229

Essential Communication Security Skills for Polycom Solutions

16. Review the attributes of the certificate and complete the blank spaces and questions shown in the table below:

Attribute/Field Issuer

Value

Subject

Basic Constraints

Question

What is the term for a certificate issued by the subject? __________________________ Subject Type=_______

Valid From Valid To

What is the validity period and why is it so long? __________________________

Public Key Length

What recommendation would you make regarding the length of this key? _________________________________________

Key Usage

17. Click OK to close the Certificate dialog 18. In the software share dialog, double-click the sample4.cer file and when prompted click Open – after ~30s the Certificate will open 19. When the certificate is displayed, click on the Details tab 20. Review the attributes of the certificate and complete the blank spaces and questions shown in the table below:

Attribute/Field Subject

Value CN=_____________

Question What is the term for a certificate issued with this form of subject? __________________________

21. Click OK to close the Certificate dialog 22. In the software share dialog, double-click the sample5.cer file and when prompted click Open – after ~30s the Certificate will open 23. When the certificate is displayed, click on the Details tab

Page 108 of 229

Essential Communication Security Skills for Polycom Solutions

24. Review the attributes of the certificate and complete the blank spaces and questions shown in the table below:

Attribute/ Field Subject

Subject Alternati ve Name (SAN)

Value

Question

CN=_______ ______

What is the advantage of a certificate which includes the SAN attribute?

____________________________________________________ _____________________________

25. Click OK to close the Certificate dialog 26. Close the software share dialog 27. Minimize the CLI01 – Remote Desktop Connection for use in later labs

Page 109 of 229

Essential Communication Security Skills for Polycom Solutions

Lab 7.1: Install Standalone CA Objective In this lab, you will install a standalone root CA using the role provided in Windows Server 2008 R2. This CA will subsequently be used as the signing CA for certificates generated in this environment.

Note: A Windows Server Standalone CA does not use Active Directory Domain Services (AD DS). They can be used as offline trusted root CAs in a CA hierarchy or to issue certificates to clients. When users submit a certificate request to a standalone CA, they must provide their identifying information and specify the type of certificate they need. Windows Server also supports Enterprise CAs which link to AD DS and can use certificate templates to automate issuance.

Steps 1. On the Entry desktop, double-click the LON-SRV01 shortcut 2. Log on using a LON-SRV01 credential as specified in the Delegate Information Sheet 3. On LON-SRV01, click Start, Administrative Tools, Server Manager 4. In the left-hand pane, highlight the Roles entry 5. In the right-hand pane, click the Add Roles link 6. When the Add Roles Wizard launches, click Next 7. In the Select Server Roles dialog, tick the Active Directory Certificate Services entry and click the Next button 8. At the Introduction to Active Directory Certificate Services dialog, click Next 9. When the Select Roles Services dialog appears, keep the default selection of Certification Authority and also tick the Certificate Authority Web Enrolment entry Note: The CA Web Enrolment service provides a web interface to provide access to certificates and CRLs. 10. When prompted, click the Add Required Role Services button 11. Click Next 12. In the Specify Setup Type dialog, verify that Standalone is selected and click Next Note: The Enterprise entry has been greyed out since the LON-SRV01 machine is not a member of an Active Directory Domain 13. In the Specify CA Type dialog, verify that the Root CA option is selected and click Next 14. When the Set Up Private Key is displayed, verify that the Create a new private key option is selected and click Next

Page 110 of 229

Essential Communication Security Skills for Polycom Solutions

15. When the Configure Cryptography for CA dialog is presented, keep the default settings 16. Record the specified Key length ____ and hash algorithm _____ and click Next 17. When the Configure CA Name dialog is presented, keep the default Common Name 18. Record the associated distinguished name (DN) and click Next CN=_____________________ 19. When the Set Validity Period dialog is displayed, record the default period in the space below and click Next _____Years 20. When the Configure Certificate Database dialog appears, keep the default certificate database locations and click Next 21. The web server (IIS) dialog is now displayed, click Next 22. In the Select Roles Services dialog, keep the default Web services settings and click Next When the Confirm Installation Selection dialog appears, verify that Active Directory Certificate Services, Web Server (IIS) and Remote Server Administration Tools are listed and click the Install button Note: You can continue to the next section while the installation completes.

23. When installation completes, the installation results dialog should indicate that the AD Certificate Services Installation Succeeded, the Web Server (IIS) Installation Succeeded and the Remote Server Administration Tools Installation succeeded. Click the Close button Note: Ignore the Warning message regarding the Windows Automatic Updating shown in Server Manager 24. Close the Server Manager dialog window.

25. Minimize the connection to LON-SRV01 for use in later labs

Page 111 of 229

Essential Communication Security Skills for Polycom Solutions

Certificate Stores

Operating systems and many applications such as Polycom’s Resource Manager and DMA servers store digital certificates on the computer or device in a storage location called the certificate store. A certificate store will typically organize the numerous certificates into function-based sub-containers or files. For example, the Microsoft Windows operating system has certificate store sub-containers which include the following:    

Personal Trusted Root Certification Authorities Intermediate Certification Authorities Untrusted Certificates

Page 112 of 229

Essential Communication Security Skills for Polycom Solutions

Personal

Holds certificates that are associated with private keys to which the user or computer has access. Certificates from the personal store may be used for purposes such as client authentication.

Trusted Root Certification Authorities

Holds certificates for Trusted certification Authorities. This includes all of the certificates in the Third-Party Root Certification Authorities store plus root certificates for an organization’s enterprise CAs and those used by Microsoft.

Intermediate Certification Authorities

Holds certificates issued to subordinate certification authorities.

Disallowed Certificates

Holds certificates that the user has explicitly decided not to trust using either Software Restriction policy or by clicking "Do not trust this certificate" in mail or in a Web browser.

Trusted Root Certification Authorities One of the key certificate stores is the Trusted Root Certification Authorities store (see figure below):

A client will only trust a certificate if the certificate can be traced back to a CA in the Trusted Root Certification Authorities container or file using the certification path (i.e. trust chain).

Page 113 of 229

Essential Communication Security Skills for Polycom Solutions

In the figure above, the certification path tab shows the LON-SRV01-CA as the trusted root CA. When an administrator adds a CA certificate to this store on a machine, it means the CA is explicitly trusted (i.e. any certificates signed by this CA are trusted by the machine).

However, in addition, this action means that all other organizations on the certificate trust chain (i.e. sub-ordinate CAs) are implicitly trusted. They are trusted not to sign a certificate without obtaining adequate assurance of an appropriate purpose and of the identity of the requestor.

Bundled Trusted CA Certificates Operating systems and applications typically include a bundled selection of the common public root CA certificates in the Trusted Root CA store by the vendor. This means that nontechnical users can establish secure connections transparently when a certificate signed by one of these CAs or one of their sub-ordinates. For example, most browsers would include a copy of the GTE Cyber Trust Global Root certificate and consequently any certificate issued

by GTE or a sub-ordinate of GTE is automatically trusted.

Note: An administrator or user can add or remove certificates from this store to alter the default trust list.

Microsoft Windows and Linux Certificate Stores In many operating systems (e.g. Linux) and applications (i.e. Apache Web Server) the Trusted Root CA store consists of a single file or directory which contains the certificates of trusted CAs in PEM format (see figure below):

Page 114 of 229

Essential Communication Security Skills for Polycom Solutions

In the Microsoft Windows environment the certificate store (including Trusted Root CA store) can be found in various locations depending on the scope required. The certificate stores are managed using the Certificates snap-in for the Microsoft Management Console (MMC) framework:

When the snap-in is selected three different scopes are offered (see figure below):

Page 115 of 229

Essential Communication Security Skills for Polycom Solutions

The scope options are detailed in the table below: Scope Name My user account Service account Computer account

Description Certificate Store for current user account Certificate Store for specified service account Certificate Store for Local Computer account

Location Registry Registry Local Computer

Note: Certificates stored under the Computer account scope are accessible for all users and services.

Importing Certificates When importing, it is possible to specify the Certificate Store in which the certificate should be placed by selecting the Show physical stores option (see figure below) and then choosing both the Certificate Store and the physical location (e.g. Registry or Local Computer).

Page 116 of 229

Essential Communication Security Skills for Polycom Solutions

Private or Enterprise CA There are two categories of CA:  

Private (Enterprise) Public (Internet)

The table below shows the key differences: CA Type Private Public

Scope of Trust Limited Complete

Description Internal to an organization External third-party organizations e.g. Verisign and GTE

Note: Public CAs must demonstrate the adequacy of their practices and controls before they can be trusted by application vendors.

Typically organizations setup internal CAs in order to gain full control of their Public Key Infrastructure and to reduce the costs associated with external CAs. However, the main disadvantages to such as approach are as follows: 

Limited Trust – the internal CA will not be automatically trusted by any operating system or application unlike a public CA which typically has its certificate included within a Root CA certificate store.

Cost – the cost of maintaining a secure internal CA infrastructure can be substantial when the requirements for special hardware and staff training are considered

A hybrid option is popular and offered by many of the public CAs (e.g. VeriSign’s private label services). This approach combines the local control of an internal CA with the outsourcing benefit of gaining the external CA’s investment in hardware, people and knowledge.

When using a Private CA an administrator must use a push mechanism to install a copy of the enterprise CA certificate into the trusted root CA store for all machines in the business.

For computers that are members of a Microsoft Active Directory Domain this can be achieved using a variety of mechanisms linked to AD Domain membership and the use of Group Policies.

Page 117 of 229

Essential Communication Security Skills for Polycom Solutions

Certificate Trust Chain An earlier topic described the concept of a Hierarchical Chain of Trust for CAs. When requesting a secure connection to a server the key purpose of digital certificates is to establish a Trust Chain for the client. This should confirm the identity of the server and provide assurance that a secure connection can be established. The trust chain must extend from the certificate of the server, via possible intermediate CAs to the Root CA which must be trusted by the client (i.e. in the client’s Trusted Root Certificate Authorities store).

The process of verifying a trust chain is facilitated by the inclusion of the Subject (i.e. Issued To) and Issuer Name (i.e. Issued By) attributes in each certificate.

Note: The Subject Key Identifier (SKI) and Authority Key Identifier (AKI) attributes are used to ensure the certification path (i.e. trust chain) is constructed accurately.

Trust Chain Example When a client (i.e. web browser) attempts a secure connection to a web server hosting the www.medeatalk.com website, it will receive a copy of the website certificate (see figure below):

The figure shows that the certificate was issued to www.medeatalk.com and issued by NYC-SRV01-CA. Note: An endpoint or sub-ordinate CA will show different names in the Issued To and Issued By attributes which provides the client with a next step to continue checking, if necessary, in order to establish trust.

Page 118 of 229

Essential Communication Security Skills for Polycom Solutions

The client will check whether the certificate was issued by a trusted CA. If not, it will check to see if the certificate of the issuing CA was issued by a trusted CA. It will continue performing this process until either a trusted CA is found (i.e. a secure connection can be established) or it determines that no trusted CA can be found (i.e. an error message will be generated and no connection will be established).

The client can obtain a copy of the NYC-SRV01-CA certificate (see below) either from its local certificate store or by downloading a copy using the URL in the Authority Information Access (AIA) attribute of the website certificate:

The figure shows that the certificate was issued to NYC-SRV01-CA and issued by LONSRV01-CA.

Page 119 of 229

Essential Communication Security Skills for Polycom Solutions

The figure shows the URL that can be used to locate the certificate for the LON-SRV01-CA. Note: A Root CA will show the same name in the Issued To and Issued By attributes so no further checking by the client is possible. This is known as a self-signed certificate. At this point the client will be able to determine whether a trust chain can be established by checking whether a copy of the Root CA certificate can be found in its Trusted Root Certification Authorities store.

The figure above shows a copy of the LON-SRV01-CA certificate in the Trusted Root Certification Authorities store of the client and consequently, a secure connection to the server can now be established.

Page 120 of 229

Essential Communication Security Skills for Polycom Solutions

Certificate Chain Validation When the Crypto Library builds and validates a certificate chain all possible certificate chains are built using locally stored certificates. If the certificate chain does not end in a self-signed certificate then the Crypto Library (e.g. CryptoAPI) can attempt to retrieve the certificate of the issuer as specified in the Authority Information Access (AIA) extension in order to complete the chain.

Page 121 of 229

Essential Communication Security Skills for Polycom Solutions

Certificate Signing Requests (CSRs)

An entity wishing to apply for a digital certificate must generate a Certificate Signing Request (CSR) which contains a Distinguished Name (DN) and a copy of the owner’s public key. The message created by the applicant, along with suitable identification, is then sent to a CA for verification and signing. Following verification the CA will return a copy of the digital certificate to the owner. The most common format used for CSRs is the PKCS#10 specification discussed earlier.

Polycom servers support creation of CSRs and the example below shows the information collected by RealPresence Resource Manager when creating a request.

Page 122 of 229

Essential Communication Security Skills for Polycom Solutions

Generate CSR

Generate CSR

1. The applicant must choose the algorithm, key size and distinguished name (DN) information to be used in the CSR. In this example OpenSSL is used to create the request.

In the image above, the applicant has generated a 1024-bit RSA keypair in a file called keypair.pem. The private key is encrypted using the AES algorithm and a 128-bit secret key based on the pass phrase supplied.

Page 123 of 229

Essential Communication Security Skills for Polycom Solutions

In the figure above, the applicant has requested a new CSR with the public key from the keypair generated previously. The Crypto Library requests the applicant to supply information to identifying the applicant for the Distinguished Name (DN) including Country (C), Organization (O) and Common Name (CN) which will be the subject name on the digital certificate.

2. The Crypto Library can generate a keypair and subsequently generate a CSR using the public key from the keypair; alternatively, it can perform both tasks simultaneously.

3. The applicant keeps the private key whilst the CSR is sent to the CA. The CSR may be accompanied by other credentials or proofs of identity as required by the Certificate Authority. If necessary the Certificate Authority may contact the applicant for further information.

Note: The type of identity information required depends on the Certificate Policy of the CA. For example, a basic check may require a user to simply prove ownership of an email address whilst a more rigorous check may involve the user supplying a passport or photo ID.

Page 124 of 229

Essential Communication Security Skills for Polycom Solutions

Signing a CSR

Signing a CSR

1. The CA receives the CSR (*.csr or *.req) and accompanying identity documents. The CA must perform various identity checks to establish the identity of the applicant and also that any requested usage is appropriate 2. If the identity checks prove successful then the CA requests the Crypto Library to generate a digital certificate (i.e. it creates a certificate structure using the X.509 v3 format) 3. The Crypto Library generates a hash of the certificate structure (i.e. the attributes and associated values) 4. The Crypto Library encrypts the newly generated hash with the private key of the CA (i.e. it generates a digital signature) 5. The digital signature is appended to the certificate structure to create a digital certificate.

6. The digital certificate is returned to the applicant

Page 125 of 229

Essential Communication Security Skills for Polycom Solutions

Distinguished Name (DN) A CSR contains information to identify the owner along with a copy of the owner’s public key.

The identity information is entered in the form of an X.500 Distinguished Name (DN).

The figure below shows the DN attributes which are used to generate the Subject attribute on the digital certificate:

Typically the DN information requested for a CSR is as follows: Information E-mail Address

Attribute E

Common Name

CN

Organisational Unit Organisation

OU O

Locality State

L S

Country

C

Description An email address use to contact the organisation.

This is usually the email address of the certificate administrator or IT department.

This is the name of the owner (e.g. John Doe for a user or www.medeatalk.com for a computer).

A department name (e.g. HR, Finance or IT) Usually the legally incorporated name of the business. It should include any appropriate suffixes such as Ltd., Inc. or Corp.

The town or city (e.g. New York).

The State, Province, Region or County (e.g. New Jersey) Note: It should not be abbreviated.

The two-letter ISO code for the country where the organisation is located (e.g. US).

Note: The same fields were included in the RealPresence Resource Manager Certificate Request shown earlier.

Page 126 of 229

Essential Communication Security Skills for Polycom Solutions

Lab 8.1: Configure the Web Server Objective In this lab, you will install a Web Server (IIS) role on the SRV01 machine. In a subsequent lab, you will configure the Web Server to provide secure connections using SSL/TLS.

Steps 1. On the Entry VM, double-click the SRV01 shortcut and log on with the SRV01 credentials from the Delegate Information Sheet 2. On SRV01, click Start, Administrative Tools, Server Manager 3. In the left-hand pane, highlight the Roles entry 4. In the right-hand pane, click the Add Roles link - the Add Roles Wizard now launches 5. At the Before You Begin dialog, click Next 6. At the Select Server Roles dialog, tick the Web Server (IIS) Role and click Next 7. At the Web Server (IIS) dialog, click Next 8. At the Select Role Services dialog, keep the default settings and click Next 9. At the Confirm Installation Selections click the Install button 10. After the installation completes, confirm the Installation Results dialog displays Web Server (IIS) Installation succeeded and click the Close button Note: Ignore the Warning message regarding the Windows Automatic Updating shown in Server Manager 11. Close the Server Manager application

Sub-Task 8.1.1: Configure the Web Server with a Home Page (i.e. default.htm) 1. From the Start menu, select Run‌ 2. In the open text box, insert the following URL: \\entry\software 3. Click the OK button 4. Enter the user credentials for SRV01 from the Delegate Information Sheet 5. When the software share dialog window opens, right-click on the default.htm file and select the Copy option 6. In the left-hand pane, select the Computer entry

Page 127 of 229

Essential Communication Security Skills for Polycom Solutions

7. Navigate to the following location: C:\inetpub\wwwroot 8. Paste the file in to the wwwroot folder 9. Close the wwwroot window

Sub-Task 8.1.2: Verify the Successful Installation of the Home Page 1. On SRV01, click Start, Internet Explorer 2. Enter the following URL: http://localhost 3. Click the Go To button (i.e. horizontal green arrow) 4. If prompted with a message stating Internet Settings are turned off by default, click the Don’t Show This Message again button 5. Verify Internet Explorer shows a message stating Now you see it and now you don’t with a title of Security Essentials in the titlebar 6. Close Internet Explorer

Lab 8.2: Generate a Certificate for the Web Server Objective In this lab, you will generate a Certificate Signing Request (CSR) for the SRV01 web server. The CSR will be transferred to the CA service installed on LON-SRV01 in order to generate a signed certificate for the SRV01 web server from this request.

Steps 1. Click Start, Administrative Tools, Internet Information Services (IIS) Manager 2. When the IIS Manager opens, in the left-hand pane, highlight the entry for SRV01 (SRV01\Administrator) 3. In the middle pane, scroll-down and double-click the Server Certificates entry in the IIS section 4. In the right hand pane, Actions section, click the Create Certificate Request… link – the Request Certificate Wizard will now launch

Page 128 of 229

Essential Communication Security Skills for Polycom Solutions

5. In the Distinguished Name Properties dialog enter the following information:

Parameter Common Name Organization Organizational unit City/locality State/province Country/region

Value www.medeatalk.com MedeaTalk Corp Training Dallas Texas US

6. Click the Next button 7. In the Cryptographic Service Provider Properties, keep the default settings and record the Bit length here: ______ 8. Click Next 9. In the File Name dialog, specify a file name for the certificate request along with a location of the following: \\entry\software\srv01.req 10. Click the Finish button Note: It can take approximately 60 seconds for the dialog to close.

11. Leave the IIS Manager dialog open for a later exercise 12. Minimize the window containing SRV01

Page 129 of 229

Essential Communication Security Skills for Polycom Solutions

Lab 8.3: Signing of the Certificate Signing Request by the CA Objective In this lab, you will use the Root CA Management Utilities on LON-SRV01-CA to sign the web server certificate signing request (CSR) generated for SRV01.

Steps 1. Restore the window containing LON-SRV01 2. Click Start, Administrative Tools, Certification Authority 3. In the left-hand pane, right-click on LON-SRV01-CA and from the All Tasks menu, select Submit new request… option 4. In the File Name text box, enter the following path: \\entry\software\srv01.req 5. Click the Open button 6. In the left-hand pane, expand LON-SRV01-CA and select the Pending Requests container 7. In the right-hand pane, right-click on the new request (i.e. ID=2), from the All Tasks Menu, left-click Issue Note: When the administrator chooses to Issue (i.e. sign) a CSR. The requested is removed from the Pending Requests container and, if successful, a signed certificate is placed in the Issued Certificate container.

8. In the left hand pane, choose the Issued Certificates container 9. Double-click on the new certificate (i.e. ID=2) in the right-hand pane 10. Select the Details tab, verify the following properties are correct:

Field Issuer Valid From Subject Public Key Enhanced Key Usage

Value LON-SRV01-CA [current date and time] www.medeatalk.com, Training…

RSA (1024 bits) Server Authentication (1.3.6….

11. Click the Copy To File… button at the bottom of the Certificate dialog 12. When the Certificate Export Wizard launches, click the Next button

Page 130 of 229

Essential Communication Security Skills for Polycom Solutions

13. In the Export File Format dialog, choose Base-64 encoded X.509 (.CER) and click the Next button 14. In the File to Export dialog, specify a file name of: \\entry\software\srv01.cer 15. Click Next 16. At the Completing Certificate Export dialog, verify the File Name and File Formats are correct and click the Finish button 17. Click OK to acknowledge a successful export 18. Click OK to close the Certificate dialog 19. Close the Certification Authority interface by selecting Exit from the File menu 20. Minimize the window containing LON-SRV01

Page 131 of 229

Essential Communication Security Skills for Polycom Solutions

Lab 8.4: Install and Configure Web Server Certificate Objective In this lab you will install the signed certificate on to the SRV01 Web Server and verify a secure connection can be established from a web browser.

Steps 1. Restore the window containing SRV01 2. In the IIS Manager dialog, Actions section in the right-hand pane, choose Complete Certificate Request‌ 3. When the Specify Certificate Authority Response dialog is displayed, enter a File Name of: \\entry\software\srv01.cer 4. In the Friendly name text box, enter the following: SRV01 Web Server Certificate 5. Click the OK button – after a minute the dialog will disappear 6. In the Server Certificates section (i.e. middle pane) of the IIS Manager, double-click the SRV01 Web Server Certificate entry 7. Record the message displayed in the Certificate Information Section? _______________________________________________________________________ _________________________________________________________________ 8. Why is this error message displayed and what should be done to rectify the issue? _______________________________________________________________________ _________________________________________________________________ 9. Click the OK button to close the Certificate dialog

Sub-Task 8.4.1: Download a copy of the CA Certificate to the SRV01 Web Server 1. On SRV01, click Start, Internet Explorer 2. In the browser, specify the following URL: http://lon-srv01.medeatalk.com/certsrv 3. Click the Go To button (i.e. horizontal green arrow) 4. When the website opens, choose the Download a CA certificate, certificate chain, or CRL link

Page 132 of 229

Essential Communication Security Skills for Polycom Solutions

5. If prompted, click the cross to close any message regarding Internet Explorer blocked ActiveX control 6. In the Download a CA Certificate dialog, choose the Encoding Method :Base 64 and click the Download CA certificate link. The certificate may take a minute to be downloaded.

7. When prompted to save or open certnew.cer, click the drop-down arrow next to the Save button and choose the Save As option 8. When the Save As dialog is displayed, enter the following File Name: \\entry\software\lon-srv01-ca.cer 9. Click the Save button 10. When a message stating The lon-srv01-ca.cer download has completed, click the Open button 11. Record the message displayed in the Certificate Information Section _______________________________________________________________________ _______________________________________________________________________ ______________________________________________________________ 12. Select the General tab 13. Click the Install Certificate‌ button 14. When the Certificate Import Wizard is launched, click Next 15. When the Certificate Store dialog is displayed, choose the Place All Certificate in the following store option 16. Click the Browse‌ button 17. Select the Show physical stores option Note: The Physical Stores are the various locations in which the Certificate can be stored (e.g. Registry, Local Computer, Group Policy, Smart Card) 18. Expand the entry for Trusted Root Certification Authorities and choose the Local Computer entry 19. Click OK 20. Click the Next button 21. At the Completing Certificate import dialog, click the Finish button 22. After a ~30 second period, click OK to acknowledge successful import 23. Click the OK button to close the Certificate dialog

Page 133 of 229

Essential Communication Security Skills for Polycom Solutions

24. Close Internet Explorer 25. In the IIS Manager, double-click on the SRV01 Web Server Certificate entry 26. Record the Certificate information now displayed: ____________________________________________________________________ 27. Click the OK button to close the Certificate dialog

Sub-Task 4.4.2: Configure the Web Server site to offer HTTPS connections 1. In the left-hand pane, highlight the Sites entry below SRV01 2. In the Sites pane (i.e. middle pane) right-click on the Default Web Site entry and chose the Bindings‌ option 3. Click the Add‌ button and specify the following settings:

Parameter Type IP address Port SSL certificate

Value https All unassigned 443 SRV01 Web Server Certificate

4. Click the OK button 5. Click the Close button 6. In the right-hand pane, under the Manage Website section, click the Restart option 7. Close IIS Manager by selecting Exit from the File menu 8. Minimize the SRV01 connection for use in a later lab

Page 134 of 229

Essential Communication Security Skills for Polycom Solutions

Certificate Revocation and Suspension

In some instances it is necessary for a CA to revoke a certificate before the certificate expires. As described above, one of the key CA tasks is to publish a list of revoked certificates in a Certificate Revocation List (CRL). For each entry in the CRL, the CA includes the serial number of the certificate and an associated code which specifies a reason for the revocation.

Revocation Reasons There are many reason codes for revoking a certificate including the following: Reason Key Compromise

CA Compromise Affiliation Changed Cessation Of Operation Superseded

Description The private key associated with the certificate has been stolen or otherwise acquired by an unauthorized person (e.g. the computer storing the private key is stolen).

The private key of a CA has been compromised (e.g. the device holding the private key is stolen).

The subject of the certificate is no longer affiliated with an organization (e.g. termination of employment of staff member).

The subject of the certificate has been decommissioned (e.g. a domain name change takes place when two companies merge and the existing web server certificates must be replaced).

A new certificate replaces the current certificate.

Page 135 of 229

Essential Communication Security Skills for Polycom Solutions

Suspension It is possible to suspend a certificate; this allows for a temporary revocation of a certificate so that a problem can be investigated. As with revocation, a reason code should be provided to indicate the grounds for suspension.

Determining Certificate Revocation There are several mechanisms which currently can be used by a client (e.g. web browser) to determine whether a certificate has been revoked:  

Certificate Revocation Lists (CRLs) Online Certificate Status Protocol (OCSP)

Certificate Revocation Lists (CRLs) The older and currently the main mechanism for determining the revocation status of a specific certificate is by using CRLs. As discussed briefly above, a CRL contains the serial numbers of all certificates revoked by a CA and includes an associate reason for each revocation. This list is then signed using the private key of the CA to prove integrity and authenticity.

As discussed in the certificates section, the CRL Distribution Point (CDP) is published as an attribute in a digital certificate. The client is responsible for downloading the latest published list from the CA and parsing the entries (i.e. to break down or analyze in to logical components and examine).

Although widely supported, this form of CRL (known as a Base CRL) has some significant issues: 

Latency The main issue with CRLs is that there is latency in identifying when a certificate has been revoked. When a certificate is revoked it is immediately added to the CRL, however, updated CRLs are only published at periodic intervals (e.g. daily) so the revocation will not be recognised until the client downloads the publication.



Large Lists A second issue with the use of CRLs is the downloading of a potentially large list of revoked certificates. Not only does the download place bandwidth demands on the network but also the client has the burden of parsing the list for the specific certificate serial number.

Delta CRL As a response to these issues listed above, the concept of delta CRLs was introduced.

Analogous to an incremental backup, a delta CRL only contains serial numbers and reason codes for certificates revoked since the last Base CRL.

Page 136 of 229

Essential Communication Security Skills for Polycom Solutions

This mechanism helps reduce latency issues by allowing the CA to publish more frequently and, in addition, this process reduces the quantity of data a client must download (i.e. only the incremental changes) to check on revocation status.

Note: In order to perform a revocation check, a client must have a copy of both the delta CRL and the associated base CRL. If the base CRL is not available then the revocation check will fail.

The main issue with Delta CRLs is that not all clients support the mechanism.

Page 137 of 229

Essential Communication Security Skills for Polycom Solutions

CRL Process

The client (e.g. a web browser) downloads from the CA server a copy of the latest CRL (see figure above). The steps involved are as follows: 1. The client first checks for the required CRL in memory and disk-based caches 2. If no valid cached information is available, then the client determines the URL of the CRL by inspecting the CRL Distribution Point (CDP) attribute in the certificate. If a valid URL is present, it will download the CRL using the protocol designated in the URL (e.g. HTTP or LDAP).

3. On receiving the download, the client can verify the signature on the file to ensure integrity and authenticity. It will then parse the CRL for the serial number of the certificate to determine whether it can trust the certificate 4. The CRL will be cached for a specified period

Page 138 of 229

Essential Communication Security Skills for Polycom Solutions

On-line Certificate Status Protocol (OCSP) A more recent method for certificate revocation checking utilises the On-line Certificate Status Protocol (OCSP). This is a simple request-response protocol defined in RFC2560.

This mechanism has significant advantages over using CRLs: 



only information relating to a specified certificate serial number is retrieved which is amount of data in the request and response is a fixed size. The number of certificates actually revoked by the certification authority does not affect the size of the OCSP responder’s response. it should provide more timely information regarding the revocation status of a certificate (i.e. reduce lag)

The most significant issues faced when deploying OCSP are as follows:  

not all client supports OCSP scalability of the OCSP responder with high numbers of requests (i.e. caching still required) and performance penalty from signing of responses

OCSP Process

The OCSP client (e.g. a web browser) queries an OCSP server (known as a Responder) for the status of the certificate (see figure above). The steps involved are as follows: 1. The client first checks for the required CRL in memory and disk-based caches 2. If no valid cached information is available, then the client determines the URL of the OCSP Responder by inspecting the Authority Information Access (AIA) attribute in the certificate. If a valid OCSP URL is present, it will send an HTTP certificate status request containing the serial number of the certificate to the Responder. Clients are capable of using either the HTTP GET or POST methods

Page 139 of 229

Essential Communication Security Skills for Polycom Solutions

3. On receiving the request, the Responder must communicate with the issuer of the certificate (i.e. CA). It can query the CA’s database to perform a real-time check on the status of the certificate using its serial number.

Note: In some implementations the Responder uses the CRLs published by the CA to determine the revocation status 4. The Responder then generates an OCSP response (i.e. good or revoked) which it digitally signs and passes to the client 5. The client can verify the signature on the response to ensure integrity and authenticity.

If the response was successful, then the client can now trust the certificate.

Caching Both CRL and OCSP-based mechanisms utilize caching to improve performance reasons and reduce network traffic. The client can cache CRLs and OCSP responses.

When a client performs a check on the revocation status of a certificate, it initially looks for the required CRL (i.e. base or delta) or OCSP response in its memory and disk caches. If the CRL or OCSP response is found, then the client determines if it is still valid in which case it will be used for the revocation checking. Both CRLs and responses have an associated validity period in the case of CRLs this is typically based on the publication interval of the CA. If no valid cached source exists then the client will use the mechanisms described above to obtain the required information.

Note: Cached CRLs can lead to situations where clients are still able to navigate to web sites after a certificate has been revoked.

Page 140 of 229

Essential Communication Security Skills for Polycom Solutions

Expiration, renewal and destruction Most End Entity certificates are valid for between 1 and 3 years. When a certificate approaches expiry there are two possible options:  

Renewal - a new certificate with the same subject, public key and usage as the previous version Update - a new certificate with either a different public key and/or a different usage

Note: In both cases the new certificate has a different serial number.

The CA is recommended to contact the owner or administrator (i.e. using the email address specified in the DN) of the certificate 30 days before expiry.

In the case of a renewal it is possible to generate a new CSR from the existing certificate, however, the recommended best practice is to generate a new keypair since the longer a keypair has been active, the greater the likelihood of key compromise.

Note: A Certificates Rollover allows a new certificate to be issued before the old one has expired.

Destruction If a keypair has been compromised or has become invalid, it should be destroyed to prevent misuse. The destruction focuses on eliminating the private key because the public key may be stored in multiple locations and consequently it will be difficult to destroy all copies.

If the key is stored on magnetic media then it can be deleted, however care must be taken to ensure that it cannot be recovered. A special procedure should be used to ensure the stored key is overwritten with random data. An alternative destruction mechanism could involve destroying the storage media (e.g. hard disk, usb key, smart card or CD).

Important: If archived data has been encrypted using the old public key then it will be necessary to export the keypair to a Certificate History. This must be maintained to allow access to data encrypted using the old keys.

Page 141 of 229

Essential Communication Security Skills for Polycom Solutions

Certificate Validation

Before a secure connection can be established it is important to validate the certificate to verify that it has integrity, authenticity and has not been revoked. There are three steps which must be performed to validate a certificate:   

Verify Certificate Integrity Check Certificate Attributes Check Certificate Revocation Status

Page 142 of 229

Essential Communication Security Skills for Polycom Solutions

Verify Digital Certificate Integrity

Figure 1: Check the Integrity of a Digital Certificate

The figure above shows the procedure for checking the integrity of a digital certificate. Each step is described below: 1. Upon receipt of a digital certificate the endpoint must perform a check on the certificate to ensure integrity. The endpoint reads key certificate attribute values:  Issuer Name  CA Signature Algorithm - Signature Algorithm and Signature Hash Algorithm  Signature Value 2. The endpoint requests the Crypto Library to perform a hash of all the certificate attributes excluding the digital signature (i.e. Signature Value) using the Signature Hash Algorithm.

This generates the first hash (i.e. Message Digest 1) which is returned to the endpoint.

3. The endpoint requests the Crypto Library to decrypt the signature value of the digital certificate using the public key of the Issuer (i.e. Signature Algorithm and Issuer Name).

The Crypto Library searches the Trusted Certificate Store for the appropriate digital certificate (e.g. RSA) of the issuer. If the certificate can be found in the store then the public key is extracted and used to decrypt the digital signature and generate the second hash (i.e. Message Digest 2) which is returned to the endpoint.

Page 143 of 229

Essential Communication Security Skills for Polycom Solutions

Note: If the digital certificate of the Issuer cannot be found in the Trusted Certificate Store then the digital certificate of the other endpoint cannot be validated and consequently a secure connection should not be established. The image below shows an example of a browser error displayed when the CA certificate is not available.

4. The endpoint requests the Crypto Library to compare the two message digests and determine whether there is a match. As the figure above indicates, if the hashes match then the public key and other certificate attributes can be verified as authentic (i.e. the integrity of the certificate is established) otherwise there is an issue with the certificate (e.g. attributes have been altered).

Page 144 of 229

Essential Communication Security Skills for Polycom Solutions

Check Digital Certificate Attributes Once the integrity of a digital certificate has been established, the endpoint must perform additional checks on the certificate attributes: The endpoint reads key certificate attribute values:   

Subject Name Validity Period – Valid From and Valid To Enhanced Key Usage

Subject Name The first check performed verifies that the host name (i.e. Subject Name) on the certificate matches the name used to establish the connection.

For example, if a browser was used to connect to the following URL: https://www.medeatalk.com then the endpoint would expect the Subject Name on the certificate to be www.medeatalk.com. If the names do not match then a secure connection should not be established and an appropriate error message should be generated (see image below); for example: The security certificate presented by this website was issued with a different website’s address.

If the digital certificate contained a Subject Alternative Name (SAN) attribute then a match with one of the entries would be considered valid and similarly, a match with a wildcard certificate would also be adequate.

If an attacker is able to manipulate a DNS server by using a technique like DNS cache poisoning (i.e. altering the IP address that a Fully Qualified Domain Name is associated with), then a user can be fooled into believing that they have connected to a trusted site (e.g. www.medeatalk.com) when in reality they are connected to a rogue site even though the URL will be correct. Under these circumstances the only protection is that a trusted Certificate Authority would not sign a request for the www.medeatalk.com entity without adequate checks.

Page 145 of 229

Essential Communication Security Skills for Polycom Solutions

Validity Period The next check verifies that the validity period of the certificate (i.e. the current date and time) as established by the endpoint are after the Valid From value and before the Valid To value.

If the certificate is out-of-date then a secure connection should not be established and an appropriate error message should be generated (see figure below); for example: The security certificate presented by this website has expired or is not yet valid.

Note: Problems with Validity Period checks are often encountered in situations where the endpoint does not have access to an accurate clock source.

Enhanced Key Usage The final check verifies that the Enhanced Key Usage attribute of the certificate is acceptable to the specific application (e.g. for a web server the enhanced usage should ensure the identity of a remote computer - i.e. server authentication) and relates to code signing or secure e‑mail. If the certificate usage is invalid then a secure connection should not be established and an appropriate error message should be generated.

Page 146 of 229

Essential Communication Security Skills for Polycom Solutions

Check Certificate Revocation Status When the Crypto Library has built and validated a certificate chain, the revocation status of the chain can be determined. For each chain that ends in a self-signed certificate held in the trusted root store, revocation checking is performed. The revocation checking is performed from the root CA certificate down to the evaluated certificate in order to minimise the work performed (i.e. if the root CA certificate has been revoked then no further checking need be performed).

Page 147 of 229

Essential Communication Security Skills for Polycom Solutions

Part 2: Summary

Part 2: Summary • Public Key Infrastructure − Digital Certificates − Certification Authorities

©

Polycom, Inc. All rights reserved.

27

The second part of this course has covered digital certificates and the Public Key Infrastructure that supports their use. Before moving on to part 3 of the course there are a series of labs using Wireshark which show the risks of insecure communication. They also introduce secure communication using protocols such as SSL and TLS and show how these can mitigate the risks.

Page 148 of 229

Essential Communication Security Skills for Polycom Solutions

Lab 9.1: Install Wireshark packet capture tool Objective In this lab, you will install the Wireshark application. This packet capture tool will be utilized in subsequent labs in order to assess the security provided by various cryptographic protocols (i.e. SSL/TLS).

Steps 1. Restore the connection to CLI01 2. Click Start, select Run… 3. In an open text box, enter the following path: \\entry\software 4. Click the OK button 5. In the software share dialog, double-click the Wireshark-win64-1.8.1.exe file 6. At the Open File – Security Warning dialog, click the Run button 7. At the Welcome to the Wireshark Setup Wizard dialog, click Next 8. At the License Agreement dialog, click I Agree 9. At the Choose Components dialog, keep the default component selection and click Next 10. At the Select Additional Tasks dialog, in the Create Shortcuts section, tick Desktop Icon, keep all other settings as default and click Next 11. In the Choose Install Location dialog, keep the default destination folder and click Next 12. In the Install WinPcap? dialog, ensure Install WinPcap 4.1.2 is selected and click the Install button – the Wireshark installation now commences 13. When the WinPcap Installer dialog is displayed, click Next 14. At the Welcome to WinPcap Setup Wizard dialog, click Next 15. At the WinPcap License Agreement dialog, click I Agree 16. In the Installation options dialog, keep the default settings to Automatically start the WinPcap driver at boot time and click the Install button – WinPcap is now installed 17. At the Completing the WinPcap Setup Wizard dialog, click Finish - the Wireshark installation now resumes 18. At the Installation Complete dialog, click Next

Page 149 of 229

Essential Communication Security Skills for Polycom Solutions

19. At the Completing the Wireshark Setup Wizard dialog, click Finish 20. Close the software share dialog window 21. Leave the CLI01 connection open for use in the next exercise

Lab 9.2: Use Wireshark to Perform Packet Capture Objective In this lab, you will use the Wireshark packet capture tool to perform a packet capture of a unsecured communication between a web browser and a web server.

Steps 1. On CLI01, click Start, All Programs, Wireshark 2. In the Filter text box (top-left of interface) enter the following expression: ip.addr==172.16.1.13 Note: The filter box will change between red and green whilst typing. Once completed it will show green to indicate the syntax is correct.

3. Click the Save button to the right of this entry and when prompted replace the default Filter name with SRV01 4. Click the OK button Note: An SRV01 button appears next to the Save button. This button can be used as a shortcut to specify this filter.

5. In the Capture section of the main Wireshark interface, highlight the Intel (R) PRO/1000 MT Network Connection entry 6. Click the Start link found above this interface entry – packet capturing should now commence 7. Click the Apply button in the Filter toolbar – the captured packets list will now show few if any entries since the filter requires packets containing the 172.16.1.13 address 8. Click Start, select Internet Explorer and specify the following URL:http://www.medeatalk.com 9. Click the Go To button (i.e. green arrow) 10. When the Now you see it and now you don’t message is displayed, minimize the Internet Explorer window 11. In the Wireshark interface, from the Capture menu, select the Stop option

Page 150 of 229

Essential Communication Security Skills for Polycom Solutions

12. In the Packet Capture pane (i.e. top pane of main interface), scroll-up to the top of the Packet Capture Listing 13. Review the Packet Capture Listing and highlight the packet with the following properties:

Property

Value

Source Property Destination Protocol Info

172.16.1.13 172.16.1.14 HTTP HTTP/1.1 200 OK (text/html)

14. In the middle pane of the Wireshark interface, expand the Line-based text data section and verify the HTML content of for the default.htm page can be read (i.e. Now you see it‌.)

15. In the File menu, select Quit and choose the Quit Without Saving option button 16. Close Internet Explorer 17. Minimize the CLI01 connection for use in the next exercise

Lab 9.3: Perform Wireshark packet capture on a Secure Connection Objective In this lab, you will perform a Wireshark Packet capture on a secure connection from a web browser to the SRV01 website and review the packets captured.

Steps 1. Restore the CLI01 connection 2. From the Start menu, choose Internet Explorer and specify the following URL: https://www.medeatalk.com 3. Click the Go To button (i.e. green arrow) 4. After ~20s, the browser displays a warning page regarding the website’s security certificate, record the reason for the warning below: ____________________________________________________________________ 5. How can this issue be rectified? ____________________________________________________________________ 6. Close Internet Explorer

Page 151 of 229

Essential Communication Security Skills for Polycom Solutions

Sub-Task 9.3.1: Install a copy of the LON-SRV01-CA Security Certificate in to the trusted root store of CLI01 1. On CLI01, click Start, Run… 2. In the Open text box enter the following: \\entry\software 3. Click OK 4. When the software share dialog opens, double-click the lon-srv01-ca.cer entry 5. When prompted with a Security Warning, click the Open button 6. When the Certificate dialog is displayed, choose the Install Certificate… button 7. The Certificate Import Wizard is now launched, click Next 8. At the Certificate Store dialog, choose Place All Certificates in the following store 9. Click the Browse… button 10. Tick the Show Physical Stores option 11. Expand the Trusted Root Certificate Authorities container 12. Choose the Local Computer sub-container and click OK 13. Click Next 14. At the Completing Certificate Import dialog, click the Finish button 15. After approximately 20 seconds, click OK to acknowledge a successful import 16. Click OK on the Certificate dialog – the window closes 17. Close the software share dialog

Sub-Task 9.3.2: Repeat attempt at secure connection 1. On CLI01, click Start, Wireshark 2. In the Filter toolbar, click the SRV01 button – a filter should now be shown in the Filter text box of ip.addr==172.16.1.13 3. In the Capture section of the interface, highlight the Intel Network Connection and click the Start link 4. Minimize Wireshark

Page 152 of 229

Essential Communication Security Skills for Polycom Solutions

5. From the Start menu, choose Internet Explorer and specify the following URL: https://www.medeatalk.com 6. Click the Go To button (i.e. green arrow) 7. Verify that the Now you see it and now you don’t message is displayed and there are no longer any security certificate warnings displayed by the browser Troubleshooting Tip: if the browser still displays the security warning when opening the secure web site restart CLI01 by clicking the Start button, clicking the Arrow next to Logoff and selecting Restart. Wait for about two minutes and then reopen CLI01 using the icon on the desktop of the Entry machine. Login as Administrator / Polycom!23 Once logged in you should repeat the instructions from the beginning of 9.3.2.

8. Single-click on the padlock next to the URL in the browser and verify that the CA has identified the webserver and that the connection is encrypted 9. Minimize Internet Explorer

Page 153 of 229

Essential Communication Security Skills for Polycom Solutions

Lab 9.4: Analyze key stages involved in the establishment of a secure connection using TLS Objective In this lab, you will analyze the packets captured by Wireshark when a secure connection is established between a web browser and web server using TLS. Hint: For your reference the course material describes the SSL/TLS handshake in detail.

Steps 1. On CLI01, restore Wireshark 2. From the Capture menu, choose the Stop option 3. In the Packet Capture pane (top pane of the main interface) scroll-up to the top

4. Highlight the packet which matches the following criteria:

Property

Value

Source Property Destination Info

172.16.1.14 172.16.1.13 Client Hello

5. Record the protocol designated to this packet by Wireshark below: ________ 6. In the middle pane, expand the Secure Sockets Layer section 7. Expand the TLSv1 Record Layer section 8. Expand the Handshake Protocol: Client Hello 9. Review the expanded section and record the following parameters offered by CLI01:

Parameter Content Type Minimum TLS Version Number of cipher suites 1st item in the cipher suites list Server Name

Value

Note: The cipher suites offered by the client to the server are listed in order of preference although the web server can select any of the named suites.

Page 154 of 229

Essential Communication Security Skills for Polycom Solutions

10. Return to the Packet Capture section, highlight the packet that matches the following criteria:

Property

Value

Source Property Destination Protocol Info

172.16.1.13 172.16.1.14 TLSv1 Server Hello, Certificate, Server Hello Done

11. In the middle pane, expand Secure Sockets Layer, TLSv1 Record Layer, Handshake Protocol: Server Hello 12. Indicate the cipher suite selected by the Web Server below: _______________________________________________________________ 13. Did the Web Server select the preferred cipher suite of the browser? (Yes/No) 14. From the File menu, select Save As‌ 15. Choose the C:\PacketCaptures folder 16. Enter a File Name of capture1, keep the default Save as type and click the Save button 17. From the File menu, choose Quit 18. Close Internet Explorer 19. Minimise the CLI01 connection dialog for use in a later lab

Page 155 of 229

Essential Communication Security Skills for Polycom Solutions

Part 3: Secure Sockets Layer (SSL) and Transport Layer Security (TLS) Overview

Transport Layer Security (TLS) and Secure Sockets Layer (SSL) are cryptographic protocols that provide communication security over insecure networks (e.g. the Internet) between a client and a server.

SSL v2.0 was originally built into the first versions of Netscape Navigator. The protocol was aimed at securing Web transactions for commerce and financial organizations. These days both SSL and TLS are built into most Web browsers and other clients in a way that does not require any end user action. Both protocols are industry standards and are used in millions of Internet transactions (e.g. credit card purchases over the Internet) to provide end-to-end protection between the server and the user.

The primary goals of these protocols are to provide the following security services:    

data confidentiality integrity of network communication authentication of server optional authentication of client

Page 156 of 229

Essential Communication Security Skills for Polycom Solutions

These protocols must allow the client and the server to negotiate unique cipher keys without requiring any prior communication between them. The negotiations can also be used to decide on encryption algorithms to be used for the oncoming data exchange between the two parties.

The protocols achieve these goals by utilizing a variety of techniques:   

asymmetric cryptography for key exchange and authentication symmetric encryption for confidentiality hashed-message authentication codes(HMACs) for message integrity and authentication

The encryption of information takes place below the Application Layer and before delivery to the Transport Layer. A key advantage of SSL and TLS is that they are application protocol independent (i.e. higher-level protocols such as HTTP and SMTP can sit on top of the SSL and TLS protocols transparently).

Although, SSL was originally designed for use with HTTP only, both SSL and TLS are now capable of working with a many different application layer protocols. They are commonly used in applications such as web browsing (i.e. HTTP), electronic mail (i.e. SMTP), directory services (i.e. LDAP), and voice-over-IP (i.e. SIP).

Page 157 of 229

Essential Communication Security Skills for Polycom Solutions

Versions Most people associate a secure web connection (i.e. HTTPS) with the Secure Sockets Layer (SSL) protocol which was created by Netscape in the mid-90s. In reality, it is rare to see SSL traffic these days since its successor, the Transport Layer Protocol (TLS), has been in common use for around for 10 years.

There are two released versions of the SSL protocol:  

SSL v2 SSL v3

SSL v2 was the first released version and was included in the original version of Netscape Navigator for secure network transactions. SSL version 3 was later released to fix some security issues in the previous version and add client authentication. The optional client authentication (known as mutual authentication) is typically used when a server requires user authentication (e.g. may be required when remote users can download proprietary and confidential information from an organization's server).

As later versions of SSL outgrew being just a Netscape standard, the continued development and maintenance of the protocol became the responsibility of the Internet Engineering Task Force (IETF). It was re-branded and developed into Transport Layer Security 1.0 which was published as an open standard in January 1999 (RFC 2246). As an open standard, TLS is more extensible and more likely to be supported in the future with other Internet standards.

SSLv3 and TLS v1.0 are very similar which means that supporting both protocols in a client is relatively straightforward. However, even though the differences between them are relatively small, they are completely incompatible with each other. This incompatibility was mitigated by making TLS backwards compatible (i.e. it possesses the capability to downgrade to SSL in order to support clients that only support this protocol).

Many applications provide support for a number of different versions of SSL and TLS. For example, Microsoft’s Internet Explorer v9 can utilize any of the following versions: Name

Internal Version

SSL 2.0 SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2

2.0 (0x0002) 3.0 (0x0300) 3.1 (0x0301) 3.2 (0x0302) 3.3 (0x0303)

Page 158 of 229

Essential Communication Security Skills for Polycom Solutions

The versions used are displayed in tools such as Wireshark. The example below shows information that was visible in Lab 9.4.

Although SSL v3.0 and TLS v1.0 are generally considered equal in terms of security this is not strictly correct. Even though the basic architecture of the TLS protocol is similar to SSL, it is an advanced version of the protocol with better security features and includes fixes for some security issues. A key difference lies in the improved choice of the hashing and public key encryption algorithms that TLS uses for providing security services.

The table below shows key changes which have taken place in the SSL and TLS protocol versions: Protocol SSL SSL

Version 2.0 3.0

    

TLS

1.0

TLS

1.1

TLS

1.2

       

Changes RC4, 3DES or DES symmetric algorithms supported Support for mutual authentication Full support for 128-bit keys Implementing a generalized key exchange protocol (e.g.

DH) Ability to fall back to SSL 2.0 when a 2.0 client is encountered Key derivation functions modified Uses Standard HMAC algorithms (SSL used an early derivation) More alerts Mandatory DSS/DH support Fixed Cipher block chaining vulnerability More secure handling of padding errors Use of stronger encryption algorithms (e.g. replacement of MD5-SHA1 with SHA-256) Remove backward compatibility re-negotiation to SSL v2.0

Page 159 of 229

Essential Communication Security Skills for Polycom Solutions

Architecture As discussed earlier, the TLS and SSL protocols encrypt TCP messages passing from the Application Layer for delivery to the Transport Layer of the TCP/IP networking model.

Note: Although UDP datagrams are also support (e.g. in OpenVPN) their use is far less common.

As shown in the diagram TLS/SSL is comprised of several different sub-protocols. The two main protocols are: Protocol SSL/TLS Handshake Protocol

SSL/TLS Record Protocol

Description Perform the client and server SSL session establishment including server and client to authentication, negotiate an encryption algorithm and securely exchange cryptographic keys.

Encapsulates and transfers both application protocol (e.g.

HTTP) and SSL Control data between the client and server in a secure manner

The initial handshake sequence also uses two additional protocols: Protocol Description SSL/TLS Change Cipher Spec Establish agreement on the Cipher Suite for the session.

Protocol SSL/TLS Alert Protocol Convey SSL error messages between client and server

Page 160 of 229

Essential Communication Security Skills for Polycom Solutions

The figure below shows the mechanism used by the SSL Record Protocol to encapsulate the application protocol data:

TLS/SSL Record Protocol

The TLS/SSL protocol may fragment or combine application-layer protocol data messages into record protocol units. These units may optionally be compressed, HMAC digest signatures are attached for integrity and authentication and symmetric data encryption applied to provide the units with data confidentiality before transmission using the underlying reliable transport protocol (i.e. TCP).

Page 161 of 229

Essential Communication Security Skills for Polycom Solutions

Note: Although support for compression is built into the protocols in practice the major SSL and TLS implementations lack support for compression. The figure below shows the compression negotiation taking place during the Client Hello phase. Only one compression method is available and this is null.

Page 162 of 229

Essential Communication Security Skills for Polycom Solutions

Pre-requisite Configuration There are some pre-requisites which should be implemented before the use of SSL/TLS may be considered:

Support for SSL/TLS The client and server applications must offer support for the version of SSL/TLS which is required. For example, most web server applications offer support for common versions of SSL and TLS. In some cases a web server (e.g. Apache) may require the installation and configuration of an additional module (e.g. mod_ssl).

Note: Currently Web Server implementations may not offer support for the latest versions of TLS. For example, the current implementation of the OpenSSL libraries do not yet offer support for TLS 1.1 in a stable release. These libraries are used by mod_ssl to provide SSL/TLS in the Apache web server. Similarly, although the current implementation of Internet Information Server (IIS) v7.5 has the capability to support TLS 1.1 and TLS 1.2; they are not enabled by default.

Server Certificate The server must have a server certificate installed along with the corresponding private key.

If mutual authentication is required, then a certificate and private key must also be installed on the client.

Optional or Mandatory SSL/TLS The server can typically be configured to allow or require secure communication using SSL / TLS (see the figure below from the IIS management console):

Page 163 of 229

Essential Communication Security Skills for Polycom Solutions

SSL/TLS Handshake The handshake protocol provides the necessary information to initiate the session requested by the endpoint/user.

When a client and a server agree to communicate using the TLS or SSL protocol, they also need to agree on several other key points:    

which protocol and version (TLS 1.0, 1.1, SSL2 or SSL3) to use whether or not to perform mutual authentication (i.e. a secure client-server communication requires server and optionally client authentication) public-key encryption techniques (e.g. a cryptographic algorithm to be used for key exchange). This will be used to generate a pre-master secret key the enciphering of data using keys generated from the pre-master key (i.e. creation of session keys)

Page 164 of 229

Essential Communication Security Skills for Polycom Solutions

SSL/TLS Handshake Sequence

Figure 2: SSL/TLS Handshake Sequence

The figure above shows the complete handshake sequence and this process is described in detail below.

Note: As a general rule, if any one of the above steps fails, the TLS handshake fails and the connection is not created.

Client Initiates Connection When the connection is initiated, the client must indicate to the server that it is using an SSL/TLS connection. There are a number of ways in which this can be achieved:  

The main way of achieving this is to use a different port number for TLS connections (for example port 443 for HTTPS, 636 for LDAPS or 5061 for SIP over TLS).

In some circumstances the protocol identifier can be used to initiate a secure connection. For example, the use of HTTPS in a URL (as per RFC 2818) indicates to the web browser that it should connect the destination server on port 443.

Page 165 of 229

Essential Communication Security Skills for Polycom Solutions



Finally, some protocols use a specific command to switch from an unsecured to a secured connection (e.g. SMTP uses the STARTTLS command for this purpose).

The figure below shows an initial connection request (i.e. SYN packet) from the web browser to the web server using a destination port of 443 (i.e. HTTPS).

Figure 3: Client initiates a TLS/SSL connection

Negotiation Phase As described above, once the client and server have decided to use SSL/TLS they negotiate the connection by using the handshake protocol. This "handshake" is encapsulated in the Record Protocol with a content-type of 22 to indicate the Handshake Protocol.

Note: SSL/TLS encapsulates all traffic (i.e. both SSL control and application data) in the Record Protocol with differing types.

During this phase the client and server exchange security capabilities, compression methods and an initial random number. The initial messages also allow the server and client to verify the other parties’ capabilities; for example, if the server demands a strong 256-bit encryption but the client is not able to handle this requirement then the session will fail.

Client Hello Message

The client sends to the server its requirements for communicating using the TLS protocol.

This initial message is known as the Client Hello and it includes the following information:

1. The highest TLS protocol version supported by the client 0x0301 indicates that the highest version supported by the client is version 3.1 (as discussed earlier this internal version equates to TLS 1.0) 2. A number which contains two parts: a. the current Greenwich Mean Time (GMT) in the Unix epoch format (i.e. the number of seconds since January 1, 1970). b. a 28-byte random number which will be used later in the handshake process

Page 166 of 229

Essential Communication Security Skills for Polycom Solutions

Note: Random numbers (known as Nonces) are used to ensure that this communication between the client and server is unique. The unique random element can be used to seed the communication and prevent replay attacks in which an attacker uses old communication traffic to establish or break a new communication.

3. A list of suggested Cipher Suites This contains a list of all of the encryption algorithms supported by the client. The list is in order of preference with TLS_RSA_WITH_AES_128_CBC_SHA as first choice and another 11 acceptable options. Note: The server won’t necessarily pick the first choice of the client often for reasons of improving performance or reducing resource utilization.

4. A session ID: In the figure below the session ID can be seen to be empty (i.e. null). The Session ID is used to reduce the overhead of a full handshake in circumstances where the client closes the current connection and reconnects in the near future. For example, if the client had recently connected to www.medeatalk.com it could include that Session ID in the Client Hello message and potentially resume the session whilst avoiding the full handshake.

5. SSL/TLS extension – Server Name Indication (SNI): There are a number of extensions which can be included in the SSL/TLS Client Hello message. An important example used for web traffic is the Server Name Indication (SNI) extension. The value in this field can be used by the web server to determine which digital certificate it should provide to the client. For example, in the figure below, the web server receiving this message would know to provide the www.medeatalk.com digital certificate.

Page 167 of 229

Essential Communication Security Skills for Polycom Solutions

Note: The current HTTP v1.1 implementation uses a "Host" header to indicate to the web server that a request is for a particular site. This allows the web server to host multiple websites on a single IP address. Unfortunately, the TLS handshake occurs long before any HTTP traffic but the web server must return the correct digital certificate. For this reason SSL v2.0 required a different IP for each site, however the implementation of this extension in later versions of SSL and TSL allows the server to respond with the appropriate certificate.

Server Hello Message The server responds with information that the client needs to communicate with the server over TLS. The response record has a Content-Type of 22 to indicate a handshake, however, the record is divided into multiple sub-messages (see figure below):

The first sub-message is a Server Hello message which includes the following:

1. Chosen protocol version: The protocol version indicates 0x0301 which means that the server agreed to the client request to use TLS v1.0.

Note: The chosen protocol version should be the highest that both the client and server support. For example, if the client supports TLS1.1 and the server supports TLS1.2, TLS1.1 should be selected; SSL 3.0 should not be selected.

2. A random number: The server also generates a timestamp and random number for use later in the handshake Session ID a 32-byte session ID has been generated which could be used by the client to reconnect without the need for a full handshake.

3. CipherSuite from the list of options offered by the client: The server has chosen a cipher suite of "TLS_RSA_WITH_AES_128_SHA1" (0x002f) which matches with the client’s first preference. Note: This selection means the client and server will use the "RSA" public key algorithm to verify certificate signatures and exchange keys, the AES encryption algorithm to encrypt data and the SHA1 hash function to verify the contents of messages.

Page 168 of 229

Essential Communication Security Skills for Polycom Solutions

Certificate Message The second sub-message is the Certificate message. This message contains a copy of the server’s digital certificate which the client will use to authenticate the server later in the handshake process.

Certificate Request Message (mutual authentication only) Optionally, the server may include a Certificate Request message which requires the client to send a copy of its digital certificate so that the server can authenticate the client (i.e. mutual authentication). This option will be covered later in SSL/TLS Mutual Authentication section.

Server Hello Done Message The final sub-message sent by the server is a Server Hello Done message. This message indicates that the server won't be asking the client for a certificate and that it has completed the handshake negotiation. In the figure below it can be seen that this is a zero byte message:

Authentication and Key Exchange Phase In the next phase, the client uses the information sent by the server to authenticate the server. If the server cannot be authenticated then a secure connection cannot be established and a warning message generated. The authentication process was covered earlier in the Certification Validation section. In addition, the server may authenticate the client if a digital certificate of the client was requested by the server.

Page 169 of 229

Essential Communication Security Skills for Polycom Solutions

Certificate Message (mutual authentication only) If the server requested client authentication (i.e. a Certificate Request Message was sent by the server), then the client sends a copy of its own certificate to the server. This option will be covered later in the SSL/TLS Mutual Authentication section.

Client Key Exchange Message The client uses the data generated during the handshake to create the Pre-Master Secret for the session. Although this 48-byte secret is not used directly it is important to keep it secure since it is used to derive other security parameters which are used to secure the session.

This Pre-Master Secret is encrypted using the RSA public key from the server certificate. The cipher selection of TLS_RSA_WITH_AES_128_SHA1 indicates that the RSA asymmetric cipher should be used for this purpose. It then sends the encrypted pre-master secret to the server in a Client Key Exchange message.

Certificate Verify Message (mutual authentication only) If mutual authentication has been requested then the client sends a Certificate Verify message. This message is an encrypted hash (i.e. signature) of all previous handshake messages sent or received. It is encrypted using the client's private key. The server can verify the signature by using the public key obtained from the client's digital certificate. This proves to the server that the client has access to the private key and consequently is the owner of the digital certificate provided. This option will be covered later in SSL/TLS Mutual Authentication section.

At this stage, if the server has requested client authentication, then the server attempts to authenticate the client (see Certificate Validation above). If the server is unable to authenticate the client then a secure connection will not be established.

If the client can be successfully authenticated or no mutual authentication was requested then the server uses its private key to decrypt the pre-master secret. At this point both the client and server have a copy of the pre-master secret. They both perform a series of steps using the random numbers and Pre-Master Secret to compute a common secret, called the "master secret". All other key data required for this session is derived from this master secret.

Page 170 of 229

Essential Communication Security Skills for Polycom Solutions

Typically the key data generated will include the following:   

Symmetric key for client and server – used to encrypt and decrypt information exchanged during the session Initialization Vectors (IVs) for client and server – used by symmetric block ciphers to randomize the data at the start of a message HMAC secret for client and server – used to verify its integrity and authenticate information exchanged during the session

Note: IVs are not required for stream ciphers (see earlier in course material). Since the cipher selected for this session was TLS_RSA_WITH_AES_128_SHA1, the AES block cipher algorithm will require IVs.

Change Cipher Spec Message (from client) At this stage the client utilizes the Change Cipher Spec sub-protocol to inform the server that future messages from the client will be authenticated and encrypted with the HMAC and symmetric keys. As before, this message is encapsulated in a SSL/TLS record with a content type of 20.

Finished Message (from client) Finally, the last handshake message which the client sends is an authenticated and encrypted handshake Finished message to the server. This encrypted message contains a HMAC hash of all the previous handshake messages. This message informs the server that the client portion of the handshake has completed.

The server will attempt to decrypt the client's Finished message and verify the HMAC. This message proves the integrity and authenticity of the handshake and it proves that the client knows the keys. If the decryption or verification fails, the handshake is considered to have failed and the secure connection will be rejected.

Page 171 of 229

Essential Communication Security Skills for Polycom Solutions

Change Cipher Spec Message (from server) The server performs almost exactly the same process as the client (i.e. it sends out a "Change Cipher Spec" followed by a "Finished Message").

The server sends a message to the client informing it that future messages from the server will be authenticated and encrypted with the session keys.

Finished Message (from server) The server then sends a separate authenticated and encrypted Finished message indicating that the server portion of the handshake has completed. As before this encrypted message contains an HMAC hash of all previous handshake messages but including the decrypted version of the client's "Finished Message."

The client performs the same decryption and verification and if successful then this proves to the client that the server was able to successfully decrypt its message.

Application Phase This phase commences on completion of a successful handshake. At this point the application protocol data is encapsulated in SSL/TLS records with a content-type of 23. The application data messages exchanged between client and server will also be authenticated and encrypted using the same mechanism as the Finished messages.

In the figure above, HTTP traffic is transferred using AES 128-bit encryption and HMAC_SHA1 to prevent tampering and prove origin. The SSL/TLS process can be completely transparent to the user although when using a browser a secure icon is displayed in the status bar (e.g. a padlock in Internet Explorer).

Page 172 of 229

Essential Communication Security Skills for Polycom Solutions

Double-clicking on this icon will reveal the trusted certification authority and that the connection is encrypted.

At any time, due to internal or external factors either side can force a renegotiation of the connection, in which case, this procedure is repeated.

Alert Protocol When an error is detected, the detecting party sends a message to the other party using the Alert protocol. Alert messages convey the severity of the message and a description of the alert. Alert messages with a level of fatal result in the immediate termination of the connection. In addition, servers and clients are required to discard any session-identifiers, keys, and secrets associated with a failed connection.

Page 173 of 229

Essential Communication Security Skills for Polycom Solutions

Some of the TLS error alerts are defined as follows: Alert bad_record_mac handshake_failure

unknown_ca

bad_certificate certificate_revoked certificate_expired decrypt_error

unknown_name

close_notify

Description This alert is returned if a record is received with an incorrect MAC. Reception of a handshake_failure alert message indicates that the sender was unable to negotiate an acceptable set of security parameters given the available options.

A valid certificate chain or partial chain was received, but the certificate was not accepted because the CA certificate could not be located or couldn`t be matched with a trusted CA. A certificate was corrupt or contained signatures that did not verify correctly A certificate was revoked by its signer.

A certificate has expired or is not currently valid.

A handshake cryptographic operation failed including not being able to correctly verify a signature, decrypt a key exchange or validate a Finished message.

Client Server Name Indicator (SNI) specified a hostname not recognised by the server. For example, an Apache web server configuration file should contain a directive stating the hostname: ServerName clients.medeatalk.com:443 This message notifies the other party that the sender will not send any more messages on this connection and the session should not be resumed.

Level Fatal Fatal

Fatal

Unspecified Unspecified Unspecified Unspecified

Unspecified

Fatal/Warning

Note: For errors where an alert level is not explicitly specified, the sending party may determine whether it should be designated as fatal. All messages which are received with a level of fatal must be treated as such, if however, a receiving party is sent a non-fatal alert then it may decide whether to treat this as fatal error or not.

Page 174 of 229

Essential Communication Security Skills for Polycom Solutions

SSL/TLS Mutual Authentication

In the normal SSL/TLS handshake process only the web server is authenticated, however as previously described, it is possible for a web server to request client authentication. This is known as mutual authentication.

When mutual authentication is required, the SSL/TLS handshake is modified as follows:

Certificate Request Message The server uses a Certificate Request to request a client certificate (see figure below):

Page 175 of 229

Essential Communication Security Skills for Polycom Solutions

The Certificate Request holds the names of Certification Authorities which are trusted by the server (see figure below):

In the figure, it can be seen that the list of server trusted CAs include the LON-SRV01-CA.

Certificate Message When mutual authentication is required, the client responds to the server with two additional messages.

On receiving a Certificate Request, the client supplies its certificate to the server in the Certificate message (see figure below):

In the figure, the certificate for the client can be observed in the Certificate message sent to the server. In addition, the CA issuing the client certificate (i.e. LON-SRV01-CA) is displayed.

Note: The client will only return a certificate to the server if it has been issued by one of the CAs in the trusted list of the server.

Page 176 of 229

Essential Communication Security Skills for Polycom Solutions

Certificate Verify The client proves ownership of the certificate using a Certificate Verify message (see figure below):

As described above, this message is an encrypted hash (i.e. signature) of all previous handshake messages sent or received. It is encrypted using the client's private key. If the server can verify the signature using the public key in the client's digital certificate then it is proof the client has access to the private key and therefore is the owner of the digital certificate.

At this stage the mutual authentication can be performed.

TLS builds on the features of SSL and offers more flexible security at the transport layer.

TLS is not compatible with SSL version 3.0 but systems may be configured to offer TLS, but revert to SSL if it is not supported at the other end. Unlike SSL, it is application-independent; for example, it has been used to support secure SMTP, IMAP and POP3.

Page 177 of 229

Essential Communication Security Skills for Polycom Solutions

Implementation SSL and TLS have been widely implemented in several free and open source software projects. Programmers may use the PolarSSL, CyaSSL, OpenSSL, MatrixSSL, NSS, or GnuTLS libraries for SSL/TLS functionality. Microsoft Windows includes an implementation of SSL and TLS as part of its Secure Channel package.

Polycom Note: The use of OpenSSL in RMX.

Applications In applications design, TLS is usually implemented on top of any of the Transport Layer protocols, encapsulating the application-specific protocols such as HTTP, FTP, SMTP, NNTP and XMPP. Historically it has been used primarily with reliable transport protocols such as the Transmission Control Protocol (TCP). However, it has also been implemented with datagram-oriented transport protocols, such as the User Datagram Protocol (UDP) and the Datagram Congestion Control Protocol (DCCP), usage which has been standardized independently using the term Datagram Transport Layer Security (DTLS).

A prominent use of TLS is for securing World Wide Web traffic carried by HTTP to form HTTPS. Notable applications are electronic commerce and asset management. Increasingly, the Simple Mail Transfer Protocol (SMTP) is also protected by TLS. These applications use public key certificates to verify the identity of endpoints.

TLS is also a standard method to protect Session Initiation Protocol (SIP) application signaling. TLS can be used to provide authentication and encryption of the SIP signaling associated with VoIP and other SIP-based applications.

Page 178 of 229

Essential Communication Security Skills for Polycom Solutions

Part 3: Summary and Lab 10

Lab 10 • Exercise 10.1: Install Sub-ordinate CA • Exercise 10.2: Root CA Signing Sub-Ordinate CA Certificate Request • Exercise 10.3: Install the Sub-Ordinate CA Certificate • Exercise 10.4: Place the Root CA in an Off-line State • Exercise 10.5: Configure the Sub-Ordinate Certification Authority • Exercise 10.6: Generate a new Certificate Request for the Web Server • Exercise 10.7: Use the Sub-Ordinate CA to Sign A New Certificate Request for Web Server • Exercise 10.7: Install new Certificate on Web Server and Verify the Configuration • Exercise 10.8: Revoke Web Server Certificate

©

Polycom, Inc. All rights reserved.

29

The course has now covered all the building blocks and techniques required for deploying and managing a Public Key Infrastructure (PKI) to support secure communication using SSL/TLS. The following labs will show the use of a subordinate Certificate Authority; using the hierarchical model described in part 2.

Page 179 of 229

Essential Communication Security Skills for Polycom Solutions

Lab Figure

Page 180 of 229

Essential Communication Security Skills for Polycom Solutions

Lab 10.1: Install Sub-ordinate CA Objective In this lab, you will install a Sub-ordinate CA and generate a certificate signing request to be signed by the root CA.

Steps 1. On the Entry machine, double-click the NYC-SRV01 shortcut and log on using the NYCSRV01 credentials as specified in the Delegate Information Sheet 2. From the Start menu, select Administrative Tools, Server Manager 3. In the left-hand pane, select Roles 4. In the right-hand pane, select Add Roles 5. At the Before You Begin dialog, click Next 6. At the Select Server Roles dialog, select Active Directory Certificate Services and click Next 7. At the Introduction to Active Directory Certificate Services, click Next 8. At the Select Roles Services, ensure Certification Authority is selected and also select Certification Authority Web Enrollment 9. When prompted with the Add Roles Wizard, choose the Add Required Role Services button and click Next 10. At the Specify Setup Type dialog, ensure Standalone is selected and click Next Note: The Enterprise option is greyed out since this machine is not a member of an Active Directory domain.

11. At the Specify CA Type dialog, choose Subordinate CA and click Next 12. At the Set Up Private Key dialog, keep the default Create a new private key option selected and click Next 13. At the Configure Cryptography for CA, keep the default settings and click Next 14. At the Configure CA Name dialog, keep the default Common name for this CA of NYC-SRV01-CA and click Next 15. At the Request Certificate from a Parent CA dialog, choose the option of Save a certificate request to file and manually send it later to a parent CA Note: the next lab includes the steps to sign this at the Root CA

Page 181 of 229

Essential Communication Security Skills for Polycom Solutions

16. Click Browse‌ and specify a File Name of: \\entry\software\subca.req 17. Click the Save button and click Next 18. At the Configure Certificate Database dialog, keep the default database and log locations and click Next 19. At the Web Server (IIS) dialog, click Next 20. At the Select Role Services, keep the default settings and click Next 21. At the Confirm Installations Selections, click the Install button Note: It may take several minutes to perform the installation.

22. At the Installations Results dialog, click Close 23. Close Server Manager 24. Minimize the NYC-SRV01 connection for use in a later lab

Page 182 of 229

Essential Communication Security Skills for Polycom Solutions

Lab 10.2: Root CA Signing Sub-Ordinate CA Certificate Request Objective In this lab you will use the root CA to sign the Sub-Ordinate CA certificate signing request and generate a Sub-Ordinate CA signing certificate.

Steps 1. Restore the connection to LON-SRV01 2. From the Start menu, select Administrative Tools, Certification Authority 3. In the left hand pane, expand LON-SRV01-CA, right-click on LON-SRV01-CA and from the All Tasks sub-menu, select Submit new request‌ 4. Browse to \\entry\software and select the subca.req file 5. Click the Open button 6. In the left-hand pane, choose the Pending Requests container 7. In the right-hand pane, right-click on the request and choose the All Tasks sub-menu and click Issue 8. In the left-hand pane, choose the Issued Certificates container and in the right-hand pane, double-click the entry with the highest number Request ID (i.e. the most recent request) Note: The certificate template column should indicate a SubCA against this entry.

9. Double-click the entry and in the Certificate dialog, select the Details tab 10. Click the Copy to File‌ button 11. When the Welcome to the Certificate Export Wizard is launched, click Next 12. In the Export File Format dialog, select Base-64 encoded X.509 (.CER) option and click Next 13. In the File to Export dialog, enter a File name of \\entry\software\subca.cer and click Next 14. At the Completing the Certificate Export Wizard dialog, click Finish 15. At the Certificate Export Wizard, click OK to acknowledge the export was successful 16. Click OK to close the Certificate dialog

Page 183 of 229

Essential Communication Security Skills for Polycom Solutions

Sub-Task 10.2.1: Publish the Certificate Revocation List for the Root CA Note: The CRL will be used in a later lab to verify that the sub-ordinate CA certificate has not been revoked.

1. On LON-SRV01, in the left-hand pane of the Certificate Authority Manager, highlight the Revoked Certificates container 2. Right-click on the Revoked Certificates container and in the All Tasks sub menu, select Publish 3. When prompted with the Publish CRL dialog, verify that the Type of CRL to publish is a New CRL Note: The Delta CRL only option is greyed-out at this stage since no Base CRL has previously been published.

4. Click the OK button 5. Close the Certification Authority Manager 6. Minimize the LON-SRV01 connection for use in a later lab

Page 184 of 229

Essential Communication Security Skills for Polycom Solutions

Lab 10.3: Install the Sub-Ordinate CA Certificate Objective In this lab you will install the newly created sub-ordinate CA certificate on to the NYCSRV01-CA.

Steps 1. Restore the connection to NYC-SRV01 2. From the Start menu, select Administrative Tools, Certification Authority 3. In the left-hand pane, highlight NYC-SRV01-CA 4. Right-click and choose from the All Tasks sub-menu, Install CA Certificate…

5. When prompted to Select file to complete CA installation 6. Change the file type in the drop-down list to X.509 Certificate (*.cer) 7. Enter a file name of: \\entry\software\subca.cer 8. Click the Open button 9. A Microsoft Active Directory Certificate Services dialog will display stating Cannot Find the Certificate for CN=LON-SRV01-CA to build a certificate chain. Do you wish to install this certificate now?

10. Click OK 11. When the software share dialog is displayed, navigate to: \\entry\software\lon-srv01-ca.cer 12. Click the Open button – it may take up to a minute for the message below to appear 13. A Microsoft Active Directory Certificate Services message is displayed stating the Root Certificate is untrusted – do you wish to trust the root certificate on this machine to complete the installation.

14. Click OK 15. In the left-hand pane, highlight NYC-SRV01-CA 16. Right-click and from the All Tasks sub menu, select Start Service 17. A Microsoft Active Directory Certificate Services message is displayed, stating The revocation function was unable to check revocation because the revocation server was offline

Page 185 of 229

Essential Communication Security Skills for Polycom Solutions

18. Click the OK button to acknowledge this message

Sub-Task 10.3.1: Download a copy of the Root CA CRL on NYC-SRV01 1. Minimise the Certificate Authority Manager 2. From the Start menu, select Internet Explorer 3. Enter the following URL: http://lon-srv01.medeatalk.com/certsrv 4. At the Welcome screen choose the Download a CA certificate, certificate chain or CRL link 5. If prompted that Internet Explorer blocked an ActiveX control, click the cross to close the dialog 6. When the Download a CA Certificate dialog is displayed, choose a Base 64 encoding method and then click on the Download latest base CRL link 7. When prompted with Do you want to open or save certcrl.crl, choose the Save button 8. When prompted that the certcrl.crl download is completed, click the Open folder button 9. Right-click on the certcrl.crl file and choose the Copy option 10. In the left-hand pane, select Computer 11. Browse to Local Disk (C:) 12. In the Local Disk (C:) dialog, right-click and choose to Paste the file in the right-hand pane 13. Close the Local Disk (C:) dialog 14. Close Internet Explorer

Sub-Task 10.3.2: Install a copy of the Root CA CRL on NYC-SRV01 1. From the Start menu, select Command Prompt 2. Enter the following command: certutil –addstore root c:\certcrl.crl 3. After pressing the <Enter> key on the keyboard, a message should be displayed below stating CRL”CN=LON-SRV01-CA” added to store 4. Close the Command Prompt by typing exit and pressing the <Enter> key

Page 186 of 229

Essential Communication Security Skills for Polycom Solutions

Sub-Task 10.3.3: Retry starting the sub-ordinate CA service on NYCSRV01 1. Restore the Certification Authority manager and in the left-hand pane, highlight NYCSRV01-CA 2. Right-click NYC-SRV01-CA, from the All Tasks sub-menu choose Start Service option â&#x20AC;&#x201C; the service should now successfully start Note: The service will not start until it can establish that the installed certificate has not been revoked. By installing a copy of the current LON-SRV01-CA CRL onto the NYCSRV01 machine, it is possible for the service to establish that the status of the subordinate CA certificate is good.

3. Minimize the Certification Authority manager 4. Minimize the connection to NYC-SRV01 for use in a later lab

Page 187 of 229

Essential Communication Security Skills for Polycom Solutions

Lab 10.4: Place the Root CA in an Off-line State Objectives In this lab, you will place the Root CA machine (i.e. LON-SRV01) in an off-line state.

It is common practice in a Public Key Infrastructure (PKI) to maximize the Root CA security by removing any possibility of attacks from the network and possible compromise.

Note: Additional measures should also be taken with respect to the possibility of physical attack.

Steps 1. Restore the connection to the LON-SRV01 2. From the Start menu, select Control Panel, Network and Sharing Centre 3. Click the Change adapter settings link 4. Right-click on the Local Area Connection entry and select the Disable option Note: The connection to LON-SRV01 will now freeze. After approximately 30 seconds a message will indicate that the connection has been lost.

5. When prompted with the Reconnecting dialog, click Cancel - the connection to LONSRV01 is closed

Sub-Task: 10.4.1: Disable Revocation Check on Subordinate-CA Note: A Windows Server CA will always check revocation on all certificates in the PKI hierarchy before issuing an end-entity certificate. If the Root CA has been taken off-line the revocation check with the Root CA will fail. The following steps disable this check: 1. Restore the connection to the NYC-SRV01 2. From the Start menu, select Command Prompt 3. Enter the following command: certutil â&#x20AC;&#x201C;setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE 4. Verify that the output includes the following message: CertUtil: -setreg command completed successfully.

5. Restore the Certification Authority manager and in the left-hand pane, highlight NYCSRV01-CA 6. Right-click NYC-SRV01-CA, from the All Tasks sub-menu choose the Stop Service option and then Start Service. The service should now successfully start 7. Minimize the connection to NYC-SRV01 for use in a later lab

Page 188 of 229

Essential Communication Security Skills for Polycom Solutions

Lab 10.5: Configure the Sub-Ordinate Certification Authority Objective In this lab, you will re-configure the default sub-ordinate CA settings in order to provide access to Certificate Revocation Lists (CRLs) via the HTTP protocol.

Steps 1. Restore the connection to NYC-SRV01 2. Click Start, Administrative Tools, Certification Authority 3. In the left-hand pane, highlight NYC-SRV01-CA 4. Right-click on the highlighted entry and select the Properties option 5. Select the Extensions tab, ensure the Selected extension drop-down list indicates CRL Distribution Point (CDP) 6. In the Specify locations from which users can obtain a certificate revocation list (CRL) section, highlight the http entry and tick the following settings: ď&#x201A;ˇ

Include in CRLS. Clients use this to find the Delta CRL locations

ď&#x201A;ˇ

Include in the CDP extension of issued certificates

7. Click the Apply button 8. A Certificate Authority dialog appears indicating You must restart Active Directory Certificate Services for the changes to take effect - click the Yes button to restart the service now 9. Click the OK button to close the NYC-SRV01-CA Properties dialog 10. Close the Certification Authority Manager 11. Minimize the NYC-SRV01 connection for use in a later lab

Page 189 of 229

Essential Communication Security Skills for Polycom Solutions

Lab 10.6: Generate a new Certificate Request for the Web Server Objectives In this lab, you will generate a new Certificate Request for the SRV01 Web Server.

This request will be sent to the NYC-SRV01-CA (i.e. the Sub-Ordinate CA) for signing.

Remember: The Root CA (i.e. LON-SRV01-CA) is currently off-line.

Steps 1. Restore the connection to SRV01 2. Click Start, Administrative Tools, Internet Information Services (IIS) Manager 3. In the left-hand pane, select SRV01 4. In the middle pane, double-click Server Certificates icon 5. In the right-hand Actions pane, click the Create Certificate Requestâ&#x20AC;Ś link 6. At the Request Certificate, Distinguished Name Properties dialog, enter the following information: Parameter Common name Organization Organizational unit City/Locality State/Province Country/Region

Value www.medeatalk.com MedeaTalk Corp Training Dallas Texas US

7. Click the Next button 8. In the Cryptographic Service Provider Properties, keep the default settings and click Next 9. In the File Name dialog, Specify a file name for the certificate request and path of: \\entry\software\webcert2.req 10. Click the Finish button 11. Leave the IIS Manager open 12. Minimise the connection to SRV01 for use in a later lab

Page 190 of 229

Essential Communication Security Skills for Polycom Solutions

Lab 10.7: Use the Sub-Ordinate CA to Sign a New Certificate Request for Web Server Objectives In this lab, you will use the Sub-Ordinate CA (i.e. NYC-SRV01-CA) to sign the new certificate request for the SRV01 webserver.

Steps 1. Restore the connection to NYC-SRV01 2. Click Start, Administrative Tools, Certification Authority 3. In the left-hand pane, highlight the NYC-SRV01-CA entry 4. Right-click on the highlighted entry and from the All Tasks sub menu, select Submit New Requestâ&#x20AC;Ś 5. At the Open Request File dialog, enter a file name of: \\entry\software\webcert2.req 6. Click the Open button 7. In the left-hand pane, double click the Pending Requests container 8. In the right-hand pane, highlight the only Pending Request 9. Right-click the highlighted entry, select the All Tasks sub-menu and choose Issue 10. In the left-hand pane, click the Issued Certificates container 11. In the right-hand pane, double-click the only request 12. In the General tab, verify the certificate is Issued to: www.medeatalk.com and Issued by: NYC-SRV01-CA 13. Select the Details tab 14. Click the Copy to Fileâ&#x20AC;Ś button 15. When the Certificate Export Wizard launches, click the Next button 16. At Export File Format dialog, select Base-64 encoded X.509 (.CER) format 17. Click Next 18. At the File to Export dialog, enter the file name of: \\entry\software\webcert2.cer

Page 191 of 229

Essential Communication Security Skills for Polycom Solutions

19. And click on the Next button 20. At the Completing the Certificate Export Wizard dialog, click the Finish button 21. At the Certificate Export Wizard dialog, click OK to acknowledge the export was successful 22. Click OK to close the Certificate dialog 23. Click File, Exit to close the Certification Authority Manager 24. Minimize the NYC-SRV01 connection for use in a later lab

Page 192 of 229

Essential Communication Security Skills for Polycom Solutions

Lab 10.8: Install new Certificate on Web Server and Verify the Configuration Objective In this lab, you will install the newly generated certificate on the SRV01 Web Server.

In addition, you will establish a secure connection to the web server to verify the configuration.

Steps 1. Restore the connection to SRV01 2. Minimize the IIS Manager 3. From the Start menu, choose Internet Explorer and enter the following URL: http://nyc-srv01.medeatalk.com/certsrv 4. When the Welcome dialog is displayed, choose the Download a CA certificate, certificate chain or CRL link 5. When the Download a CA, Certificate Chain or CRL dialog is displayed, choose an Encoding method of Base 64 and click the Download CA certificate link 6. When prompted, choose Save as from the drop-down list next to the Save button 7. Enter a File name of: \\entry\software\nyc-srv01-ca.cer 8. Click the Save button 9. When prompted at the nyc-srv01-ca.cer Download has Completed, close Internet Explorer

Sub-Task 10.8.1: Install sub-ordinate CA (i.e. NYC-SRV01-CA) Certificate on SRV01 1. On SRV01, click Start, Runâ&#x20AC;Ś 2. In the open text box enter the following: \\entry\software 3. Click the OK button 4. When the contents of the software Share are displayed, double-click the NYC-SRV01CA.cer file 5. At the Open File - Security Warning, click Open

Page 193 of 229

Essential Communication Security Skills for Polycom Solutions

6. In the General tab of the Certificate dialog, choose the Install Certificate…

7. When the Certificate Import Wizard is launched, click Next 8. In the Certificate Store dialog, choose Place all certificates in the following store option and click the Browse… button 9. Tick the Show physical stores option 10. Expand the Intermediate Certification Authorities container, choose the Local Computer sub-container and click the OK button 11. Click Next 12. At the Completing the Certificate Import Wizard dialog, click Finish 13. At the Certificate Import Wizard dialog, click OK to acknowledge the import was successful 14. Click OK to close the Certificate dialog 15. Close the software share dialog 16. Restore the IIS Manager 17. In the IIS Manager, highlight SRV01 in the left-hand pane 18. In the middle-pane, open Server Certificates and in the right-hand pane, under Actions click the Complete Certificate Request…

19. When the Specify Certificate Authority Response dialog is displayed, enter a File name containing the certificate authority’s response of: \\entry\software\webcert2.cer 20. In the Friendly name, specify SRV01 Web Server Certificate 2 21. Click the OK button 22. After approximately 30 seconds, the new certificate should be added to the IIS Server Certificates listing in the middle pane 23. In the left-hand pane, expand SRV01, expand Sites and highlight the Default Web Site entry 24. In the right-hand Actions pane, in the Edit Site section, choose the Bindings… link 25. In the Site Bindings dialog, highlight the https entry and click the Edit… button 26. In the SSL Certificate section of the Edit Site Binding dialog, choose SRV01 Web Server Certificate 2 from the drop-down list and click the OK button

Page 194 of 229

Essential Communication Security Skills for Polycom Solutions

27. Click Close in the Site Bindings dialog 28. In the File menu, select Exit to close the IIS Manager 29. Minimize the SRV01 connection for use in a later lab

Sub-Task 10.8.2: Verify the Installation of the Certificate on the Web Server 1. Restore the connection to CLI01 2. Click Start, Internet Explorer and enter the following URL: https://www.medeatalk.com 3. Press the Go To (i.e. green arrow) button 4. Can a secure connection be established without any warnings being displayed? (Yes or No) 5. When the secure connection has been established, click on the padlock icon next to the URL and choose the View Certificates link 6. In the General tab, verify that the certificate was issued by NYC-SRV01-CA and not LON-SRV01-CA 7. Click on the Certification Path tab, and verify that the Certification Path includes the Root CA (i.e. LON-SRV01-CA), the Intermediate CA (i.e. NYC-SRV01-CA) and the Web Server (i.e. www.medeatalk.com) 8. Click OK to close the Certificate dialog 9. Close the Internet Explorer 10. Minimize the CLI01 connection for use in later labs

Page 195 of 229

Essential Communication Security Skills for Polycom Solutions

Lab 10.9: Revoke Web Server Certificate Objectives In this lab, you will revoke the new Web Server certificate using the sub-ordinate CA (i.e. the issuer of the certificate). This procedure would be undertaken under a variety of circumstances; for example, when the web server private key has been compromised (i.e. key compromise).

Steps 1. Restore the NYC-SRV01 connection

Sub-Task 10.9.1: Revoke the Web Server certificate 1. Click Start, Administrative Tools, Certification Authority 2. In the left-hand pane, expand the NYC-SRV01-CA folder 3. In the left-hand pane, highlight the Issued Certificates container 4. In the right-hand pane, double-click the web server Certificate 5. Choose the Details tab and record the Serial Number below: ________________________________ 6. Close the Certificate dialog 7. In the right-hand pane, right-click on the Certificate and from the All Tasks sub-menu, chose the Revoke Certificate option 8. When prompted with the Certificate Revocation dialog, choose a Reason code of Key Compromise Note: there are a number of other reasons for revoking a certificate, including CA compromise, change of affiliation and cease of operation.

9. Keep the default date and time and click the Yes button 10. In the left-hand pane, highlight the Revoked Certificate container and ensure the Certificate is now displayed in the right-hand pane (i.e. it has been revoked)

Sub-Task 10.9.2: Publish a Certificate Revocation List (CRL) 1. In the left-hand pane, right-click the Revoke Certificates container, in the All Tasks submenu, select the Publish option 2. When the Publish CRL dialog is displayed, choose to keep the Type of CRL to publish as New CRL and click OK Note: It is also possible to publish a delta CRL which contains the differences between a full CRL and the current listing only.

Page 196 of 229

Essential Communication Security Skills for Polycom Solutions

3. Close the Certification Authority Manager by clicking File and Exit 4. Minimize the NYC-SRV01 connection for use in a later lab

Sub-Task 10.9.3: Verify the Certificate Revocation is Active 1. Restore the connection to CLI01 2. Click Start, Wireshark 3. From the Edit menu, select Preferences…

4. In the left-hand pane, choose Filter Expressions 5. Click the Add button 6. Enter an Expression of ip.addr==172.16.2.11 7. Press the <Enter> key on the keyboard 8. Double-click on the New Label entry and modify the label to read NYC-SRV01 and press <Enter> on the keyboard 9. In the Preferences – Profile:Default dialog, click OK Note: A new filter button is displayed in the Filter Toolbar called NYC-SRV01.

10. Click the NYC-SRV01 button – the ip.addr==172.16.2.11 should appear in the Filter textbox 11. From the Capture menu, choose the Start option 12. Minimize Wireshark 13. Click Start, Internet Explorer 14. Specify the following URL: https://www.medeatalk.com 15. Press the Go To (i.e. green arrow) button 16. Can a secure connection be established to the Web Server? (Yes or No) 17. Can you suggest why certificate revocation has not worked? _______________________________________________________________________ _________________________________________________________________

Page 197 of 229

Essential Communication Security Skills for Polycom Solutions

Sub-Task 10.9.4: Clear the CRL Cache on CLI01 1. Remain on CLI01 and close Internet Explorer 2. From the Start menu, select Command Prompt 3. In the Command Prompt, <Enter> the following command: certutil â&#x20AC;&#x201C;urlcache * delete Note: This flushes the disk cache and is typically required on Windows XP or Windows Server 2003-based systems. It may be necessary to restart the application or even the computer to ensure the CRL cache has been flushed.

4. Review the output from the command and verify there are no entries for NYC-SRV01-CA or LON-SRV01-CA 5. In the Command Prompt, <Enter> the following command: certutil â&#x20AC;&#x201C;setreg chain\ChainCacheResyncFiletime @now Note: This flushes the memory cache and is the preferred mechanism for Windows Vista and Windows 2008-based systems.

6. Review the command output and note that the Resync File Time has been set to the same date and time as that displayed in the bottom right hand corner of the virtual machine (i.e. the memory cache should be flushed immediately) 7. Enter exit to close the Command Prompt

Sub-Task 10.9.5: Retry the Certificate Revocation Check 1. On CLI01, click Start and select Internet Explorer 2. Enter the following URL: https://www.medeatalk.com 3. Press the Go To (i.e. green arrow) button 4. Are you able to successfully connect to the website securely? (Yes / No) 5. What message is displayed by the web browser? ____________________________________________________________________ 6. Close Internet Explorer 7. Restore the Wireshark dialog 8. In the Capture menu, select Stop

Page 198 of 229

Essential Communication Security Skills for Polycom Solutions

9. In the top packet capture pane, scroll down to find a packet matching the following criteria: Criteria

Value 172.16.2.11 172.16.1.14 PKIX-CRL Certificate Revocation List

Source Destination Protocol Info

10. Highlight the packet in the middle pane, expand the Certificate Revocation List item 11. Expand signedCertificateList 12. Expand revokedCertificates 13. Expand revokedCertificates item 14. Highlight userCertificate 15. Record the value of the Users Certificate below: ____________________________________________________________________ 16. Does this User Certificate serial number match the serial number of the revoked certificate recorded earlier? (Yes/No) 17. From the File menu, choose Quit 18. When prompted, chose Quit without Saving button 19. Minimize the CLI01 connection for use in a later lab

Page 199 of 229

Essential Communication Security Skills for Polycom Solutions

Labs 11 - 14

Labs 11-14 • Lab 11: Configure a Linux-based Web Server to support Secure SSL/TLS Connections • Lab 12: Demonstrate the importance of securing servers and private keys • Lab 13: Configure a Linux-based Web Server to require Mutual SSL/TLS Connections • Lab 14: Configure Various Scenarios on the Apache Web Server for Packet Capture using Wireshark

©

Polycom, Inc. All rights reserved.

30

So far the labs have used Internet Information Server (IIS) running on a Windows 2008 server to illustrate the use of certificates for HTTPS. The following labs will demonstrate:

 

 

Configuration of Apache, running on the Linux operating system to use certificates in order to support secure communication The importance of securing the private key and implementing strong physical security for servers. The lab will demonstrate how access to the private key will allow Wireshark to decrypt secure communication Configuration of mutual authentication in which a client must provide their digital certificate as well as the server Various configuration scenarios on the Apache Web Server using Wireshark to capture and analyze communication.

Page 200 of 229

Essential Communication Security Skills for Polycom Solutions

Lab Figure

Page 201 of 229

Essential Communication Security Skills for Polycom Solutions

Lab 11.1: Configure a Linux-based Web Server to support Secure SSL/TLS Connections Overview In this lab, you will configure an Apache 2.2 web server with a digital certificate to provide secure connections using SSL or TLS. The web server is running on a CentOS 6 operating system installed on the SRV02 machine.

Steps 1. Restore connection to CLI01

Sub-Task 11.1.1: Connect to SRV02 from CLI01 using Putty (i.e. SSH) 1. From the Start menu, select Runâ&#x20AC;Ś 2. In the open text box, insert the following URL \\entry\software 3. Click the OK button 4. When the software share dialog window opens, right-click on the putty.exe file and select the Copy option 5. In the left-hand pane, right-click on the Desktop entry and choose the Paste option 6. Close the software share window 7. Double-click on the putty.exe file located on the CLI01 Desktop 8. In the Host Name (or IP address) textbox enter the following: root@srv02.medeatalk.com 9. Click the Open button 10. When prompted with the PuTTY Security Alert dialog, choose Yes to add the key to the PuTTY cache Note: SSH uses a server authentication mechanism based on RSA Public/Private keys to ensure the client has connected to the correct machine. When a connection is initiated, the server sends a copy of its public key to the client. If the client has not seen the key before, it will prompt the user to verify whether the key belongs to the intended host. The user can verify the key using the fingerprint (i.e. hash) and add the key to the client key cache. Any subsequent connection to the same host should result in the same key being sent to the client otherwise a warning will be displayed.

11. When prompted for a password, enter Polycom!23 â&#x20AC;&#x201C; a remote console on SRV02 should now be established. Tip: no characters will appear when you type the password

Page 202 of 229

Essential Communication Security Skills for Polycom Solutions

Sub-Task 11.1.2: Generate Keypair 1. In the Putty console, enter the following command: openssl genrsa -aes128 -out srv02.key 1024 2. When prompted to Enter pass phrase for server.key specify 1234,press Enter and verify the value when requested. Press Enter

Sub-Task 11.1.3: Generate a Certificate Signing Request (CSR) using the newly created Keypair 1. In the Putty console, enter the following command: openssl req -out srv02.req â&#x20AC;&#x201C;key srv02.key -new 2. When prompted to Enter pass phrase for server.key specify 1234 3. When prompted, specify the following DN values: Field Country Name State or Province Name Locality Name Organization Name Organization Unit Name Common Name Email Address A challenge password

Value US Texas Dallas MedeaTalk Corp Training clients.medeatalk.com

. . .

An optional company name

Tip: to save entering all details a dot (period) can be entered for the last three items.

4. Minimize the Putty console 5. Minimize the connection to CLI01 for use in a later exercise

Sub-Task 11.1.4: Connect to SRV02 from CLI01 using WinSCP (i.e. SSH) Note: the SCP protocol provides secure file copy using SSH. 1. Restore the connection to NYC-SRV01 2. From the Start menu, select Runâ&#x20AC;Ś 3. In the open text box, insert the following URL: \\entry\software 4. Click the OK button

Page 203 of 229

Essential Communication Security Skills for Polycom Solutions

5. When the software share dialog window opens, double-click on the winscp439setup.exe file 6. After several minutes an Open File - Security Warning dialog will be displayed, click the Run button 7. Keep the default language and click OK 8. When the WinSCP Setup Wizard launches, click Next 9. Select the I accept the agreement and click Next 10. Keep the Typical installation (recommended) option and click Next 11. Keep the Commander interface option and click Next 12. Untick the option to Include Google Chrome, along with WinSCP and click Next 13. Click the Install button 14. At the Completing the WinSCP Setup dialog, click the Finish button â&#x20AC;&#x201C; WinSCP should now launch 15. At the WinSCP Login enter the following information: Parameter

Value srv02.medeatalk.com root Polycom!23

Host name User name Password 16. Click the Login button

17. When prompted with a Warning dialog, click the Yes button to trust this host Note: This is the same mechanism discussed earlier for Putty.

Sub-Task 11.1.5: Use NYC-SRV01-CA to Sign Certificate Request 1. In the right-hand pane (i.e. /root ), highlight the srv02.req and drag into the left-hand pane (i.e. My Documents) 2. When prompted with the Copy dialog, click the Copy button 3. Repeat these steps for the srv02.key file 4. Minimize the WinSCP dialog 5. Close the software share window 6. From the Start menu, click Administrative Tools, Certification Authority

Page 204 of 229

Essential Communication Security Skills for Polycom Solutions

7. In the left-hand pane, right-click on NYC-SRV01-CA and from the All Tasks sub-menu, select Submit new request… option 8. In the left-hand pane of the Open Request File dialog, highlight the Documents entry 9. In the right-hand pane of the dialog, highlight the srv02.req file and click the Open button 10. In the left-hand pane, expand NYC-SRV01-CA and select the Pending Requests container 11. In the right-hand pane, right-click on the only request 12. From the All Tasks sub-menu, select Issue Note: If having done this, you get a catastrophic failure, then the following process needs to be undertaken:   

Right click on Revoked Certificates, choose All Tasks and Publish.

Close Certification Authority Dialog by selecting Exit from the File menu Then repeat steps 6-12 above.

13. In the left-hand pane, choose the Issued Certificates container 14. In the right-hand pane, double-click on the new certificate 15. Select the Details tab 16. Click the Copy To File… button at the bottom of the Certificate dialog 17. When the Certificate Export Wizard launches, click the Next button 18. In the Export File Format dialog, choose Base-64 encoded X.509 (.CER) and click the Next button 19. In the File to Export dialog, click the Browse… button 20. In the left-hand pane of the Save As dialog, select the Documents folder 21. In the File name textbox, enter the following: srv02.cer 22. Click Save 23. In the File to Export dialog, click Next 24. At the Completing Certificate Export dialog, verify the File Name and File Formats are correct and click the Finish button 25. Click OK to acknowledge a successful export

Page 205 of 229

Essential Communication Security Skills for Polycom Solutions

26. Click OK to close the Certificate dialog 27. Close the Certification Authority management Interface by selecting Exit from the File menu

Sub-Task 11.1.6: Download CA Certificate Chain 1. On NYC-SRV01, click Start, Internet Explorer 2. Enter the following URL: http://localhost/certsrv 3. At the Welcome screen choose the Download a CA certificate, certificate chain or CRL link 4. If prompted that Internet Explorer blocked an ActiveX control, click the cross to close the dialog. Ignore the message stating that Intranet Settings are off by default.

5. When the Download a CA Certificate dialog is displayed, choose a Base 64 encoding method and then click on the Download CA certificate chain link Note: commands used later in the lab will fail if the Base 64 format is not selected.

6. When prompted with Do you want to open or save certnew.p7b, choose the Save button 7. When prompted that the certnew.p7b download has completed, click the Open folder button 8. Right-click on the certnew.p7b file and choose the Copy option 9. In the left-hand pane, select Documents 10. In the right-hand pane, right-click and choose to Paste 11. Close the Documents dialog 12. Close Internet Explorer

Sub-Task 11.1.7: Install Certificates on Apache Web Server 1. Restore WinSCP 2. In the right-hand pane, press the hide/show directory tree button (see image below):

Page 206 of 229

Essential Communication Security Skills for Polycom Solutions

3. In the right-hand pane, use the directory tree pane to browse to the following directory: /etc/pki/tls/certs/ 4. In the left-hand pane (i.e. C:\Users\Administrator\Documents ), highlight the srv02.cer file and drag into the right-hand bottom pane 5. When the Copy dialog is displayed, click the Copy button 6. Repeat the last two steps for the certnew.p7b file 7. In the right-hand pane, use the directory tree pane to browse to the following directory: /etc/pki/tls/private/ 8. In the left-hand pane (i.e. /root ), highlight the srv02.key file and drag into the righthand bottom pane 9. When the Copy dialog is displayed, click the Copy button 10. Leave WinSCP open for use in the next task

Sub-Task 11.1.8: Upload a Home Page and Favicon for the Web Server 1. In the right-hand pane, use the directory tree pane to browse to the following directory: /var/www/html 2. In the left-hand pane (i.e. My Documents), drag the index.html file into the right-hand bottom pane 3. When prompted with the Copy dialog, click the Copy button 4. Repeat the last two steps for the favicon.ico file 5. Leave WinSCP open for use in the next task

Sub-Task 11.1.9: Re-configure Apache Web Server to use the Certificates 1. In the right-hand pane, use the directory tree pane to browse to the following directory: /etc/httpd/conf.d/ 2. In the right-hand bottom pane, drag the ssl.conf file into the left-hand pane (i.e. My Documents)

Page 207 of 229

Essential Communication Security Skills for Polycom Solutions

Note: This file will be a backup in case the problems are experienced in the next few steps.

3. When prompted with the Copy dialog, click the Copy button 4. In the right-hand bottom pane, right-click the ssl.conf file and choose the Edit option â&#x20AC;&#x201C; a new window displays the contents of this configuration file 5. In this file find the following settings and re-configure to the new settings shown in the table below: Setting Old New

Value #ServerName www.example.com:443 ServerName clients.medeatalk.com:443

Note: This setting ensures the server knows the site name.

6. In this file find the following settings and re-configure to the new settings shown in the table below: Setting Old New

Value SSLCertificateFile /etc/pki/tls/certs/localhost.crt SSLCertificateFile /etc/pki/tls/certs/srv02.cer

Note: This setting indicates the path to the web server certificate.

7. In this file find the following settings and re-configure to the new settings shown in the table below: Setting Old New

Value SSLCertificateKeyFile /etc/pki/tls/private/localhost.key SSLCertificateKeyFile /etc/pki/tls/private/srv02.key

Note: This setting indicates the path to the web server private key.

8. In this file find the following settings and re-configure to the new settings shown in the table below: Setting Old New

Value #SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt SSLCertificateChainFile /etc/pki/tls/certs/ca-chain.cer

Note: This setting indicates the path to the certificates of the CAs present in the web server certificate.

9. In the Edit window, click the Save button (see image below):

10. Close the Edit window 11. Minimize the NYC-SRV01 connection for use in a later exercise

Page 208 of 229

Essential Communication Security Skills for Polycom Solutions

Sub-Task 11.1.10: Generate CA Chain for use by Apache Web Server 1. Restore the CLI01 connection 2. In the Putty console, navigate to the certs/ directory by entering the following command: cd /etc/pki/tls/certs/ 3. In the Putty console, list the contents of the directory by entering the following command: dir 4. Verify that the certnew.p7b file is present 5. Display the P7B file in a PEM format by entering the following command; openssl pkcs7 –in certnew.p7b –print_certs 6. Verify the certificates for both NYC-SRV01-CA and LON-SRV01-CA are displayed 7. Generate a file called ca-chain.cer which contains these CA certificates by entering the following command: openssl pkcs7 –in certnew.p7b –print_certs > ca-chain.cer 8. In the Putty console, list the contents of the directory by entering the following command: dir 9. Verify that the ca-chain.cer file is present 10. Leave the Putty console open for the next exercise

Sub-Task 11.1.11: Restart Apache Web Server to implement configuration changes 1. In the Putty console on CLI01, enter the following command to restart the Apache Web Server: service httpd restart 2. When prompted to Enter pass phrase, enter the pass phrase for the private key of 1234 – the service should display an OK: Pass Phrase Dialog successful message 3. Minimise the Putty console

Sub-Task 11.1.12: Verify a secure connection can be established between CLI01 and SRV02 using SSL/TLS 1. On CLI01, click Start, Wireshark 2. From the Edit menu, select Preferences…

3. In the left-hand pane, choose Filter Expressions 4. Click the Add button 5. Enter an Expression of ip.addr==172.16.1.15 6. Press the <Enter> key on the keyboard 7. Click on the New Label entry and modify the label to read SRV02 and press <Enter> on the keyboard

Page 209 of 229

Essential Communication Security Skills for Polycom Solutions

8. In the Preferences – Profile:Default dialog, click OK Note: A new filter button is displayed in the Filter Toolbar called SRV02.

9. In the Filter toolbar, click the SRV02 button – the ip.addr==172.16.1.15 should appear in the Filter textbox 10. From the Capture menu, choose the Start option 11. Minimise Wireshark 12. Click Start, Internet Explorer 13. Specify the following URL: https://clients.medeatalk.com 14. Press the Go To (i.e. green arrow) button – after ~15s the Welcome to the MedeaTalk Extranet Site should now be displayed 15. Can a secure connection be established to the Web Server? (Yes or No) 16. Minimize Internet Explorer 17. Restore Wireshark 18. From the Capture menu, choose the Stop option 19. In the Packet Capture pane (top pane of the main interface) scroll-up to the top 20. Highlight the packet that matches the following criteria:

Property Source Property Destination Protocol Info

Value 172.16.1.15 172.16.1.14 TLSv1 Server Hello

21. In the middle pane, expand Secure Sockets Layer, TLSv1 Record Layer, Handshake Protocol: Server Hello 22. Enter below what the Web Server selected as the Cipher Suite: _______________________________________________________________ 23. Using the Cipher Suite value, fill in the blanks to complete the following table: Algorithm Type

Algorithm Specified

Asymmetric Symmetric Hashing

Page 210 of 229

Essential Communication Security Skills for Polycom Solutions

24. From the File menu, select Save Asâ&#x20AC;Ś 25. Choose the C:\PacketCaptures folder 26. Enter a File Name of capture2, keep the default Save as type and click the Save button 27. From the File menu, choose Quit 28. Close Internet Explorer 29. Minimize the CLI01 connection dialog for use in a later lab

Page 211 of 229

Essential Communication Security Skills for Polycom Solutions

Lab 12.1: Demonstrate the Importance of Securing Servers and Private Keys Objective In this lab, you will configure Wireshark with a copy of the private key for the SRV01 web server. This allows the Wireshark packet capture tool to decrypt the secure session established between the browser on CLI01 and web server.

Note: These exercises are included to show the importance of preventing unauthorized access to certificates and private keys. If a certificate and private key is exported to provide a backup it is essential that the file is securely stored and that a complex password is used to further protect the private key.

Sub-Task 12.1.1 Install a copy of OpenSSL on to the CLI01 VM 1. Open the CLI01 virtual machine 2. Click Start and choose Runâ&#x20AC;Ś 3. In the open text box, enter the following: \\entry\software 4. Click the OK button 5. When the software share window opens, double-click the vcredist2008_x64.exe 6. When prompted, after a few seconds, with the Open File - Security Warning dialog, click the Run button 7. At the Welcome to Microsoft Visual C++ 2008 Redistributable Setup dialog, click the Next button 8. In the License Terms dialog, tick the I have read and accept the license terms option and click Install 9. After a couple of minutes, the Setup Complete dialog will open, click the Finish button 10. In the software share window, double-click Win64OpenSSL_Light-1_0_0j.exe 11. When prompted with the Open File - Security Warning dialog, click the Run button 12. In the Setup dialogue, click OK to continue and ignore the message regarding Microsoft Visual C++ 2008 Redistributables 13. At the Welcome to OpenSSL Light (64-bit) Setup Wizard dialog, click the Next button

Page 212 of 229

Essential Communication Security Skills for Polycom Solutions

14. At the License Agreement dialog, choose I accept the agreement and click the Next button 15. At the Select Destination Location dialog, keep the default destination and click the Next button 16. At the Select Start Menu Folder, keep the default and click the Next button 17. At the Select Additional Tasks dialog, keep the default setting (i.e. the Windows system directory) and click the Next button 18. At the Ready to Install dialog, click the Install button 19. At the Completing the OpenSSL Light (64-bit) Setup Wizard dialog, choose to remove the tick relating to a One-time $10 donation to Windows OpenSSL and click the Finish button 20. Close the software share window 21. Minimize the connection to CLI01 for use in a later lab

Sub-Task 12.1.2: Transfer a copy of the Web Server Private Key to CLI01 1. Restore the connection to the NYC-SRV01 machine 2. Click the Start button and choose Computer 3. In the left-hand pane, click the Documents folder 4. In the right-hand pane, right-click on the srv02.key file and choose the Copy option 5. Click the Start button and choose Runâ&#x20AC;Ś 6. Enter the following path: \\entry\software 7. Click the OK button 8. In the left-hand pane, right-click and Paste the srv02.key file in to this folder 9. Minimize the connection to NYC-SRV01 for use in a later exercise

Sub-Task 12.1.3: Remove the Pass Phrase from the Web Server Private Key 1. On CLI01, click the Start button and choose Runâ&#x20AC;Ś

Page 213 of 229

Essential Communication Security Skills for Polycom Solutions

2. Enter the following path: \\entry\software 3. Right-click on the srv02.key file and choose the Copy option 4. In the left-hand pane, select Computer and locate the following path: C:\OpenSSL-Win64\bin 5. In the right-hand pane, right-click and Paste the srv02.key file into this folder 6. Close the bin folder window 7. Click Start and select Command Prompt 8. Type the following command: cd \openssl-win64\bin 9. Press the <Enter> key on the keyboard and verify the path has changed to: C:\OpenSSL-Win64\bin 10. In the Command Prompt, <Enter> the following command: type srv02.key 11. Verify that the command output indicates that the private key is ENCRYPTED using AES-128-CBC 12. In the Command Prompt, <Enter> the following command: set OPENSSL_CONF=c:\OpenSSL-Win64\bin\openssl.cfg Note: This command tells OpenSSL where to locate its configuration file (i.e. openssl.cfg) otherwise it generates error messages regarding a missing config file.

13. In the Command Prompt, <Enter> the following command: openssl rsa -in srv02.key -out srv02.key.pem Note: This command converts the private key from an encrypted format to PEM format which uses Base64 encoding. Encoding does not provide security as it can be decoded without requiring a key. Note that the passphrase is required in order to convert the key.

14. When prompted, Enter Pass Phrase of 1234 and press the <Enter> key 15. A writing RSA key message should be displayed to indicate a successful conversion 16. Enter the following command: type srv02.key.pem 17. Verify the RSA Private key is displayed 18. Verify that the command output indicates that the private key is no longer encrypted (i.e. the Proc-Type and DEK-info headers are no longer present)

Page 214 of 229

Essential Communication Security Skills for Polycom Solutions

19. In the Command Prompt, enter exit – the Command Prompt closes

Sub-Task 12.1.4: Use the Web Server Private Key in Wireshark to decrypt the secure connection 1. On CLI01 VM, click Start, Wireshark 2. When Wireshark has launched, click the Edit menu and select Preferences…

3. In the left-hand pane, expand the Protocols entry 4. Scroll-down and highlight the SSL entry 5. In the right-hand pane, click the Edit… button to show the RSA keys list 6. When the dialog opens, click the New button and specify the following information: Parameter Value IP address 172.16.1.15 Port 443 Protocol http Key File C:\openssl-win64\bin\srv02.key.pem Password <blank> Note: Click on the highlighted area (see figure below) in order to browse to the Key File path specified in the table above. Once the path has been selected only the srv01.key.pem file name is displayed in the Key File entry.

7. Click the OK button 8. Click OK again on the SSL Decrypt – Profile Default dialog 9. Click OK again at the Wireshark: Preferences – Profile Default dialog 10. From the File menu, click the Open… option 11. Browse to c:\packetcaptures 12. Highlight capture2.pcapng and click the Open button 13. In the Filter toolbar, click the SRV02 button – the ip.addr==172.16.1.15 filter is now displayed in green 14. In the packet capture pane (i.e. top pane of the main interface), scroll-down to the find a packet matching the following criteria:

Page 215 of 229

Essential Communication Security Skills for Polycom Solutions

Parameter

Value 172.16.1.15 172.16.1.14 HTTP HTTP/1.1 200 OK (text/html)

Source Destination Protocol Info 15. Highlight the packet

16. In the middle pane, expand the Secure Sockets Layer section 17. Expand the TLSv1 Record Layer: Application Data Protocol: http and review the encrypted application data Note: Without the Private Key, even this layer would be inaccessible to a packet capture tool such as Wireshark.

18. Expand the Hypertext Transfer Protocol and Line-based text data sections to verify that the home page text (i.e. index.html) has been decrypted and can now be viewed in plaintext Note: A second connection is established to request the favicon.ico image file.

19. From the File menu, select the Quit option 20. Close Internet Explorer 21. Minimize the CLI01 connection dialog for use in a later lab

Page 216 of 229

Essential Communication Security Skills for Polycom Solutions

Lab 13.1: Configure a Linux-based Web Server to require Mutual SSL/TLS Connections Overview In this lab, you will configure the re-configure the Apache Web Server to require a mutual TLS connection (i.e. both the Web Server and Web Browser must supply certificates for authentication purposes).

Steps Sub-Task 13.1.1: Re-configure Apache Web Server to require Mutual Authentication 1. Restore the connection to NYC-SRV01 2. In the right-hand pane of WinSCP, use the directory tree pane to browse to the following directory: /etc/httpd/conf.d/ 3. In the right-hand bottom pane, right-click the ssl.conf file and choose the Edit option â&#x20AC;&#x201C; a new window displays the contents of this configuration file 4. In this file find the following settings and re-configure to the new settings shown in the table below: Setting Old New

Value #SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt SSLCACertificateFile /etc/pki/tls/certs/ca-chain.cer

Note: This setting indicates the path to the file containing trusted CA certificates for client authentication.

5. In this file find the following settings and re-configure to the new settings shown in the table below: Setting Old New

Value #SSLVerifyClient require SSLVerifyClient require

Note: This setting specifies that mutual authentication is mandatory.

6. In this file find the following settings and re-configure to the new settings shown in the table below: Setting Old New

Value #SSLVerifyDepth 10 SSLVerifyDepth 3

Note: This setting specifies the maximum number of levels which the web server will check in the received certificate path before resolving that the certificate is invalid.

7. In the Edit window, click the Save button (see image below):

8. Close the Edit window

Page 217 of 229

Essential Communication Security Skills for Polycom Solutions

9. Minimize the NYC-SRV01 connection for use in a later exercise

Sub-Task 13.1.2: Restart Apache Web Server to implement configuration changes 1. Restore the connection to CLI01 2. In the Putty console, enter the following command to restart the Apache Web Server: service httpd restart 3. When prompted to Enter pass phrase, enter the pass phrase for the private key of 1234 â&#x20AC;&#x201C; the service should display an OK message 4. Minimise the Putty console

Sub-Task 13.1.3: Attempt Secure Connection to the Web Site and Review Wireshark Trace 1. Click Start, Wireshark 2. In the Filter toolbar, click the SRV02 button â&#x20AC;&#x201C; the ip.addr==172.16.1.15 should appear in the Filter textbox 3. From the Capture menu, choose the Start option 4. Minimise Wireshark 5. Click Start, Internet Explorer 6. Specify the following URL: https://clients.medeatalk.com 7.

Press the Go To (i.e. green arrow) button

8. Can a secure connection be established to the Web Server? (Yes or No) 9. Minimize Internet Explorer 10. Restore Wireshark 11. From the Capture menu, select the Stop option 12. In the packet capture pane (i.e. top pane of the main interface), scroll-down to the find a packet matching the following criteria: Parameter Source Destination Protocol Info

Value 172.16.1.15 172.16.1.14 TLSv1 Certificate, Certificate Request, Server Hello Done

Page 218 of 229

Essential Communication Security Skills for Polycom Solutions

Note: depending on the conf 13. Highlight the packet 14. In the middle pane, expand the Secure Sockets Layer section 15. Expand the TLSv1 Record Layer: Handshake Protocol: Multiple Handshake Messages 16. Expand Handshake Protocol: Certificate Request 17. Expand Distinguished Names 18. Record the Distinguished Names of the CAs supported by the Web Server for authentication below: _____________________________ & ____________________________ 19. In the packet capture pane (i.e. top pane of the main interface), scroll-down to the find a packet matching the following criteria: Parameter

Value 172.16.1.15 172.16.1.14 TLSv1 Alert (Level: Fatal, Description: Handshake Failure)

Source Destination Protocol Info

20. Specify below why the fatal alert has been generated? _______________________________________________________________________ 21. From the File menu, select Quit 22. When prompted, choose the Quit without Saving button 23. Close Internet Explorer

Sub-Task 13.1.4: Generate a Client Authentication Certificate 1. On CLI01, click Start, Runâ&#x20AC;Ś 2. In the open textbox, enter the command: mmc 3. Click OK 4. From the File menu, select Add/Remove Snap-inâ&#x20AC;Ś

Page 219 of 229

Essential Communication Security Skills for Polycom Solutions

5. In the Available snap-ins pane (left-hand side), highlight the Certificates entry and click the Add > button 6. When Certificates snap-in dialog is displayed, keep the My user account option and click the Finish button 7. Click OK to close the Add or Remove Snap-ins dialog 8. In the left-hand pane, expand the Certificates container 9. In the left-hand pane, right-click on the Personal item, from the All Tasks sub-menu, select the Advanced Operations sub-menu and select the Create Custom Requestâ&#x20AC;Ś 10. At the Before You Begin dialog, click the Next button 11. At the Select Certificate Enrollment Policy dialog, highlight the Proceed without enrollment policy and click Next Note: certificate enrollment policies may be used as part of an enterprise PKI to configure rights to apply for certificates and the properties of the certificates. The following steps illustrate configuration that could be applied using policies and certificate templates.

12. At the Custom request dialog, keep the default settings and click Next 13. At the Certificate Information dialog, expand the Details section (see image below):

14. Click the Properties button 15. In the General tab, specify a Friendly name of Student One 16. Click the Subject tab 17. In the Subject name section, specify a Type of Common Name from the drop-down list and a Value of Student One 18. Click the Add > button 19. Click the Extensions tab 20. Expand the Key usage section and select the following options: ď&#x201A;ˇ

Data encipherment

Page 220 of 229

Essential Communication Security Skills for Polycom Solutions

 Digital Signature  Key encipherment  Non repudiation 21. Expand the Extended Key Usage (application policies) section and select Client Authentication 22. Click OK for the Certificate Properties dialog 23. At the Certificate Information dialog, click the Next button 24. At the Where do you want to save the offline request? dialog, specify a File Name of: \\entry\software\studentone.req 25. Click the Finish button 26. Leave the Console1 dialog open for use in a later exercise 27. Minimize the connection to CLI01

Sub-Task 13.1.5: Sign Client Authentication Request on Sub-Ordinate CA 1. Restore the connection to NYC-SRV01 2. Click Start, Administrative Tools, Certification Authority 3. In the left-hand pane, highlight the NYC-SRV01-CA entry 4. Right-click on the highlighted entry and from the All Tasks sub menu, select Submit New Request…

5. At the Open Request File dialog, enter a file name of: \\entry\software\studentone.req 6. Click the Open button 7. In the left-hand pane expand NYC-SRV01-CA and navigate to the Pending Requests container 8. In the right-hand pane, highlight the latest (or only) Pending Request 9. Right-click the highlighted entry, select the All Tasks sub-menu and choose Issue 10. In the left-hand pane, click the Issued Certificates container 11. In the right-hand pane, double-click the only request 12. In the General tab, verify the certificate is Issued to: Student One and Issued by: NYCSRV01-CA

Page 221 of 229

Essential Communication Security Skills for Polycom Solutions

13. Select the Details tab 14. Click the Copy to Fileâ&#x20AC;Ś button 15. When the Certificate Export Wizard launches, click the Next button 16. At Export File Format dialog, select Base-64 encoded X.509 (.CER) format 17. Click Next 18. At the File to Export dialog, enter the file name of: \\entry\software\studentone.cer 19. And click on the Next button 20. At the Completing the Certificate Export Wizard dialog, click the Finish button 21. At the Certificate Export Wizard dialog, click OK to acknowledge the export was successful 22. Click OK to close the Certificate dialog 23. Click File, Exit to close the Certification Authority Manager 24. Minimize the NYC-SRV01 connection for use in a later lab

Sub-Task 13.1.6: Configure Web Browser with a Client Authentication Certificate 1. Restore connection to CLI01 2. Restore Console1, right-click the Personal sub-container below the Certificates container, select the All Tasks sub-menu and choose the Importâ&#x20AC;Ś option 3. At the Welcome to Certificate Import dialog, click Next 4. In the File name textbox specify the following: \\entry\software\studentone.cer 5. Click Next 6. In the Certificate Store dialog, keep the default setting (i.e. Personal) and click the Next button 7. At the Completing the Certificate Import dialog, click the Finish button 8. Click OK to acknowledge a successful import

Page 222 of 229

Essential Communication Security Skills for Polycom Solutions

9. In the left-hand pane, expand the Personal container and highlight the Certificates subcontainer 10. In the right-hand pane, double-click the Student One entry – after ~30s the Certificate dialog opens 11. In the General tab, determine whether the Certificate has a corresponding private key?

(Yes/No) 12. Record why is it important that there is a private key which corresponds to the certificate? _______________________________________________________________________ 13. Record the error message shown in the Certificate Information section below: _______________________________________________________________________ 14. How should this issue be rectified? _______________________________________________________________________ 15. In the Console1 dialog, right-click on the Intermediate Certificate Authorities and from the All Tasks sub-menu, select the Import… option 16. At the Welcome to Certificate Import dialog, click Next 17. In the File name textbox specify the following: \\entry\software\nyc-srv01-ca.cer 18. Click Next 19. In the Certificate Store dialog, click the Browse… button 20. Tick the Show physical stores option 21. Expand the Intermediate Certificate Authorities store and select the Local Computer item 22. Click OK 23. In the Certificate Import Wizard dialog, click the Next button 24. At the Completing the Certificate Import dialog, click the Finish button 25. Click OK to acknowledge a successful import 26. In the left-hand pane, expand the Personal container and highlight the Certificates subcontainer 27. In the right-hand pane, double-click the Student One entry – after ~30s the Certificate dialog opens

Page 223 of 229

Essential Communication Security Skills for Polycom Solutions

28. In the General tab, does the Certificate Information section still show an error message? (Yes/No) 29. View the information shown in the Certification Path tab 30. Click OK to close Certificate dialog 31. Minimize Console1

Sub-Task 13.1.7: Re-attempt Secure Connection to the Web Site and Review Wireshark Trace 1. On CLI01, click Start, Wireshark 2. In the Filter toolbar, click the SRV02 button â&#x20AC;&#x201C; the ip.addr==172.16.1.15 should appear in the Filter textbox 3. From the Capture menu, choose the Start option 4. Minimize Wireshark 5. Click Start, Internet Explorer 6. Specify the following URL: https://clients.medeatalk.com 7.

Press the Go To (i.e. green arrow) button - after ~30s a Windows Security prompt will be displayed requesting a Confirm Certificate

8. Verify the dialog shows a certificate for Student One which was issued by NYC-SRV01CA and click the OK button 9. Can a secure connection be established to the Web Server? (Yes or No) 10. Minimize Internet Explorer 11. Restore Wireshark 12. From the Capture menu, select the Stop option 13. In the packet capture pane (i.e. top pane of the main interface), scroll-down to the find a packet matching the following criteria: Parameter Source Destination Protocol Info

Value 172.16.1.14 172.16.1.15 TLSv1 Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec,

Page 224 of 229

Essential Communication Security Skills for Polycom Solutions

Finished 14. Highlight the packet 15. In the middle pane, expand the Secure Sockets Layer section 16. Expand the TLSv1 Record Layer: Handshake Protocol: Multiple Handshake Messages 17. Expand Handshake Protocol: Certificate 18. Expand Certificates 19. Record which Certificates are sent by the Web Client to the Web Server below: _____________________________ & ____________________________ 20. From the File menu, select Quit 21. When prompted, choose the Quit without Saving button 22. Close Internet Explorer

Page 225 of 229

Essential Communication Security Skills for Polycom Solutions

Lab 14.1: Scenarios on the Apache Web Server for Packet Capture using Wireshark Overview In these labs, you will be given minimal information to configure the scenario, although, we have covered appropriate techniques in previous labs. You will be expected to use Wireshark to capture the session and then answer questions based on the trace.

Steps Sub-Task 14.1.1: Disable Mutual Authentication 1. Restore the connection to CLI01 2. In WinSCP, in the top right-pane navigate to the following location: /etc/httpd/conf.d/ 3. In the bottom right-pane, right-click on the ssl.conf file and select the Edit option 4. In this file find the following settings and re-configure to the new settings shown in the table below: Setting Old New

Value SSLCACertificateFile /etc/pki/tls/certs/ca-chain.cer #SSLCACertificateFile /etc/pki/tls/certs/ca-chain.cer

5. In this file find the following settings and re-configure to the new settings shown in the table below: Setting Old New

Value SSLVerifyClient require #SSLVerifyClient require

6. In this file find the following settings and re-configure to the new settings shown in the table below: Setting Old New

Value SSLVerifyDepth 3 #SSLVerifyDepth 3

7. In the Edit window, click the Save button (see image below):

8. Close the Edit window 9. Restart the Apache Web Server as described in Sub-Task 11.1.11 10. Use a Wireshark trace to verify that mutual authentication has been disabled successfully when using the CLI01 browser to connect to https://clients.medeatalk.com

Page 226 of 229

Essential Communication Security Skills for Polycom Solutions

11. Record below which three Handshake events are not used when only the Web Server provides authentication? __________________________________________________________ __________________________________________________________ _______________________

Sub-Task 14.1.2: Re-configure the Web Browser on CLI01 to force a connection with SSLv3 1. Restore the connection on CLI01 2. Click Start, Control Panel 3. Single-click on Internet Options 4. Select the Advanced tab 5. Scroll-down to the Security section (i.e. at the bottom) and ensure that the only SSL or TLS protocol enabled is SSL 3.0 6. Click OK 7. Close Control Panel 8. Perform a packet capture of CLI01 Web Browser connection to https://clients.medeatalk.com 9. Which Cipher Suite is selected by the Web Server for the session? _______________________________________________________________________ 10. Which symmetric algorithm is used instead of AES-128? _________ 11. Using the steps above, modify the Web Browser settings again so that only SSL 2.0 is enabled.

12. Perform a packet capture of CLI01 Web Browser connection to https://clients.medeatalk.com 13. Can a secure connection be established? (Yes/No) 14. Analyze the packet capture to try and determine the issue and record your answer below: _______________________________________________________________________ 15. Record which Cipher Suites are offered by the Web Browser when configured for SSL 2.0 only: _________________________________ _________________________________ _________________________________

Page 227 of 229

Essential Communication Security Skills for Polycom Solutions

16. Using the steps above, modify the Web Browser settings again to enable SSL 3.0 and TLS 1.0 only 17. Verify a secure connection can successfully be established following this re-configuration

Sub-Task 14.1.3: Modify the Apache Web Server configuration and review the results 1. Restore the connection to NYC-SRV01 2. In WinSCP, in the top right-pane navigate to the following location: /etc/httpd/conf.d/ 3. In the bottom right-pane, right-click on the ssl.conf file and select the Edit option 4. In this file find the following settings and re-configure to the new settings shown in the table below: Setting Old New

Value ServerName clients.medeatalk.com:443 #ServerName clients.medeatalk.com:443

5. In the Edit window, click the Save button (see image below):

6. Close the Edit window 7. Restart the Apache Web Server as described in Sub-Task 4.1.11 8. Perform a packet capture of CLI01 Web Browser connection to https://clients.medeatalk.com 9. Can a secure connection be established? (Yes/No) 10. Analyze the packet capture and record the description of any alert generated below: _______________________________________________________________________ 11. Explain what this alert means below? _______________________________________________________________________

Page 228 of 229

Essential Communication Security Skills for Polycom Solutions

Congratulations you have now completed the training.

Please return to Polycom University to complete the Assessment.

For assistance please contact PolcomU@Polycom.com

Page 229 of 229