SHA-2 SHA-512/224, SHA-512/256. - · PDF fileDefault Certificates 1. Default certificates,...

Click here to load reader

  • date post

    31-May-2019
  • Category

    Documents

  • view

    229
  • download

    0

Embed Size (px)

Transcript of SHA-2 SHA-512/224, SHA-512/256. - · PDF fileDefault Certificates 1. Default certificates,...

1

1. This talk provides guidance for migrating Avaya provided demonstration grade certificates to customer self-signed or trusted root 3rd party digital certificates. 2. The new generation of Avaya products will require servers to have certificates issued by a trusted Certificate Authority (CA) in order for the product to establish a secure connection.3. Administrators must review their networks to determine the certificates in use + decide whether to use CA certs to products including end-user devices, to replace server

certificates, or both. 4. Why is this happening - as with other forms of identification, certificate technology has progressed over the years. 5. Current standards mandate using newer algorithms than are in place in the default certificates that Avaya has shipped with Avaya Aura systems for demonstration, lab,

and isolated private network use, so use of these default certificates has now been deprecated and trust of the Avaya SIP Product CA has been removed from new products.

6. Avaya's recommendation is that customers upgrade their servers to use certificates generated to the current US National Institute of Standards and Technology (NIST) standards for information systems security. Detailed information for doing this upgrade is available in the product documentation.

7. The default certificates shipped with Avaya Aura Session Manager were intended for lab and demonstration use only. 8. Up to now, products have included support for these default certificates to facilitate lab testing. 9. Removing support for these default certificates from the products allows a customer with higher security needs to implement a strategy using current best practices.10. Avaya Aura 6.2.x Feature Pack 1st release to officially support SHA2/204 certificates.

SHA-1A 160-bit hash function which resembles the earlier MD5 algorithm. This was designed by the National Security Agency (NSA) to be part of the Digital Signature Algorithm. Cryptographic weaknesses were discovered in SHA-1, and the standard was no longer approved for most cryptographic uses after 2010. SHA-2

A family of two similar hash functions, with different block sizes, known as SHA-256 and SHA-512. They differ in the word size; SHA-256 uses 32-bit words where SHA-512 uses 64-bit words. SHA-2 includes significant changes from its predecessor, SHA-1.

The SHA-2 family consists of six hash functions with digests (hash values) that are 224, 256, 384 or 512 bits: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256.

1. Nevertheless careful inspection of the entire infrastructure is a mandatory preliminary task to evaluate if all communicating parties (clients and servers) support the SHA2 signing algorithm.

What services are affected?1. All communications between two parties (client-server and server-server) in the Avaya Aura environment are secured using Transport Layer Security (TLS, a newer

version of SSL that you may be familiar with). 2. In TLS, servers are configured with an identity certificate issued by a certificate authority. 3. When products connect to servers, the server presents its identity certificate for the client to validate. 4. The client checks whether the server identity certificate was issued by a certificate authority that the client trusts (among other items). If everything checks out, then the

client proceeds and a secure connection is established.

1. Enhanced security is the overall motivator for migrating from demo to third party signed certificates. 2. This is achieved by deploying certificates with shorter validity, enhanced key length, stronger signing algorithms and a trusted issuing authority. 3. A Digital Certificate serves as a guarantee that the parties to a transaction are who they claim to be. 4. The certificate consists of a long string of binary code issued by a certification authority (CA). 5. The CA authenticates the parties' identities and

1. creates a public key for message encryption, 2. and a private key for message decryption. 3. A Digital Certificate does not imply anything about the transaction itself.

6. A Digital Certificate contains a certificate number, dates during which the certificate is valid, the CA's name and digital signature. Digital Certificates have a limited lifetime, usually one year.

7. The replying party checks if the CA is set as a trusted one in the partys trusted CA key store, the expiration data of the Digital Certificate along with the signature and much more.

8. A Digital Certificate contains a certificate number, dates during which the certificate is valid, the CA's name and digital signature. Digital Certificates have a limited lifetime, usually one year.

9. The replying party checks if the CA is set as a trusted one in the partys trusted CA key store, the expiration date of the Digital Certificate along with the signature and much more.

10. Many components have multiple trust stores. It has to be ensured that the CA root certificate is installed in each of the required trust stores.

2

Default Certificates1. Default certificates, also known as demo certificates, are non-unique identity certificates

issued by the Avaya SIP Product Certificate Authority for demonstration and lab testing only. Default certificates are very insecure and do not meet current NIST standards.

2. Continue to use the Default Certificates in an isolated LAN environment until the Demo Certificate expires if:

You do not yet deploy or manage X.509 Certificates within your data network. Your VOIP solution is completely isolated from internal and external data networks.

3. This strategy is not approved for production networks that are not isolated and sufficiently protected from eavesdropping. The certificates will NOT be renewed. Eventually, a different strategy MUST be used.

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

1. All communications between the client and the servers in the Avaya Aura environment are secured using a technology called Transport Layer Security (TLS, a newer version of SSL that you may be familiar with). In TLS, servers are configured with an identity certificate issued by a certificate authority. When clients connect to servers, the server presents its identity certificate for the client to validate. The client checks whether the server identity certificate was issued by a certificate authority that the client trusts (among other items). If everything checks out, then the client proceeds and a secure connection is established.

2. The color coding of each element reflects the issuing certificate authority for certificates presented by that element (see the legend for details).

3. Elements which may have certificates from multiple authorities are shown using a gradient fill.

4. Customers who have deployed the Avaya Unified Communications solution over time may have a very complex set of certificates and may require the installation of up to four CA certificates on client devices as well as replacing the default certificate on the Avaya one-X Client Enablement Services server.

5. The Avaya Aura team is working to simplify this situation; new installations will use the Avaya Aura System Manager as a certificate authority where possible and eliminate use of the Avaya SIP Product certificate authority entirely.

6. How to simplify your network Installing certificates issued by your enterprise certificate infrastructure or by a well-known certificate vendor will simplify your network + reduce the amount of work required for your users to start using the new Avaya products.

7. If you use a well-known certificate vendor that is already trusted by the end-user client devices, there is no need to deploy certificates to those devices at all.

8. If you have an enterprise certificate infrastructure, you may need to make the CA certificate available to end users so that they can install it on their client device and provide instructions for them to do so.

28

29

30

FundamentalsCertificate Authority (CA)

1. A Certificate Authority (CA) is a trusted entity that issues Digital Certificates and public-private key pairs. A Certificate Authority (CA) verifies the identity of an individual or organization before issuing a digital certificate.

2. A Certificate Authority (CA) can be an external (public) Certificate Authority (CA) like Verisign, Thawte or Comodo, or an internal (private)

Certificate Authority (CA) configured inside an enterprise network. A Certificate Authority (CA) is a critical security service in a network and performs the following functions:

- Verifies the identity. The Certificate Authority (CA) must validate the identity of the entity who requested a digital certificate.- Issues digital certificates. If the validation process succeeds, the Certificate Authority (CA) issues the digital certificate to the entity who requested it.- Maintains the Certificate Revocation List (CRL). A certificate revocation list (CRL) is a list of digital certificates that are no longer valid and have been revoked. These digital certificates are not reliable.

Public Key Infrastructure (PKI)The Public Key Infrastructure (PKI) is a system that creates, manages, stores, distributes, and revokes Digital Certificates. A PKI provides a method to securely and privately exchange data through the use of a public and a private cryptographic key pair that is obtained and shared through a trusted authority.A PKI consists of a:1. - Certificate Auth