CCVP Prep: Cryptography in Cisco Unified Communications: BRKCRT-2202

CCVP Prep:
Cryptography in Cisco
Unified Communications
BRKCRT-2202
BRKCRT-2202
14370_04_2008_c1 © 2008 Cisco Systems, Inc. All rights reserved. Cisco Public 2
© 2008, Cisco Systems, Inc. All rights reserved. 1

14370_04_2008_c1.scr
What Is Covered by This Session?
Impossible to cover all topics about voice security in a

two hour session
Session helps to prepare for current CCVP exam
questions that relate to Cisco Unified Communications
Manager security
Intended for CCVP candidates lacking security
experience
Cisco Unified Communications Manager knowledge
is expected
BRKCRT-2202
Agenda
Threats to Cisco Unified Communications

Introduction to Cryptography
Cisco Unified Communications Manager Security
Summary
Q&A
BRKCRT-2202

14370_04_2008_c1.scr
Threats to
Cisco Unified
Communications
BRKCRT-2202
Examples of Threats Targeting

the IP Telephony System
Loss of Privacy Loss of Integrity
Deposit Deposit
$1000 $100
Confidential Information
Customer Bank
Impersonation Denial of Service
Loss
I am Bob, of Dial
send me Tone
I am the PSTN, phone calls.
send me calls.
BRKCRT-2202

14370_04_2008_c1.scr
Introduction to
Cryptography
Symmetric vs. Asymmetric Encryption
BRKCRT-2202
Symmetric Encryption
Encryption and Encryption and
Decryption Key Decryption Key
Encrypt Decrypt
$1000 $!@#IQ $1000
Same (“shared”) key encrypts and decrypts

Key must be kept secret (sender and receiver)
Fast
Algorithms: DES, 3DES, AES, RC4, SEAL, Blowfish, etc.
BRKCRT-2202

14370_04_2008_c1.scr
Symmetric Encryption (Cont.)
Key Management
Different key for each pair of devices
Keys should be changed frequently (hours to weeks)
Same key must be known by both parties
Usage
Bulk Data Encryption (e-mail, IPsec packets, sRTP, HTTPS, TLS)
Algorithm Example—AES
Publicly announced by NIST in 2000
Much faster and more efficient than DES/3DES
Used to encrypt signaling (TLS) and media (sRTP)
BRKCRT-2202
Asymmetric Encryption
Encryption Decryption
Key Key
Encrypt Decrypt
$1000 %3f7&4 $1000
Based on key pairs: data encrypted by one key can only be

decrypted by other key
Each entity owns its pair of keys
Only one key (decryption key) must be kept secret
Slow
Algorithm: RSA
BRKCRT-2202

14370_04_2008_c1.scr
Asymmetric Encryption (Cont.)
Key Management
Different key pair for each entity
Keys can be used for longer periods (months to years)
One key must remain secret (“private key”), the other key must
be known by other entities (“public key”)
Usage
Low Volume Data (symmetric keys)
Algorithm Example—RSA
Developed in 1977, public domain since patent expired in 2000
BRKCRT-2202
Two Ways to Use

Confidentiality
Sender encrypts data with public key of the receiver
Any sender can generate encrypted message
Senders need to know public key of receiver
Only receiver can decrypt encrypted data
Only receiver knows its corresponding private key
Authenticity and Integrity
Sender encrypts data with its own private key
Only sender can generate encrypted (signed) message
Only sender knows its private key
All receivers can decrypt encrypted (signed) message
All receivers need to know corresponding public key of sender
BRKCRT-2202

14370_04_2008_c1.scr
Introduction to
Cryptography
Hash-Based Message Authentication Codes (HMAC)
BRKCRT-2202
Hash Functions
One-way functions
Message
Generate fixed-length Data of ~~~~~~~~~~~~~~
Arbitrary ~~~~~~~~~~~~
output (“hash”, “digest” or ~~~~~~~~~~~
Length
“fingerprint”) from arbitrary ~~~~~~~~~~~~~
input data
Impossible to recover Hash
Function
hashed data from digest
Collisions (multiple inputs
result in same hash
output) possible
Fast Fixed-Length
e883aa0b24c09...
Algorithms: MD5, SHA-1 Hash
BRKCRT-2202

14370_04_2008_c1.scr
No Integrity Provided by Pure Hashing
Only the algorithm has
to be known to create a Data
valid hash—algorithms Confirm

are well known. Order
Attacker changing the

data can easily create Confirm Hashing
a new hash. Order Algorithm
e8F0s31a...
Receiver cannot detect Hashing
Algorithm
the manipulation. e8F0s31a...
Same Hash
For security, a secret e8F0s31a...
Digest?
element has to be added Hash Digest
to the computation.
BRKCRT-2202
Hash-Based Message Authentication

Code or “Keyed Hash”
Secret key added to provide
authenticity and integrity:
Sender creates hash value from
input data plus locally known key Data
Sender transmits data plus hash Confirm Secret Key

Order
Receiver creates hash from received
data plus locally known key
Locally created hash must match Confirm Hashing
Secret Key
received one Order Algorithm
Symmetric Key Nature Hashing

bff6f12a0…
Different key for each pair of devices Algorithm

bff6f12a0…
Keys should be changed frequently bff6f12a0… HMAC
(hours to weeks) HMAC Verified
(Authenticated
Same key must be known by Fingerprint)
both parties
Used for bulk data (IPsec

packets, HTTPS, TLS, sRTP)
BRKCRT-2202

14370_04_2008_c1.scr
Introduction to
Cryptography
Digital Signatures
BRKCRT-2202
Digital Signatures
Provide authenticity, integrity and non-repudiation

Based on asymmetric cryptographic methods
Sender’s private key used as signature-generating key
Sender’s public key used as signature-verification key
Slower than HMAC

Not used for bulk or real-time traffic
Used for device authentication and exchange
of symmetric keys
BRKCRT-2202

14370_04_2008_c1.scr
Digital Signatures (Cont.)
Purchase Order
$100,000
SHA-1 Hash
Untrusted Network
49eD0e3A7c44...
Purchase Order Purchase Order
$100,000 $100,000
RSA Signature
e10d6200aCe...
Encrypt
RSA
SHA-1 Hash
Decrypt
Private Key Public Key
of Signer of Signer 49eD0e3A7c44...
Same Hash Digest?
BRKCRT-2202
Introduction to
Cryptography
Public Key Infrastructure (PKI)
BRKCRT-2202

14370_04_2008_c1.scr
Key Distribution Issues
Symmetric Keys used by Symmetric Encryption

and HMAC
Frequent key exchange between peers is needed
Confidentiality and authenticity are required for key exchange
Out-of-band exchange does not scale
Public Keys used by Asymmetric Encryption and

Digital Signatures
Public keys need to be distributed to all devices
Authenticity and integrity are required for key exchange
Out-of-band verification or exchange do not scale
BRKCRT-2202
Symmetric Key Distribution Protected by

AES Key AES Key
A RSA RSA B
Public Key Private Key

of User B of User B
Symmetric key is generated by one peer

Key is encrypted with the public key of the receiver and sent over
the network
Only the receiver can decrypt the message by using its private key
Allows secure automated key distribution of symmetric keys
Relies on knowledge of public keys of all possible peers
BRKCRT-2202

14370_04_2008_c1.scr
Public Key Distribution in
Asymmetric Cryptography
All entities have to know public
keys of all other entities.
If automated key exchange is
used, authenticity and integrity
must be provided to avoid
man-in-the-middle attacks
Out-of-band verification does Public Key
of User A
not scale
PKI can be used to solve Public Key
of User B
scalability issues A B
BRKCRT-2202
PKI as a Trusted Third-Party Protocol
Does not eliminate the need for authenticity and

integrity of public keys (out-of-band verification)
Solves scalability issues
Uses a hierarchical model by adding a trusted introducer
Authenticity and integrity (out-of-band verification) only required
between trusted introducer and each entity
Authenticity and integrity between entities are then guaranteed
by trusted introducer (no out-of-band verification required)
Trusted introducer will then guarantee authenticity and integrity
of public keys of other entities by use of certificates, signed by
the introducer
BRKCRT-2202

14370_04_2008_c1.scr
PKI—Generating Key Pairs
Trusted
Introducer

of Trusted of Trusted
Introducer Introducer
Public Key Public Key

of User A of User C
Private Key Private Key

A of User A of User C C
Every entity, including the trusted introducer, needs to generate

its own public and private key pair
BRKCRT-2202
PKI—Distribution of the Public Key

of the Trusted Introducer
Trusted
Introducer


of User A of User C
Private Key Public Key Public Key Private Key

A of User A of Trusted of Trusted of User C C
Each entity obtains the public key of the trusted introducer and
verifies its authenticity and integrity (out-of-band)
BRKCRT-2202

14370_04_2008_c1.scr
PKI—Requesting Signed Certificates
of User A Trusted of User C
Introducer


of User A of User C

Each entity submits its public key to the trusted introducer and
requests a certificate
BRKCRT-2202
PKI—Signing Certificates
A
Public Key
of User A Content
Trusted
Introducer
Sign
RSA
Public Key
of User A
Public Key
Trusted of Trusted Signing Public Key of User A
Introducer Key Signed by the
Introducer
Trusted Introducer
Private Key
of Trusted
Introducer
The trusted introducer verifies the received public key (out-of-band) and
creates a certificate signed with the trusted introducer’s private key
BRKCRT-2202

14370_04_2008_c1.scr
PKI—Providing Entities with
Their Certificates
Trusted
Introducer

Trusted Trusted

of User A Public Key Public Key of User C
of User A of User C

The trusted introducer sends signed certificates to the entities
BRKCRT-2202
PKI—Exchange of Public Keys Between

Entities Using Their Signed Certificates
Trusted Trusted
Public Key Public Key Public Key Public Key

of User A of User A of User C of User C
Untrusted Network
Entities can now exchange their public keys by means of their

signed certificates
Signature of a received certificate is verified using the public key of
the trusted introducer. This ensures the authenticity and integrity of
the peer’s public key
BRKCRT-2202

14370_04_2008_c1.scr
PKI Entities
Term Function
CA (Certificate The trusted introducer signing certificates of PKI entities
Authority) (PKI users)
PKI Users Devices, users, or applications that want to safely
distribute their public keys
Certificates Digital form (X.509v3) including the identity of a PKI
user, its public key, and a signature (created by the CA)
Self-signed Sometimes entities issue self-signed certificates:

Certificates CA, as the root of a PKI
Entities that are not part of a PKI (not associated with a CA)
but use PKI-enabled applications
Require out-of-band verification
BRKCRT-2202
X.509v3 Certificates
Certificate Format Version Version 3

Certificate Serial Number 12457801
Signature Algorithm Identifier
RSA with SHA-1
for CA
Issuer X.500 Name C = US O = Cisco CN = CA
Start = 04/01/04
Validity Period
Expire = 04/01/09
C = US O = Cisco CN =
Subject X.500 Name
CCMCluster001
Subject Public Key Information 756ECE0C9ADC7140...
Extension(s) (v3)
CA Signature 2C086C7FE0B6E90DA396AB…
BRKCRT-2202

14370_04_2008_c1.scr
Introduction to
Cryptography
PKI Example: SSL in the Internet
BRKCRT-2202
Internet Web Server Certificate
Used for sensitive web Internet-CA

applications
The web server has a Private Key of
private and public key Internet-CA
The web server has a

certificate, usually issued Web Server
by a public Internet-CA
Internet-CA
Public Key of
Web Server
Public Key of
Web Server
Private Key of
Web Server
BRKCRT-2202

14370_04_2008_c1.scr
Internet Web Browser: Embedded
Internet-CA Certificates
Web browser applications have Internet-CA certificates already

embedded (100+)
Eliminates the need to download and verify the Internet-CA’s
certificate
BRKCRT-2202
Obtaining Authentic Public Key

of Web Server
Web Browser Web Server
Internet-CA
Public Key of
Internet-CA
Verify
Signature
Internet-CA Internet-CA Public Key of

Web Server
Internet
Public Key of Public Key of Public Key of Private Key of

Web Server Web Server Web Server Web Server
The server passes its certificate to the client at connection startup

The client verifies the certificate using the embedded certificate of the
Internet-CA that has issued the certificate of the web server
The client extracts the public key of the web server from the certificate
BRKCRT-2202

14370_04_2008_c1.scr
Web Server Authentication
Random String Sign

Challenge
Rj@as94iDg... RSA
Internet Private Key of

Web Server
RSA p2CksD1f3r...
Response
Public Key of
Web Server
Rj@as94iDg...
The client sends challenge with random data to the web server
The web server uses its private key to sign the data and sends it back to the client
The client verifies the returned data using the public key of the web server
previously retrieved from the certificate
If returned data matches the sent data, the web server has the correct private key,
and therefore it is authentic
BRKCRT-2202
Exchange of Symmetric Session Keys

Generate
Session Keys
ke4P6d23Le... RSA
Session Keys
Internet Private Key of
Web Server
RSA
Session Keys
Public Key of
Web Server
The client generates symmetric session keys for encryption and HMAC algorithms
to provide session protection
The client encrypts the keys using the public key of the web server and sends them
to the web server
The web server (only) can decrypt the session keys using its private key
BRKCRT-2202

14370_04_2008_c1.scr
Session Encryption
Data from
Browser Data from
Browser
AES
Ss199le4... AES
Session Keys
Session Keys
Internet
Data from
AES
Server
Data from
AES dV46ax7...
Server
Packets between web server and client can now be authenticated (using HMAC,
such as keyed SHA-1) and encrypted (using symmetric encryption algorithms such
as AES)
BRKCRT-2202
Cisco Unified
Communications
Manager Security
PKI Topologies Used in Cisco Unified Communications
BRKCRT-2202

14370_04_2008_c1.scr
PKI Topologies in Cisco Unified
Communications Manager Deployments
Cisco Unified Communication Manager services

certificates are self-signed: CCM, TFTP and
Certificate Authority Proxy Function (CAPF)
Manufacturing Installed Certificates (MICs) on
current Cisco Unified models are signed by
Cisco manufacturing CA
Locally Significant Certificates (LSCs) on 7940,
7960 and current Cisco IP phone models are signed
by CAPF or by an external CA
Secure SRST Certificate signed by external CA
BRKCRT-2202
Self-Signed Certificates
CCM1 TFTP TFTP
CCM1
of CCM1 of TFTP

of CCM1 of TFTP
of CCM1 of TFTP
CCM2 CAPF CAPF

CCM2
of CCM2 of CAPF

of CCM2 of CAPF
of CCM2 of CAPF
Each CallManager service has a self-signed certificate

The TFTP service also has self-signed certificates
If the CAPF is used (needed for LSC), it also has a self-signed certificate
All of them act as their own PKI root
BRKCRT-2202

14370_04_2008_c1.scr
Manufacturing Installed
Certificates (MIC)
Cisco CA
Cisco CA
Issue Certificate
Private Key During Production Private Key
of Phone of Cisco CA
Public Key
of Phone
Public Key Cisco CA Public Key
of Phone of Cisco CA
Public Key
of Cisco CA Public Key
of Cisco CA
Cisco IP phone models with MICs have a public and a private key pair
and MIC for the phone installed
The certificate of the IP phone is signed by the Cisco manufacturing CA
Cisco manufacturing CA is the PKI root for all MICs
BRKCRT-2202
Locally Significant Certificates (LSC)

CAPF Acting CAPF Acting
as a CA as a Proxy
CCM1 CCM1 Enterprise CA
CAPF CAPF Enroll
Enroll Enroll
LSCs can be used on phones with MICs or on Cisco Unified IP Phone

7940 and 7960 models (SCCP only)
They use LSCs issued either by the CAPF or by an external CA
The CAPF or external CA is the root for all LSCs
Cisco Unified Communications Manager 5.0 and 6.0 do not support
an external CA
BRKCRT-2202

14370_04_2008_c1.scr
Multiple PKI Roots in Cisco Unified
Communications Manager Deployments
CCM1 CCM1 TFTP TFTP

of CCM1 of TFTP

of CCM1 of TFTP
of CCM1 of TFTP
Cisco CA MIC LSC CAPF CA

7941 7940
Cisco CA CAPF

of 7941 of 7940
No single root but multiple independent PKI topologies

All need to be known and trusted (out-of-band verification)
Cisco Certificate Trust List (CTL) allows verification of roots
BRKCRT-2202
Cisco Unified
Communications
Manager Security
Cisco Certificate Trust List (CTL)
BRKCRT-2202

14370_04_2008_c1.scr
CTL Client Signs CTL
CCM1 CCM1 Signed List of Certificate Issuers
Cisco CTL Cisco CTL Client
Client
Public Key TFTP CCM1

of CCM1
TFTP TFTP
Private Key of TFTP of CCM1
of Cisco
Public Key CTL Client
of TFTP Cisco CA Cisco CA CAPF
CAPF
CAPF
Public Key Public Key Public Key
of Cisco of Cisco of Cisco Public Key
CTL Client CTL Client CTL Client of CAPF
Public Key
of CAPF
Obtains certificates of all certificate-issuing instances (PKI roots)

Creates a list (CTL) containing all obtained certificates and signs the list
Cisco CTL client keys physically stored on a security token
BRKCRT-2202
CTL Download
Cisco CTL Client
Cisco CA
TFTP CCM1
TFTP Public Key

of Phone
of TFTP of CCM1
Private Key
Cisco CA of Phone
Public Key
of Cisco Public Key
CTL Client of Phone
The CTL is sent to the IP phones over TFTP at boot

The CTL contains all entities that issue certificates
The IP phone now knows which issuers are trusted
Similar to Internet browser embedded Internet-CA certificates
BRKCRT-2202

14370_04_2008_c1.scr
Cisco CTL Client Application
Cisco CTL client software is used
to create or update the CTL
The CTL is signed by Cisco CTL
client using the private key from
one of the administrator security
tokens, which are all signed by the
Cisco CA
The CTL file must be updated only
if Cisco Unified Communications
Manager services or security
tokens change
The CTL also acts as an
authorization list specifying
which certificates belong to
which function (such as Cisco
Manager and TFTP) Security Token
BRKCRT-2202
CTL Verification on the IP Phone

Existing CTL on the Phone
Cisco CTL Client Cisco CTL Client
TFTP CCM1 TFTP CCM1
Public Key Public Key New CTL Public Key Public Key
of TFTP of CCM1 of TFTP of CCM1
over TFTP
Cisco CA CCM2 Cisco CA

of Cisco Public Key of Cisco
CTL Client of CCM2 CTL Client
Every time the IP phone receives a new CTL, it is verified

New CTL must be signed by one of the authorized security tokens
(listed in the IP phone’s current CTL file)
If no CTL file is present in phone, new CTL is not verified (initial
deployment or after erasing the CTL from the IP phone)
BRKCRT-2202

14370_04_2008_c1.scr
IP Phone Usage of the CTL
Encrypted Signaling (CallManager Service Certificate)
SCCP or SIP over TLS
Certificate-based two-way authentication between IP phone and Cisco Unified
Communications Manager
IP phone verifies self-signed Cisco Unified Communications Manager certificate
against CTL
LSC Enrollment (CAPF Certificate)
Protected by TLS
Certificate-based authentication of CAPF to IP phone
IP phone verifies self-signed CAPF certificate against CTL
Signed IP Phone Configuration Files (TFTP Server Certificate)
TFTP file is signed by private key of TFTP server
IP phone needs to know authentic public key of TFTP server
Signed CTL File (CTL Client Certificate)
CTL file is signed with private key of a security token
Corresponding public key must be known in current CTL
BRKCRT-2202
Cisco Unified
Communications
Manager Security
Signed Phone Loads
BRKCRT-2202

14370_04_2008_c1.scr
Signed Phone Loads
CTL Binary
Executable
Image.bin.sgn File
Config1.xml.sgn TFTP Server
Config2.xml.sgn
Cisco IP Phone Public Key
Config3.xml.sgn of Cisco
Image Signature
Image.bin.sgn
TFTP
Authenticated phone images (signed phone loads) introduced

with Cisco CallManager Release 3.3(3)
Image signed by Cisco manufacturing (using a private key)
Current image verifies signature and phone model information of new
image before accepting it (using the corresponding public key embedded
in the verification code of the current image)
Prevents falsification of phone image
BRKCRT-2202
Cisco Unified
Communications
Manager Security
Signed and Encrypted Configuration Files
BRKCRT-2202

14370_04_2008_c1.scr
Signed IP Phone Configuration Files
CTL XML TFTP
TFTP Server Configuration
Image.bin.sgn File
Config1.xml.sgn
Config2.xml.sgn Public Key
Signature of
Config3.xml.sgn of TFTP
TFTP Server
Config2.xml.sgn
TFTP
Configuration files signed by the TFTP server (using its private key)
Phone verifies signature before applying configuration (using
corresponding public key from CTL)
Automatically done for supported IP phones when security mode is
enabled for cluster
Prevents falsification of phone configuration files
BRKCRT-2202
Encrypted IP Phone Configuration Files

XML
Configuration
TFTP Server Symmetric
Image.bin.sgn File with
Key Used
Config1.xml.sgn Encrypted for
Config2.xml.sgn Content Encryption
Config3.xml.sgn and
Decryption
Config2.xml.sgn
TFTP
Configuration file encrypted by TFTP server

Phone decrypts configuration file before applying configuration
Two ways to manage key used for encryption (symmetric)
TFTP server encrypts the symmetric key using the IP phone’s public
key (for supported phones) and appends it to the configuration file
Manually entered keys used for IP phones that do not support public
and private keys (7905/7912 writeable web; 7940/7960 (SIP only): UI)
Prevents exposure of sensitive phone configuration settings
BRKCRT-2202

14370_04_2008_c1.scr
Cisco Unified
Communications
Manager Security
Secure Real-time Transport Protocol (sRTP)
BRKCRT-2202
sRTP Packet Format

V P X CC M PT Sequence Number
Time Stamp
Synchronization Source (SSRC) Identifier
Contributing Sources (CSRC) Identifier
...
RTP Extension (Optional)
RTP Payload
sRTP MKI—0 Bytes for Voice

SHA-1 Authentication Tag (Truncated Fingerprint)
Encrypted Data Authenticated Data
BRKCRT-2202

14370_04_2008_c1.scr
sRTP Encryption
Voice Voice
AES AES
AES AES
74lizE122U Encrypted Voice 74lizE122U

74lizE122U
A B
The sender encrypts the RTP payload using the AES algorithm and a
symmetric key
The receiver uses the same key to decrypt the RTP payload
Prevents eavesdropping of conversation
BRKCRT-2202
sRTP Authentication
Voice or
Encrypted +
Voice or SHA-1
+ Voice
Encrypted
SHA-1
Voice
SHA-1
SHA-1
32-bit Truncated
Hashes Equal?
s197i
Voice or
s197i Encrypted s197i
Voice
A B
The sender hashes the RTP payload together using the SHA-1 algorithm and a
symmetric key
The hash digest is truncated to 32 bits and added to the RTP packet
The receiver uses the same key for a local computation of the truncated hash and
compares it against the received one
Prevents falsification of RTP packets
BRKCRT-2202

14370_04_2008_c1.scr
sRTP in Cisco Unified Communications
Intra-cluster sRTP is supported by
Cisco IP phones using SCCP (since Cisco Unified CallManager 4.0)
Cisco IP phones using SIP (since Cisco Unified Communications Manager 5.0)
MGCP gateways (since Cisco Unified CallManager 4.0)
H.323 gateways (since Cisco Unified Communications Manager 5.0)
Inter-cluster sRTP is supported since Cisco Unified Communications
Manager 5.0
sRTP session keys (symmetric keys used for truncated HMAC and AES)
are generated by
Cisco IP phones (SIP)
Cisco Unified Communications Manager
Symmetric keys are exchanged in signaling messages
Secure signaling is required for key protection
Authenticated and encrypted signaling is mandatory for Cisco IP phones (SCCP and SIP)
when using sRTP
MGCP, H.323, Cisco Unified Communications Manager intra- and inter-cluster signaling are
NOT secured by default
IPsec should be used in these cases to protect keys in signaling messages
BRKCRT-2202
Cisco Unified
Communications
Manager Security
Secure Signaling
BRKCRT-2202

14370_04_2008_c1.scr
Certificate Exchange in TLS
Phone Hello
CallManager Hello
CallManager Certificate
Certificate Request
Phone Certificate
TLS hellos are used to negotiate attributes of the TLS session (one
or two-way certificate exchange, encryption and HMAC algorithms,
key lengths, etc.)
Certificates are exchanged
Certificates are then validated
BRKCRT-2202
Server-to-Phone Authentication
Phone Hello
CallManager Hello
Certificate Request
Phone Certificate
Challenge1
Response1
The IP phone sends a challenge to the server containing random

data to be signed by the server
The server signs the random data with its private key and returns the
signed data to the IP phone
The IP phone verifies the signature using the public key of the server
Prevents impersonation of server
BRKCRT-2202

14370_04_2008_c1.scr
Phone-to-Server Authentication
Phone Hello
CallManager Hello
Certificate Request
Phone Certificate
Challenge1
Response1
Challenge2
Response2
The server sends a challenge to the IP phone containing random data to

be signed by the IP phone
The IP phone signs the random data with its private key and returns the
signed data to the server
The server verifies the signature using the public key of the IP phone
Prevents impersonation of IP phone
BRKCRT-2202
TLS SHA-1 and AES Session

Key Exchange
Phone Hello
CallManager Hello
Certificate Request
Phone Certificate
Challenge1
Response1
Challenge2
Response2
Key Exchange
The IP phone generates session keys for SHA-1 and AES, encrypts them
using the public key of the server and sends the encrypted keys to the server
The server decrypts the keys
IP phone and server now share secret keys
BRKCRT-2202

14370_04_2008_c1.scr
Secure Signaling Using TLS
TLS
SHA-1 SCCP SHA-1

AES or SIP AES
Symmetric keys shared by IP phone and server are used to protect

signaling message (SCCP or SIP) using authenticated and
encrypted TLS packets
Prevents falsification and eavesdropping of signaling messages
BRKCRT-2202
Cisco Unified
Communications
Manager Security
Secure Conferencing
BRKCRT-2202

14370_04_2008_c1.scr
Secure Conferencing Overview
Cisco Unified Communications Manager 6.0 introduces secure
conferencing support
Secure conference bridge configured in Cisco IOS software
Registers with Cisco Unified Communications Manager using SCCP
over TLS
TLS authentication includes two-way certificate exchange:
Cisco Unified Communications Manager certificate(s) have to be known by secure
conference bridge (to be able to compare received certificate)
Certificate of CA that issued certificate to secure conference bridge has to be known
in Cisco Unified Communications Manager systems (to be able to verify signature of
received certificate)
Manually added during configuration time
Supported Cisco Unified IP phones:

7940 and 7960: SCCP only, authenticated conference only
7906, 7911, 7931: SCCP only
794[125], 796[125], 797[015]
BRKCRT-2202
Secure Conferencing
Configuration Procedure
1. Obtain a certificate for the secure conference media resource at
the Cisco IOS router
2. Configure a secure conference media resource in Cisco IOS
software and associate it with the previously obtained certificate
3. Export Cisco Unified Communications Manager certificate(s)
4. Add downloaded Cisco Unified Communications Manager
certificate(s) to Cisco IOS router
5. Export certificate of the CA that issued the certificate to the secure
conference media resource
6. Add downloaded CA certificate(s) to Cisco Unified
Communications Manager server(s)
7. Add and configure the secure conference bridge in Cisco Unified
Communications Manager
8. Optional: Configure a minimum security level for Meet-Me
conferences if desired (default is nonsecure)
BRKCRT-2202

14370_04_2008_c1.scr
Cisco Unified
Communications
Manager Security
SIP Digest Authentication
BRKCRT-2202
SIP Digest Authentication

No TLS support for third-party SIP phones
No TLS support for Cisco IP phones 7905, 7940 and 7960
when using SIP
SIP digest authentication can be used with these devices
(and on SIP trunks) for signaling protection
Provides authentication only using HMAC
Based on a client-server model (server challenges client)
Cisco Unified Communications Manager supports both functions on SIP trunks
(send challenges and respond to challenges)
Cisco Unified Communications Manager only supports server function to
IP phones (sends challenges only)
If used with Cisco IP phones, HMAC key is downloaded in TFTP configuration file
Use encrypted configuration files for key protection in TFTP files
Prevents falsification of SIP signaling messages

BRKCRT-2202

14370_04_2008_c1.scr
Cisco Unified
Communications
Manager Security
IPSec
BRKCRT-2202
IPsec
Network layer based security
Applicable for any sensitive traffic that is not protected
by applications themselves
Especially important when cryptographic keys are sent in clear
text—like sRTP keys in signaling messages
Server-to-server intra-cluster signaling
Inter-cluster trunk signaling
Signaling to H.323 gateways
Signaling MGCP gateways
Supported by Cisco Unified Communications Manager 5
ESP only, no AH
Pre-shared keys or X.509 certificates
Recommended to be used on network infrastructure devices
Prevents impersonation of IPsec peers
Prevents falsification and eavesdropping of protected IP packets
BRKCRT-2202

14370_04_2008_c1.scr
IPSec Scenarios in Cisco
Cisco Unified
Communications Manager Recommendation:
Use closest-possible
TLS H.323 network infrastructure
IP Phone H.323 device instead of
sRTP Gateway Cisco Unified
Cisco Unified Communications
Communications Manager Manager
TLS MGCP
IP Phone MGCP
sRTP Gateway
Cisco Unified Cisco Unified

Communications Manager Communications Manager
Inter- or intra-cluster
TLS TLS
IP Phone IP Phone
sRTP
BRKCRT-2202
Cisco Unified
Communications
Manager Security
Secure Survivable Remote Site Telephony (SRST)
BRKCRT-2202

14370_04_2008_c1.scr
Secure SRST
TLS
IP Phone
sRTP
Secure
TLS SRST
IP Phone
Allows Cisco IP phones to use TLS for signaling and sRTP for
media when in SRST mode
Prevents impersonation of SRST gateway and IP phones
Prevents falsification and eavesdropping of signaling and
RTP packets
BRKCRT-2202
PKI Topology with Secure SRST

Certificate Trust List (CTL)
CA
Cisco CA CAPF TFTP CCM
SRST Certificate
MIC LSC
SRST
IP Phone
Phones have certificates (MIC and/or LSC) and CTL

The SRST gateway obtains a certificate from any (external) CA
BRKCRT-2202

14370_04_2008_c1.scr
Trust Requirements with Secure SRST
IP phones must be able to verify Secure SRST gateway certificate
(issued by any external CA)
Secure SRST gateway certificate is not verified by its signature (using public key
of issueing CA)
Secure SRST gateway certificate is obtained by Cisco Unified Communications
Manager at configuration time (using the credential service at the gateway)
Manual verification is requested at configuration time
Cisco Unified Communications Manager adds received (and manually verified)
certificate to phone configuration files
Secure SRST gateway must be able to verify IP phone certificates

IP phone certificates are signed by either CAPF (LSC) or Cisco Manufacturing
CA (MIC)
CAPF and Cisco Manufacturing CA certificates are added manually to
Secure SRST gateway
BRKCRT-2202
Secure SRST—Certificate Import: Cisco

Unified Communications Manager
Imports certificate from the Secure SRST gateway over the network
Manual certificate fingerprint verification required
BRKCRT-2202

14370_04_2008_c1.scr
Secure SRST—Certificate Import:
Secure SRST Gateway
srst(config)#crypto pki trustpoint CAPF Certificates of entities that
srst(ca-trustpoint)# enrollment terminal signed phone certificates
srst(ca-trustpoint)# revocation-check none (CAPF, Cisco Manufacturing
srst(ca-trustpoint)#exit CAs) are added manually
srst(config)#crypto pki authenticate CAPF
Enter the base 64 encoded CA certificate.

End with a blank line or the word "quit" on a line by itself
(paste the certificate)
:
quit
Certificate has the following attributes:
Fingerprint MD5: F7E150EA 5E6E3AC5 615FC696 66415C9F
Fingerprint SHA1: 1BE2B503 DC72EE28 0C0F6B18 798236D8 D3B18BE6
% Do you accept this certificate? [yes/no]: y
Trustpoint CA certificate accepted.
% Certificate successfully imported
BRKCRT-2202
Certificate Usage in Secure SRST

TFTP
SRST Certificate
Obtained from Gateway

Configuration Credentials Service during Configuration
SRST
Certificate
File and added to IP Phone Configuration Files
Compare
SRST Certificate Manually
Certificates Entered
SRST Certificate SRST
TLS Two-way CAPF Certificate
Certificate Exchange
MIC Cisco CA
signed by LSC signed by CAPF Certificates
Check
Cisco CA Certificate’s
or
IP Phone Signature
LSC MIC signed by Cisco CA
signed by
CAPF
IP phone verifies received SRST gateway certificate against the one in its
configuration file
SRST gateway checks received IP phone certificate’s signature using
public key of issuer (Cisco CA or CAPF)
BRKCRT-2202

14370_04_2008_c1.scr
Summary
BRKCRT-2202
Summary
Threats to Cisco Unified Communications
Loss of privacy
Loss of integrity
Impersonation
Denial of service
Cryptography
Symmetric and asymmetric encryption
HMACs
Digital signatures
PKI
Cisco Unified Communications Manager security features
PKI-enabled, certificate-based solution; CTL in IP phones
Signed phone loads, signed and encrypted configuration files
sRTP and secure signaling
SIP digest authentication
IPsec
Secure SRST
BRKCRT-2202

14370_04_2008_c1.scr
Q and A
BRKCRT-2202
Recommended Reading
Continue your Cisco Live

learning experience with further
reading from Cisco Press
Check the Recommended
Reading flyer for suggested
books
Available Onsite at the Cisco Company Store

BRKCRT-2202

14370_04_2008_c1.scr
Complete Your Online
Session Evaluation
Give us your feedback and you could win Don’t forget to activate
fabulous prizes. Winners announced daily. your Cisco Live virtual
account for access to
Receive 20 Passport points for each session all session material
evaluation you complete. on-demand and return
for our live virtual event
Complete your session evaluation online now in October 2008.
(open a browser through our wireless network Go to the Collaboration
to access our portal) or visit one of the Internet Zone in World of
stations throughout the Convention Center. Solutions or visit
www.cisco-live.com.
BRKCRT-2202
BRKCRT-2202

14370_04_2008_c1.scr

CCVP Prep: Cryptography in Cisco Unified Communications: BRKCRT-2202

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

CCVP Prep: Cryptography in Cisco Unified Communications: BRKCRT-2202

Transféré par

Droits d'auteur :

Formats disponibles

CCVP Prep:

© 2008, Cisco Systems, Inc. All rights reserved. 1

 Impossible to cover all topics about voice security in a

 Threats to Cisco Unified Communications

© 2008, Cisco Systems, Inc. All rights reserved. 2

Examples of Threats Targeting

Impersonation Denial of Service

© 2008, Cisco Systems, Inc. All rights reserved. 3

Symmetric vs. Asymmetric Encryption

 Same (“shared”) key encrypts and decrypts

© 2008, Cisco Systems, Inc. All rights reserved. 4

 Based on key pairs: data encrypted by one key can only be

© 2008, Cisco Systems, Inc. All rights reserved. 5

Two Ways to Use

© 2008, Cisco Systems, Inc. All rights reserved. 6

Hash-Based Message Authentication Codes (HMAC)

© 2008, Cisco Systems, Inc. All rights reserved. 7

valid hash—algorithms Confirm

 Attacker changing the

Hash-Based Message Authentication

Sender transmits data plus hash Confirm Secret Key

 Symmetric Key Nature Hashing

Different key for each pair of devices Algorithm

 Used for bulk data (IPsec

© 2008, Cisco Systems, Inc. All rights reserved. 8

 Provide authenticity, integrity and non-repudiation

 Slower than HMAC

© 2008, Cisco Systems, Inc. All rights reserved. 9

Public Key Infrastructure (PKI)

© 2008, Cisco Systems, Inc. All rights reserved. 10

 Symmetric Keys used by Symmetric Encryption

 Public Keys used by Asymmetric Encryption and

Symmetric Key Distribution Protected by

Public Key Private Key

 Symmetric key is generated by one peer

© 2008, Cisco Systems, Inc. All rights reserved. 11

PKI as a Trusted Third-Party Protocol

 Does not eliminate the need for authenticity and

© 2008, Cisco Systems, Inc. All rights reserved. 12

Private Key Public Key

Public Key Public Key

Private Key Private Key

 Every entity, including the trusted introducer, needs to generate

PKI—Distribution of the Public Key

Private Key Public Key

Public Key Public Key

Private Key Public Key Public Key Private Key

© 2008, Cisco Systems, Inc. All rights reserved. 13

Private Key Public Key

Public Key Public Key

Private Key Public Key Public Key Private Key

© 2008, Cisco Systems, Inc. All rights reserved. 14

Private Key Public Key

Public Key Public Key

Private Key Public Key Public Key Private Key

 The trusted introducer sends signed certificates to the entities

PKI—Exchange of Public Keys Between

Public Key Public Key Public Key Public Key

 Entities can now exchange their public keys by means of their

© 2008, Cisco Systems, Inc. All rights reserved. 15

Self-signed Sometimes entities issue self-signed certificates:

Certificate Format Version Version 3

Impossible to cover all topics about voice security in a

Threats to Cisco Unified Communications

Same (“shared”) key encrypts and decrypts

Based on key pairs: data encrypted by one key can only be

Attacker changing the

Symmetric Key Nature Hashing

Used for bulk data (IPsec

Provide authenticity, integrity and non-repudiation

Slower than HMAC

Symmetric Keys used by Symmetric Encryption

Public Keys used by Asymmetric Encryption and

Symmetric key is generated by one peer

Does not eliminate the need for authenticity and

Every entity, including the trusted introducer, needs to generate

The trusted introducer sends signed certificates to the entities

Entities can now exchange their public keys by means of their

Used for sensitive web Internet-CA

The web server has a

Web browser applications have Internet-CA certificates already

The server passes its certificate to the client at connection startup

Cisco Unified Communication Manager services

Each CallManager service has a self-signed certificate

LSCs can be used on phones with MICs or on Cisco Unified IP Phone

No single root but multiple independent PKI topologies

Obtains certificates of all certificate-issuing instances (PKI roots)

The CTL is sent to the IP phones over TFTP at boot

Every time the IP phone receives a new CTL, it is verified

Authenticated phone images (signed phone loads) introduced

Configuration file encrypted by TFTP server

The IP phone sends a challenge to the server containing random

The server sends a challenge to the IP phone containing random data to

Symmetric keys shared by IP phone and server are used to protect

Supported Cisco Unified IP phones: