12 SSL Certificates and PKI [PDF]

Zitiervorschau

Cryptography SSL Certificates and PKI The Public Key Game!

COPYRIGHT OF LUCIDEUS 2018 | CONFIDENTIAL DOCUMENT

Unit 12

Public Key Infrastructure & SSL/TLS

• • • • • • • • •

Relation b/w certificates & SSL/TLS SSL/TLS introduction SSL/TLS handshake process Public Key Infrastructure Certificate Authorities and its types Certificate issuance process Certificate chain Certificate Architecture SSL Pinning

2

Cryptographic protocols designed to provide communication security over a network. SSL: Developed by Netscape Communications for adding HTTPS protocols to their Navigator web browser. Introduction to SSL/ TLS

TLS: Extension to SSL, proposed by IETF in 1999. Protocol

Published

Status

SSL 1.0

Unpublished

Unpublished

SSL 2.0

1995

Deprecated in 2011 (RFC 6176)

SSL 3.0

1996

Deprecated in 2015 (RFC 7568)

TLS 1.0

1999

Deprecation planned in 2020

TLS 1.1

2006

Deprecation planned in 2020

TLS 1.2

2008

TLS 1.3

2018 3

Requirement: ● Confidentiality ● Integrity ● Authentication Introduction to SSL/ TLS ● Non-repudiation

4

● Browser sends a ‘Client Hello’ message to server with a list of supported ciphers, key exchange, and hashing algorithm ● Key exchange determines the client-server authentication How SSL works

● Server responds with a ‘Server message and the selected cipher

Hello’

Process is called SSL/ TLS handshake

5

SSL/ TLS Handshake

6

Demo in wireshark

SSL/ TLS Handshake

7

Demo: ● Google chrome certificates ● Mozilla Firefox certificates

Reading/ Examining the Certificate

Windows certificate store: ● certmgr.msc Linux certificate store: ● /etc/ssl/certs (System certificates)

8

● Key generation

○ Create a key with the request strength using the proper cipher.

● Certificate Generation ○ Allocate a key to the user

● Distribution

○ Makes the key available to the user

● Storage

Key Management Life Cycle

○ Secure storage and protection against unauthorized use.

● Revocation

○ Manage the keys that have been compromised.

● Expiration

○ Certificate have a specific life.

9

● PKI: Policies, procedure, hardware, software, people ○ Dig Sig: Create, distribute, manage, revoke & store ● This is a big, big thing ○ Lots of planning Public Key Infrastructure

● Also refers to binding public keys to people ○ The certificate authority ○ It’s all about the trust

1 0

Requirement

• Some Trusted Agency is required which certifies the association of an individual with the key pair. Certifying Authority (CA) • This association is done by issuing a certificate to the user by the CA Public key certificate (PKC) • All public key certificates digitally signed by the CA

are

11

• Must be widely known and trusted • Must have well defined Identification process before issuing the certificate • Provides online access to all the certificates issued Certifying Authorities

• Provides online access to the list of certificates revoked • Displays online the license issued by the Controller • Displays online approved Certification Practice Statement (CPS) • Must adhere to IT Act/Rules/Regulations and Guidelines

1 2

Certificate Issuance

1 3

● Some small systems implementations have CA, RA and VA on same server, but typically they are distributed on different servers. ● One CA server have multiple RA and VA associated with it. Certificate Issuance

● CA hierarchy is used because root CA must be kept secure otherwise whole security will fall

1 4

Root CA

● Also called as trusted root ● Center of the trust model for SSL/TLS ● Every browser has root store (some trust third party) ● Root certificate is invaluable (cert. signed with Pr key will be trusted by all) ● Trusted roots belongs to CA (CA validates & issue SSL cert.)

1 5

● CA do not issue server certificates (end user SSL certificates) directly off of their roots. ● That would be dangerous Intermediate CAs

● Root CAs issues intermediate root CA (also called as intermediate CA). ● Root CA sign intermediate CA with it’s private key. ● This process can play out several times ● Finally a CA signs the certificate.

1 6

● A Root CA is a Certificate Authority that owns one or more trusted intermediate CA. ○ They have roots in the trust stores of the major browsers. Root CA vs Intermediate CA

● Intermediate CAs or Sub CAs are Certificate Authorities that issue off end user certificate or points another CA. ○ They do not have roots in the browser’s trust stores, instead their intermediate roots chain back to a trusted third-party root. ○ This is sometimes called cross-signing.

1 7

http://www.cca.gov.in/cca/

Controller of Certifying Authorities

1 8

● Controller is the Root certifying authority responsible for regulating Certifying Authorities (CAs) ● Controller certifies the association of CA with his public key Trust Path

● Certifying Authority (CA) is the trusted authority responsible for creating or certifying identities. ● CA certifies the association of an individual with his public key

1 9

Certificate Chain

2 0

Top Root CA (2018)

2 1

Structure of an X.509 v3 digital certificate:

Certificate Architecture

■ Version Number ■ Serial Number ■ Signature Algorithm ID ■ Issuer Name ■ Validity period ● Not Before ● Not After ■ Subject name ■ Subject Public Key Info ● Public Key Algorithm ● Subject Public Key ■ Issuer Unique Identifier (optional) ■ Subject Unique Identifier (optional) ■ Extensions (optional) ●… ■ Certificate Signature Algorithm ■ Certificate Signature

2 2

1. End Entity Certificate 2. Intermediate Certificate 3. Root Certificate

Certificate Architecture

2 3

End Entity Certificate Decoded X.509 Certificate

Certificate: Data: Version: 3 (0x2) Serial Number: 10:e6:fc:62:b7:41:8a:d5:00:5e:45:b6 Signature Algorithm: sha256WithRSAEncryption Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2 Validity Not Before: Nov 21 08:00:00 2016 GMT Not After : Nov 22 07:59:59 2017 GMT Subject: C=US, ST=California, L=San Francisco, O=Wikimedia Foundation, Inc., CN=*.wikipedia.org Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 00:c9:22:69:31:8a:d6:6c:ea:da:c3:7f:2c:ac:a5: af:c0:02:ea:81:cb:65:b9:fd:0c:6d:46:5b:c9:1e: 9d:3b:ef ASN1 OID: prime256v1 NIST CURVE: P-256 X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Agreement Authority Information Access: CA Issuers - URI:http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt OCSP - URI:http://ocsp2.globalsign.com/gsorganizationvalsha2g2 X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.4146.1.20 CPS: https://www.globalsign.com/repository/ Policy: 2.23.140.1.2.2 X509v3 Basic Constraints: CA:FALSE X509v3 CRL Distribution Points: Full Name: URI:http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl X509v3 Subject Alternative Name: DNS:*.wikipedia.org, DNS:*.m.mediawiki.org, DNS:*.m.wikibooks.org, DNS:*.m.wikidata.org, DNS:*.m.wikimedia.org, DNS:*.m.wikimediafoundation.org, DNS:*.m.wikinews.org, DNS:*.m.wikipedia.org, DNS:*.m.wikiquote.org, DNS:*.m.wikisource.org, DNS:*.m.wikiversity.org, DNS:*.m.wikivoyage.org, DNS:*.m.wiktionary.org, DNS:*.mediawiki.org, DNS:*.planet.wikimedia.org, DNS:*.wikibooks.org, DNS:*.wikidata.org, DNS:*.wikimedia.org, DNS:*.wikimediafoundation.org, DNS:*.wikinews.org, DNS:*.wikiquote.org, DNS:*.wikisource.org, DNS:*.wikiversity.org, DNS:*.wikivoyage.org, DNS:*.wiktionary.org, DNS:*.wmfusercontent.org, DNS:*.zero.wikipedia.org, DNS:mediawiki.org, DNS:w.wiki, DNS:wikibooks.org, DNS:wikidata.org, DNS:wikimedia.org, DNS:wikimediafoundation.org, DNS:wikinews.org, DNS:wikiquote.org, DNS:wikisource.org, DNS:wikiversity.org, DNS:wikivoyage.org, DNS:wiktionary.org, DNS:wmfusercontent.org, DNS:wikipedia.org X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 Subject Key Identifier: 28:2A:26:2A:57:8B:3B:CE:B4:D6:AB:54:EF:D7:38:21:2C:49:5C:36 X509v3 Authority Key Identifier: keyid:96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C Signature Algorithm: sha256WithRSAEncryption 8b:c3:ed:d1:9d:39:6f:af:40:72:bd:1e:18:5e:30:54:23:35: ... 2 4

Issuer C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2

End Entity Certificate

Authority Key Identifier 96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83: 00:40:E6:1A:7C

2 5

Intermediate Certificate Belongs to a Certificate Authority

Certificate: Data: Version: 3 (0x2) Serial Number: 04:00:00:00:00:01:44:4e:f0:42:47 Signature Algorithm: sha256WithRSAEncryption Issuer: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA Validity Not Before: Feb 20 10:00:00 2014 GMT Not After : Feb 20 10:00:00 2024 GMT Subject: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2 Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:c7:0e:6c:3f:23:93:7f:cc:70:a5:9d:20:c3:0e: ... Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 X509v3 Subject Key Identifier: 96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C X509v3 Certificate Policies: Policy: X509v3 Any Policy CPS: https://www.globalsign.com/repository/ X509v3 CRL Distribution Points: Full Name: URI:http://crl.globalsign.net/root.crl Authority Information Access: OCSP - URI:http://ocsp.globalsign.com/rootr1 X509v3 Authority Key Identifier: keyid:60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B Signature Algorithm: sha256WithRSAEncryption 46:2a:ee:5e:bd:ae:01:60:37:31:11:86:71:74:b6:46:49:c8: ... 2 6

Intermediate certificate authority signed the end-entity certificate, and was signed by the root certificate.

Intermediate Certificate Belongs to a Certificate Authority

● Subject field of this intermediate certificate matches the issuer field of the end-entity certificate that it signed. ● The "subject key identifier" field in the intermediate matches the "authority key identifier" field in the end-entity certificate .

2 7

Data:

Root Certificate Self Signed

Version: 3 (0x2) Serial Number: 04:00:00:00:00:01:15:4b:5a:c3:94 Signature Algorithm: sha1WithRSAEncryption Issuer: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA Validity Not Before: Sep 1 12:00:00 1998 GMT Not After : Jan 28 12:00:00 2028 GMT Subject: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:da:0e:e6:99:8d:ce:a3:e3:4f:8a:7e:fb:f1:8b: ... Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE X509v3 Subject Key Identifier: 60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B Signature Algorithm: sha1WithRSAEncryption d6:73:e7:7c:4f:76:d0:8d:bf:ec:ba:a2:be:34:c5:28:32:b5: ...

Its issuer and subject fields are the same, and its signature can be validated with its own public key. Validation of the trust chain has to end here

2 8

The client will authenticate the server certificate it receives by doing the following:

Server Authentication

1. Identify the CA that signed the server certificate. 2. Find that CA certificate in its trusted CA certificate store and obtain the public key. 3. Use the public key to validate that the signature is genuine. 4. If the CA is itself signed by a higher level CA then the client will find that CA in its trusted store a. Then use its public key to validate the signature on the first CA. b. This process will repeat until the top level CA in the chain of trust is reached – this will be the root CA. 5. If the client does not have a local copy of any of the intermediate CA certificates then it will try to download them from the root CA. 2 9

1.X.509 Certificate a. Must be issued by Professional CA b. CPS: Certification Practices Statement required c. Naming authority hierarchies d. Centralized Model

Certificate Standards

2.PGP a. Issuers are not professionals b. Web of Trust model c. Decentralized model d. PGP Keyservers similar to a CA (but we can choose or create our own) e. If chain of trust breaks then might be difficult to figure out Google Certificate Transparency Project https://www.certificate-transparency.org/

3 0

Digital Certificate: Serves as a proof of identity of the server.

SSL Pinning

The client will only trust the server if: ● Server can provide a valid certificate that is signed by one of the trusted Certificate Authorities ● That trusted CA certificate come pre-installed in the client

How attacker can abuse this system: ● Install a malicious root CA Cert. to user device ● Compromise the CA completely

3 3

SSL Pinning: Used in the client side to avoid man-in-the-middle attack by validating the server certificates again even after SSL handshaking.

SSL Pinning

● Developers pin list of trustful certificates to the client application during development ● Use these to compare against the server certificates during runtime. ● If mismatch between the server and the local copy of certificates, the connection will simply be disrupted

Two ways of pinning: ● Pin whole certificate ● Pin the public key ○ Further of two types: ■ Pin: SubjectPublicKeyInfo ■ Pin concrete type: RSAPublicKey DSAPublicKey

or 3 4

Security mechanism delivered by HTTP Header

SSL Pinning: HTTP Public Key Pinning (HPKP)

● Trust on First Use ● Web server tells client via special HTTP header which public keys belong to it ● Client stores this information for a given period of time ● When the client visits the server again: ○ Expect at least one certificate in the certificate chain to contain a public key ○ This public key fingerprint is already known via HPKP.

3 5

To enable this feature for the site: ● Need to return the Public-Key-Pins HTTP header when site is accessed over HTTPS ● Steps necessary to deliver the HPKP header depend on the web server SSL Pinning: HTTP Public Key Pinning (HPKP)

Browser testing for HPKP and HSTS: https://projects.dm.id.lv/Public-Key-Pins_test

HPKP Header Example: Public-Key-Pins: pinsha256="cUPcTAZWKaASuYWhhneDttWpY3oBAkE3h2+soZS7sWs="; pin-sha256="M8HztCzM3elUxkcjR2S5P4hhyBNf6lHkmjAHKhpGPWE="; max-age=5184000; includeSubDomains; report-uri="https://www.example.org/hpkp-report" 3 6

Thank you