Download Presentation4 - University Of Worcester

COMP3371
Cyber Security
Richard Henson
University of Worcester
October 2015
Week 4: Public Key
Encryption & PKI

Objectives
 Explain need for sender to identify themselves;
why digital signatures are necessary in the real
world; how they can be implemented
 Apply public-private key encryption to the sending
of Internet email
 Explain PGP and PKI as two reliable techniques
for sending data securely from one place to
another… including verification of the sender
Symmetric v Asymmetric Key

Symmetric
one encryption/decryption key only

Asymmetric (public key…)
encryption: shared public key
decryption: unshared private key
each algorithm a one way function
Authentication of an
Email Message

Two potential issues with new email:
Is it intact & unmodified? (integrity)
can original authorship (authenticity)
be established

Requirements for Authentication:
Inputs (sender): secret key, message
output: message authentication code
When is Encryption alone
not enough!

Authentication:
 technique needed for verifying that the sender
really is who he or she claims to be

On local network
 covered through username/password

When data is on the move to a computer or
device from OUTSIDE…
 could come from ANYONE!
Authentication Methods

Paper correspondence?
by physical signature

Many available digital methods of providing a
sender signature
 e.g. Windows SIGVER (file signing)
» method of checking incoming files to ensure that they are from
a Microsoft approved source
 Java now uses a similar technique
Security & Wireless Data

Encryption (e.g. WPA) not enough
open access
decryption too easy…

Requires authentication as well for safe
transmission (best WPA-2)
use a known SSID to provide
authentication of remote device
other devices won’t get access…
Asymmetric (two key)
encryption

Diffie and Hellman (US, 1976)

Two keys:
 British scientists were secretly working on it much earlier
 Ellis, at GCHQ made the first breakthrough in 1970
 public key - known to everyone
 private or secret key - known only to the recipient of the
message
Example of PKE


John wants to send a secure message to
Jane…
He uses Jane's public key to encrypt the
message
Jane then uses her private key to decrypt it
Original public key method did not support
either encryption or digital signatures…
 therefore vulnerable to third party in the middle
eavesdroppers
Public Key Encryption (PKE)
Can work in two ways:
• private key encryption, public key decryption
• public key encryption, private key decryption
Unencrypted data
Private key
on sender’s
computer
Encrypted data
Data sent through the Internet
Encrypted data
Received by
recipient’s computer
Public key
on recipient
computer
Decrypted data
Public Key Encryption (PKE)

The public and private keys must be related
in such a way that
 only the public key can be used to encrypt
messages
 only the corresponding private key can be used to
decrypt them

In theory it is virtually impossible to deduce
the private key if you know the public key
Practical Public Key
Encryption systems


Include authentication of sender in
architecture
Variety of techniques developed:
Pretty Good Privacy (PGP)
Digital Certificates & Public Key
Infrastructure (PKI)
PGP (Pretty Good Privacy)

Developed by Philip Zimmerman (early 1990s)

Based on public-key method…
 official repository held at the Massachusetts Institute of
Technology
 spec for v2.0 at RFC #1991 https://tools.ietf.org/html/rfc1991
 plus authentication using a “web of trust”. Quote from RFC…
» “As time goes on, you will accumulate keys from other people that you may want
to designate as trusted introducers. Everyone else will each choose their own
trusted introducers. And everyone will gradually accumulate and distribute with
their key a collection of certifying signatures from other people, with the
expectation that anyone receiving it will trust at least one or two of the signatures.
This will cause the emergence of a decentralized fault-tolerant web of confidence
for all public keys.”

Convenient way to protect messages on the Internet:
 effective
 easy to use
 free
Using PGP (or not..)

To encrypt a message using PGP, the
receiver needs the PGP encryption package
 Zimmerman made it available for free download
from a number of Internet sources
Such an effective encryption tool that
the U.S. government actually brought a
lawsuit against Zimmerman!
 Problem:

PGP made public…
therefore available to enemies of the U.S.
US gov v Zimmerman (PGP)

Actual Lawsuit:
 selling munitions overseas without a license (used
>40 bit encryption)
 unpopular…
 after a public outcry, quietly dropped, law changed
in 2000

Still illegal to download PGP from US to many
other countries
Trust

Ever seen “Meet the Parents?”

Web of trust (personal) not practicable for
trust “in the business sense”

New system needed that followed “business
trust”
 you may not trust me, but you do trust my
business enough to accept that you’ll get paid!
 PGP web of trust wouldn’t be practicable!
 Different model needed…
LDAP and Public Key “lookup”


One of flaws with single key encryption…
 getting the key securely to the receiver
An alternative approach to the “web of trust”
the creation of an Internet lookup system that
could be used with PKE
 became known as LDAP (Lightweight Directory
Application Protocol)
» Netscape spec: https://www.ietf.org/rfc/rfc2251.txt
 “historic” involvement of Microsoft in Internet
Infrastructure
» implemented in VB

System expanded rapidly to form Public Key
Infrastructure (PKI)
The Public Key Repository

Store of public keys associated with
authentication data
 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

Infrastructure complete by 1999
 many still don’t know of it or how to implement it
even in 2015!
Digital Signatures/Digital-IDs

Unique 'security code' appended to an
electronic document
 the digital equivalent of a signature on a paper
document
» authenticates the sender
» permits the authenticity of the document to be proven
 also used the ensure the integrity of the message
sent

Signature and public key supplied packaged
within a digital certificate
 usually 30-day trial, then ~£100 for 2-year lease
Digital Certificate

A randomly generated number:
used to create the public-private key pair
creates the attachment to an electronic
message known as a digital signature

Anyone wishing to send an encrypted
email message for a digital certificate
from a (CA) Certificate Authority
Certificate Authorities

Example: verisign
 www.verisign.com


Trusted third-party organizations that issues
the digital certificates used to create publicprivate key pairs
The role of the CA is to guarantee that the
individual granted the unique certificate is, in
fact, who he or she claims to be.
Certificate Authorities

Usually, this means that the CA has an
arrangement with a financial institution, such
as a credit card company
 finance company provides it with information to
confirm an individual's claimed identity

CAs are a critical component in data security
and e-commerce because they guarantee
that the two parties exchanging information
really are who they claim to be
Supplying Digital
Certificates


On request, a CA can produce an encrypted
digital certificate for any applicant
Digital certificates contain:
 the applicant's private key
 a digital signature


CA makes its own public key readily available
on the Internet
The recipient of the encrypted message can
use the CA's public key to decode the digital
certificate attached to the message
Digital Certificate (continued)

The recipient:
verifies the digital signature as issued by
the CA
obtains the sender's public key and digital
signature held within the certificate
With this information, the recipient can
send an encrypted reply
 This procedure relies on the integrity of
the CA, and the user must be able to
trust them

Digital Signatures: an
increasing role in society…

Increased online delivery of traditionally paper
based correspondence & services…
 Contracts
 Government forms such as tax returns
 anything else that would require a hand-written
signature for authentication…

Information sent through the Internet
WITHOUT a digital signature…
 has NOT been authenticated!
 further means of proof of identity of sender should
be sought… could be FAXed
The trouble with HTTP


General Internet principle of “anyone can go
anywhere”
On a Windows system with www access:
 TCP can link directly to HTTP
 session layer authentication not invoked
 HTML data transferred directly to the presentation
and application layers for display

Problem:
 the data is visible to anyone else on the Internet
who may have access to that machine and the
data path to it!
Secure HTTP and the user
authentication problem

Makes use of the
potential for requiring
authentication at the
session layer

SSL protocol can require
a username/password
combination before data
passes through the
socket from transport
layer to application layer
application
authentication
required
transport
Computer Authentication


SSL is able to use the PKI
When a user first attempts to communicate
with a web server over a secure connection:
 that server will present the web browser with
authentication data
 presented as a server certificate (remember
those?)
» verifies that the server is who and what it claims to be

Works both ways…
 server may in return request client authentication
SSL and Encryption

Authenticating the user & server only helps
when the data is at its at its source or
destination
 data also needs to be protected in transit…

SSL working at level 5/6 also ensures that it
is:
» encrypted before being sent
» decrypted upon receipt and prior to processing for display
Confidentiality & Integrity

Encryption of SSL responses can be
Either Standard 40 bit RSA
» difficult to break confidentiality
Or Secure 128 bit RSA
» virtually impossible to “crack”

Guarantee that the data will not be
modified in transit by a third party
integrity therefore also maintained
Is an SSL Digital Certificate
Really Necessary?

Yes:
 for sites involved in e-commerce and therefore
involving digital payment
 any other business transaction in which
authentication of identity is important

No:
 if an administrator simply wants to ensure that
data being transmitted and received by the server
is private and cannot be snooped by anyone
eavesdropping on the connection
 In such cases, a self-signed certificate is sufficient
Https & “Web of Trust”
Based on individual trust networks built
up between individuals
 Possible to “self sign” a digital certificate

if someone trusts you, a self-signature may
be all they need
OpenPGP identiity certificates are designed
to be self-signed
Verisign Trust System

Web of Trust
OK for academics (“good” people?)
but bad” people can do business

Verisign system presented as an
alternative
developed so that people could trust
strangers in business transactions
financial institutions provide the “trust”
General Tips on
Running SSL

Designed to be as efficient as securely
possible but encryption/decryption is
computationally expensive from a
performance standpoint
not strictly necessary to run an entire Web
application over SSL
customary for a developer to decide which
pages require a secure connection and
which do not
When to use SSL

Whenever web pages require a secure
connection e.g.:
login pages
personal information pages
shopping cart checkouts
any pages where credit card information
could possibly be transmitted
Running HTTPS

Like http and ftp, a client-server service that
runs on the Web server
 uniquely designed so it will not run on a server
without a server certificate

Once the service has been set up, https will
require users to establish an encrypted
channel with the server
 ie https://
 rather than http://

Until the user does use https they will get an
error, rather than the pop up that proceeds the
secure web page
Running HTTPS



However, there still could be problems with
access…
The use of an encrypted channel running https
requires that the user's Web browser and the
Web server BOTH support the encryption
scheme used to secure the channel
For example:
 IF an IIS Web Server is set to use default
secure communication settings
 THEN the client Web browser must support a
session key strength of 40 bits, or greater
Accessing a Web Page
using HTTPS

If the client is to request a page that needs
SSL:
 in the HTML code that will call that page, prefix the
address with https:// instead of http:// and the
system will do the rest

Any pages which absolutely require a secure
connection should:
 check the protocol type associated with the page
request
 take the appropriate action if https: is not specified
Proof that Web Page has been
delivered securely using SSL

The first thing is that (depending on browser
settings) a pop up appears…
 this informs the client that they are entering a
secure client-server connection
 The pop up must be acknowledged to continue

The page will then be displayed:
 https:// will appear before the URL
 “lock” symbol appears on the bottom left of the
screen
Practical Limitations on the
Use of SSL


The SSL “handshake”, where the client
browser accepts the server certificate, must
occur before the HTTP request is accessed
As a result:
 the request information containing the virtual host
name cannot be determined prior to authentication
 it is therefore not possible to assign multiple
certificates to a single IP address

Using name-based virtual hosts on a secured
connection can therefore be problematic
Authentication Types/Factors

Classified 1, 2, or 3

Type 1: Knowledge based (what user knows)
 information provided based on person’s unique knowledge

Type 2: Token based (what user has/does)
 information comes from a token generated by a system
» tied in some way to the user logging on
 generally not considered a good idea on its own because
someone else could have stolen/copied it

Type 3: Characteristic based (what user is)
 biometric data from the person logging in
Which to use?

Ideally all three!

At least 2 factors recommended:
e.g. password or PIN number (type 1)
card based record (type 2)

For best security…
Type 3 retina scan or fingerprint (AS
WELL!)
One time Passwords (OTP)

Can only be used once…
 If user gets it wrong, becomes invalid…
» locked out
» has to contact administrator to reset

Implemented as a type 2 factor
 password characters randomly generated

If used properly…
 very secure indeed
 problem: degree of randomness…
1/2/3 factor authentication
& Identity Theft

Factor 1 authentication alone is not
enough
username/password may be stolen (or
even borrowed with permission!)

Need proof:
something only that person would know…
something unique to that person
Biometric data)

More on this later…
Single Sign On (SSO)

Logon once…
 authenticated for all servers in that environment

More a convenience matter than a security
issue
 only one set of authentication factors needed
 single username/authentication factor database
covering all servers

SOME very secure environments have
dropped SSO in favour of separate logon for
each server
 arguable whether this is necessary but avoids the
“all eggs in one basket” argument
Password Administration

Three aspects:
 Selection
» should be a company IS policy that includes choice of
password
» generally no. of characters is a good match with strength
– the higher the better
 Management
» selection & expiration period must comply with policy
 Control
» policy should be enforced by the network itself
» usually achieved through use of “group policies”
Access Control Techniques

Discretionary (DAC)
 access to files/resources controlled by system
administrator
 Achieved through ACLs (Access Control Lists)
» consist of ACEs (Access Control Entries)
 the granting of access can be audited

Mandatory (MAC)
 access dependent on rules/classifications
 classification:
» hierarchical or compartmentalised, or hybrids
» dependent on security clearance levels
Next session will explore…
Authentication and access control
to websites, remote organisational
servers
It will also introduce
Active Directory