COMP3123 Internet Security

COMP3123 Internet Security Richard Henson University of Worcester October2010

Week 3: Cryptography, Securing the Internet, & the PKI • Objectives: • Explain the intended of the various components that make up the PKI and allow secure internetwok communications • Explain what Kerberos Authentication is, and how Kerberos can be used to securely authenticate users on remote networks • Apply principles of public-private key encryption and digital signatures to obtain a digital certificate via Internet and then use the PKI to send/receive encrypted messages

The Need for a Secure Architecture • As discussed last week: The Internet was designed to be an “open” system” • anyone with a little knowhow can read email/http communications… • no-one should therefore even think of asking people to send credit card details without using encryption • just as no-one (hopefully…) would leave their credit card details on someone’s voicemail! • For secure data transfer, PKE (public key encryption) of email sent through the Internet became an attractive option

The PKI (Public Key Infrastructure) • Developed in late 1990s through IETF; • shared as RFCs • Essential to provide support for Internet Encryption techniques and demand for services increased: • e.g. the distribution & identification of public keys • PKI is made up of: • Digital Signatures • Digital Certificates (DC) • Certificate Authorities (CA) • Repository for digital certificates • Authentication across networks • RFCs included contributions from the first CA – Verisign • #2459 in February 1999 : • v1 digital certificates; v1 revocation lists

Digital Certificates (or Digital IDs) • To support secure email, the PKI needed a way to ensure that the public key belongs to the entity to which the certificate was issued • Verisign provided this through the digital certificate: • the public key • information about the algorithms used • owner or subject data • the digital signature of a Certificate Authority that has verified the subject data • a date range during which the certificate can be considered valid

Providing Digital Certificates • IETF/Verisign agreed DCs should be made available via the www • IETF decided to use Directory Services compliant with the OSI X500 standard • result: LDAP (Lightweight Directory Access Protocol) • problem: the LDAP fields were not right for the Internet… • Developments (starting 1995) carefully controlled as RFCs: • RFC1777 – defined LDAP • RFC2585 – http accessible repository for certificates • RFC2587 – perfected X509 schema for LDAP v2 • RFC2251 – defined LDAP v3 • RFC2256 – X509 schema for LDAP v3… • still not complete: issues with authentication • Final Agreement (year 2006) • RFC 4510 – technical spec and roadmap for LDAP v3

Crucial Role of the Digital Certificate • Without certificates, it would not be possible to • 1. create a new key pair • 2. distribute the public key, claiming that it is the public key for almost anyone • Data could be sent encrypted with the private key and the public key would be used to decrypt the data… • but there would be no assurance that the data was originated by anyone in particular • all the receiver would know is that a valid key pair was used…

PKI & Certificate Authorities • Certificate Authority (CA) • guarantees that the individual granted the unique certificate is, in fact, who he or she claims to be • guarantee that the two parties exchanging information are really who they claim to be • CAs are “trusted” (e.g. banks) third-party organizations that issue digital certificates used to create digital signatures and public-private key pairs • contrast with PGP “web of trust” • This means that the CA must have an arrangement with a financial institution that provides it with information to confirm an individual's claimed identity • CAs are, and were intended to be, a critical component in the security transfer of information & electronic commerce

The Four Types of Digital Certificate… • Personal Certificates • Server Certificates • Software publisher Certificates • Certificate Authority certificates

Personal Certificates • Identify individuals • Authenticate users with a server, or to enable secure e-mail using S-Mime • If a Windows password list file (.pwl) becomes damaged or missing: • the personal certificate is not available for use • you may therefore receive an error message when you try to send e-mail! • It is the responsibility of the user to back up this file so passwords can be recovered • Microsoft offered encryption for this file as far back as Windows 95 & 98 systems!

Server Certificates • Identify servers that participate in secure communications with other computers… • using secure communication protocols such as SSL (secure sockets layer) • Allow a server to verify its identity to clients • Follow the X.509 certificate format • As defined by the Public-Key Cryptography Standards (PKCS)

Software Publisher Certificates • Used are used to sign software that will be distributed over the Internet • Internet browsers are capable of trusting software that is signed with a publisher's certificate • Example: • Microsoft use a system called Authenticode • requires a software publisher certificate to sign Microsoft ActiveX and other compiled code. • Authenticode does not guarantee that signed code is safe to run, but rather informs the user whether or not the publisher is participating in the infrastructure of trusted publishers and CAs • Trusted software publishers appear in a list provided in Internet Explorer

Root (class 1) Certificate Authorities • Trusted organisations set up specifically for the purpose of awarding digital certificates • e.g. Verisign • Usually associated with banks, or credit card companies, who can reliably authenticate the name of anyone requesting a digital certificate

Root and Intermediate Certification Authorities & their certificates • Root certificates are self-signed… • subject of the certificate is also the signer of the certificate • Root CAs can also assign certificates for “Intermediate Certification Authorities” • The hierarchy can continue downwards: • Intermediate Certification Authorities can issue: • server certificates • personal certificates • publisher certificates • certificates for other Intermediate Certification Authorities…

Verisign Digital Certificates • Included “by default” with Internet Explorer • Issued and signed by the Class 1 Public Primary Certificate Authority, and therefore root certificates • Intermediate Certification Authorities option also available: • listed as "VeriSign Class 1 CA“ • means that Verisign (as Root certificate authority) issued these certificates • created for the purpose of issuing and validating personal digital certificates • if a person has obtained a Class 1 personal digital certificate from VeriSign, it will be issued by one of these Intermediate CAs

Verification Chains • The system of root and intermediate certificate authorities creates what is known as a verification chain • root authority is always at the top • could be a number of intermediate authorities • verification chains can contain a large number of certificates depending upon the number of intermediates in the chain

How a Certificate Is Issued - 1 • Key Generation • The person requesting certification sets the process in motion that will automatically generate key pairs of public and private keys • Matching of Policy Information • anyone requesting a CA is required to send additional information requested by the CA to issue the certificate, before the certificate is generated • tax ID number • e-mail address • etc…

How a Certificate Is Issued – 2 • Verification of Information • The CA applies whatever policy rules it requires in order to verify the information gathered • If verification is successful… • Public Keys and Information is sent (often encrypted using the CA's public key) to the CA • the CA may wish to make it available on the Internet through a repository • a process then begins whereby the applicant should receive their certificate

How a Certificate Is Issued - 3 • Certificate Creation • The CA creates a digital document with the appropriate information (public keys, expiration date, and other data) and signs it using the CA's private key • Sending/Posting of Certificate • The CA may email the certificate to the applicant, or post it publicly as appropriate • The certificate is installed on the individual's computer

Certificate Revocation • Typical reasons: • The certificate holder's private key may have been compromised • false information may have been used to apply for the certificate • CAs publish certificate revocation lists (CRLs) containing certificates that have been revoked by the CA • provide a way of withdrawing a certificate after it has been issued • available for downloading or online viewing by client programs

Verifying a Certificate • Verification of a certificate requires the public key of the CA and a check against the CRL published by that CA • certificates and CAs reduce the public-key distribution problem of verifying and trusting one (or more) public keys per individual • instead, only the CA's public key must be trusted and verified, and then that can be relied on to allow verification of other certificates

Certificate Repository • A system or collection of distributed systems that store digital certificates and CRLs and serves as a means of distributing these certificates and CRLs to end entities • Covers the use of FTP and HTTP to obtain and download: • X509 Digital Certificates (recommend saved as .cer, but could also be .p7c) • CRLs (recommend saved as .crl) from PKI repositories

What is x509? • PKI standard for managing digital certificate information, defined by RFC 2459 • also integrated with the OpenSSL infrastructure • OpenSSL consists of an “open source” implementation of: • SSL (secure sockets layer) • TLS (transport layer security) • OpenSSL architecture can: • display certificate information • convert certificates to various forms • sign certificate requests like a "mini CA“ • edit certificate trust settings

Logging On Remotely using Kerberos Authentication • Kerberos was (is) a very clever system developed at MIT to support secure remote network logon • it became part of the PKI thanks to IETF support and RFC 1510 • It was subsequently adopted by Microsoft to provide authentication for remote Windows 2000 logons to support logon across domain trees and forests (RFC 3244)

The Kerberos System • A number of components are needed: • Central coordination/distribution centre (KDC) as a “trusted centre” • Link between each participating network user (client) and the distribution centre for the sharing of secret keys • Shared secret key generation when a computer joins a domain • Client-server trust can then be established • theory is that both parties (client and server) trust the KDC, so they trust each other!

Mechanism of Kerberos Authentication • All based on the KDC • Client requests valid logon credentials from KDC • NOT the server it is logging on to! • Logon info provides the KDC with username/password client-ID info and the domain that it is requesting to log on to

Role of the KDC • Looks up secret keys of both client and server that client is trying to log on to • Then creates a “ticket” containing • expiration time, determined by the security policy • random session key • current KDC time • the SID – secure identifier • The ticket is then encrypted using the client’s secret key

Role of the KDC • The KDC then creates a second “session ticket” containing: • the session key • optional further authentication data that is encrypted with the server’s key • Both tickets are transmitted to the client (server doesn’t even need to be involved – only a valid client can encrypt the ticket anyway!)

Client-Server Communication • Once the client has a valid ticket and session key for a server, it can communicate directly with that server • To do this, the client constructs an authenticator: • Clients name • Optional checksum • Randomly generated number/session subkey • Encrypted using the session key, and transmitted with the session ticket • Authenticators can only be used once

Server actions • When the ticket is received: • Decrypts session ticket using the servers shared secret key • Retrieves the session key • Uses this to decrypt the authenticator – and prove that it was received from the KDC using the shared secret key • Authenticator proves that the key is recent and not a replay attack

Diagram of a KDC system: client-side KDC client Request for ticket Generate authenticator & encrypt using session key Retrieve secret key for client & server Create ticket Encrypt ticket with clients secret key ticket Create session ticket & encrypt with server key SERVER

Diagram of a KDC system: server-side CLIENT ticket & authenticator server Decrypt session ticket using server secret key Decrypt authenticator using session key KDC Validate authentication Grant access, service requests

Revision of Domain Relationships (NT) • Covered in COMP2122 • Windows NT domains (pre-W2K): • Each domain can be set up to “trust” other domains: • users and groups then get access to trusted domain • potentially a security threat, through the trusted domain Domain A trusts Domain B

Revision of Domain Relationships (Active Dir) • Windows 2000 etc allow “domain tree” structures: • a whole 2D structure of domains with a trust relationship can be set up • potentially a HUGE security threat, if authentication is compromised…

Kerberos and Trust Relationships between Domains • Any domain name that is connected to the Internet is actually part of the Domain Name system • e.g. there was once an NT domain called bandit (Business and IT) here at Worcester • Thanks to active directory, it became bandit.worc.ac.uk in the Internet naming system • Domains that are linked within an Active directory domain tree work within a system that automatically creates interdomain keys for Kerberos through a system involving local and “foreign” KDCs

So now you know!That’s all folks…  Plenty more PKI-related RFCs on the IETF website…

COMP3123 Internet Security