Transcript WHAT ARE THE THREE 'CORE/KEY SKILLS'?
COMP3123 Internet Security
Richard Henson University of Worcester October 2011
Week 3: Securing the Internet with encryption, & the PKI
Objectives: Explain the intended of the various components that make up the PKI, allowing secure internetwork communications Explain what Kerberos Authentication is, and how KDCs can be used to securely authenticate users on remote networks using active directory 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)
A series of components developed in the late 1990s through IETF: shared as RFCs became a very elaborate cryptosystem Essential to provide support for Internet Encryption techniques and demand for services increased: e.g. the distribution & identification of public keys
Components of the PKI
The PKI is made up of: Digital Signatures Digital Certificates (DC) Certificate Authorities (CA) Repository (object-oriented database) for digital certificates Means of accessing that repository in a controlled way Authentication across networks
LDAP, Digital Certificates and the PKI
Digital Certificates developed as an alternative to PGP’s “web of trust” part of a movement that resulted in the creation of a secure Internet infrastructure became known as the Public Key Infrastructure Dependent on a central registry of public keys associated with authentication data, which is readily accessible via the Internet included a set of “lookup” protocols known as LDAP (Lightweight Directory Access Protocol) enabled public key lookup to occur transparently i.e. without intervention from the user
Contribution from non-academics
The PKI was developed mostly through the efforts of the research community via the IETF Other organisations also contributed RFCs: Contributions from Microsoft: » e.g. LDAP (original RFC’s #1777, 1778, 1779) The first CA – Verisign » first RFC (#2459) in February 1999 : » defined v1 digital certificates; v1 revocation lists » CA’s considerably evolved since that time…
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 …
Making Digital Certificates (or Digital IDs) a practical reality
To support secure transmission of data, the people working on 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
An Infrastructure for Digital Certificates
IETF/Verisign agreed that Digital Certificates and the Public Key registry should be made available and downloadable via the www IETF decided to use Directory Services compliant with the OSI X500 standard » result: LDAP (Lightweight Directory Access Protocol) » problem: the original LDAP fields were not right for the Internet…
LDAP: mechanism for the Public Key “look up”/repository
Developments (starting 1995) carefully controlled: 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
PKI & Certificate Authorities
An organisation that guarantees » that the individual granted the unique certificate is, in fact, who he or she claims to be » that the two parties exchanging information are really who they claim to be decides who should be awarded a digital certificate (DC), and records essential information required for that award Accepts payment for the award of the DC
Who are Certificate Authorities?
CAs are, and were intended to be, a critical component in the security transfer of information & electronic commerce Because of the financial dimension, CAs are associated with “trusted” (e.g. banks) third-party organizations that provides it with information to confirm an individual's claimed identity If identity approved, CAs issue the digital certificates used to create digital signatures and public-private key pairs contrast with PGP “web of trust”
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 to digitally 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 The “trust” hierarchy continues downwards to Intermediate Certification Authorities Types of certificates issued: » 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
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 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
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 implementation of: consists of an “open source” 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 Developed at MIT to support secure logons via diverse networks became part of the PKI » IETF support, v5 RFC 1510 (1993) subsequently adopted by Microsoft to provide authentication for remote Windows 2000 logons (RFC 3244) » supports logon across domain trees within forests
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 - 1
Looks up secret keys of both client and server that client is trying to log on to Then creates a “session ticket” containing 1.
expiration time, determined by the security policy 2.
random session key 3.
current KDC time 4.
the SID – secure identifier The ticket is then encrypted using the client’s secret key
Role of the KDC - 2
S econd “session ticket” then created containing: the session key optional further authentication data that is encrypted with the server’s key Both tickets transmitted to the client note: server doesn’t even need to be involved – only a valid client can encrypt the ticket anyway!
Client-Server Communication using KDCs
Once the client has a valid ticket and session key for a server… can communicate directly with that server Mechanism: the client constructs an
“authenticator”
made up of: client 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 in KDCs
When the ticket is received: Decrypts session ticket using the servers shared secret key Retrieves the session key Uses this to decrypt the authenticator » proves that it was received from the KDC using the shared secret key » And 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 ticket SERVER Retrieve secret key for client & server Create ticket Encrypt ticket with clients secret key Create session ticket & encrypt with server key
Diagram of a KDC system: server-side
CLIENT KDC ticket & authenticator server Decrypt session ticket using server secret key Decrypt authenticator using session key 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
Active Directory and KDC
Kerberos principles “built in” from time of launch of active directory Domains linked
within an Active directory domain tree
create interdomain keys for Kerberos trust relationships through a system involving local and “foreign” KDCs Windows 2003 active directory takes the trust to the “between forests” level
So now you know!
That’s all folks…