Transcript slides

Advanced
Database Topics
Copyright © Ellis Cohen 2002-2005
Database Security
These slides are licensed under a Creative Commons
Attribution-NonCommercial-ShareAlike 2.5 License.
For more information on how you may use them,
please see http://www.openlineconsult.com/db
1
Overview of Lecture
Database Security Overview
Discretionary Access Control Mechanisms
Delegation & Revocation
Dynamic Views &
Fine-Grained Security Policies
User Identification
Authentication & Encryption
© Ellis Cohen 2002 - 2005
2
Database Security
Overview
© Ellis Cohen 2002 - 2005
3
Database Security Objectives
Secrecy/Privacy
Users can't see what they're not
supposed to
Integrity
Users can't modify what they're
not supposed to
Availability
Users should not be prevented
from doing what they are allowed
to do
© Ellis Cohen 2002 - 2005
4
Problems, Policies, Mechanisms & Solutions
Security Problem
General description of a situation in
which a user is able to inappropriately
access or modify information
Security Policy
Specifies who is authorized to do what
Security Mechanism
Facilities provides by a system that can
be used to enforce some set of security
policies
Security Solution
Use of a Security Mechanism to solve a
problem or enforce a policy
© Ellis Cohen 2002 - 2005
5
Database Security Policies
Access Control Policy
Specify limitations related to what
a user is able to access
Information Flow Control Policy
Specify limitations related to what
kind of information a user is able
to find out about
Inference Control Policy
Specify limitations related to what
kind of inferences a user might be
able to make
© Ellis Cohen 2002 - 2005
6
Database Security Mechanisms
Most Security Mechanisms are based on
Access Control
– determining whether a user can access a
particular piece of data or do a specific
operation with it
Mandatory Access Control Mechanisms
– Decision to allow or deny access to a user is
based on the characteristics of the data and the
user
– Used to enforce information flow control
policies
Discretionary Access Control Mechanisms
– Decision to allow/deny access is based on the
discretion of some set of users
– Used to enforce access control policies (and
sometimes information flow control policies)
© Ellis Cohen 2002 - 2005
7
Discretionary
Access Control
Mechanisms
(DAC)
© Ellis Cohen 2002 - 2005
8
Database Users & Schemas
Each database user (e.g. SCOTT) has their
own schema: the set of database objects,
e.g. tables, views, packages, etc. that they
own
If you have connected to the database as
TOMMY, then you can try to access SCOTT's
Emps table by writing SCOTT.Emps
SCOTT> SELECT * FROM Emps
TOMMY> SELECT * FROM SCOTT.Emps
Indicates that we are in SQL*Plus
connected as TOMMY
© Ellis Cohen 2002 - 2005
9
Privileges
Privilege
Right of a database user (e.g. TOMMY) to use a
database object (e.g. table, view, procedure,
function, package, etc.) in a particular way
Discretionary Access Control Model
A database user has all the privileges for any object
it owns (i.e. are in its schema)
Database users can
• grant privileges to other database users
• revoke privileges they have granted
TOMMY> SELECT * FROM SCOTT.Emps
will not be allowed unless TOMMY has been granted
the privilege to access Emps (by SCOTT, or some
other user who has the power to do so)
© Ellis Cohen 2002 - 2005
10
Table Privileges
Privileges on tables include
SELECT - query table
UPDATE - update (specific columns in) table (also
requires SELECT)
INSERT - insert rows in table (can limit columns w
explicitly set values)
DELETE - delete rows from table
Examples
SCOTT> GRANT SELECT ON Emps TO JOE, MARY
JOE> SELECT * FROM SCOTT.Emps
SCOTT> GRANT SELECT, UPDATE(ename) ON Emps
TO TOMMY
Be very careful about granting
anything but SELECT access
© Ellis Cohen 2002 - 2005
11
Selective READ Access Problem
Suppose SCOTT is the administrator (and
owner) of the company's employee
information table, Emps (empno, ename,
deptno, addr, mgr, job, sal )
SCOTT wants to allow SMITH & ADAMS to be
able to see name and address information
in Emps, but no other information.
What SQL commands does SCOTT execute to
ensure that SMITH or ADAMS have the
appropriate access to the Emps table.
© Ellis Cohen 2002 - 2005
12
Granting Access to Views
SCOTT> GRANT SELECT(ename,addr) ON Emps
TO SMITH, ADAMS
doesn't work in most databases.
Here's what does work:
SCOTT> CREATE VIEW NameAddrView AS
SELECT ename, addr
FROM Emps
Access can
be granted to
a view instead
of to the
underlying
table
SCOTT> GRANT SELECT ON NameAddrView
TO SMITH, ADAMS
Now SMITH can execute (for example)
SMITH> SELECT * FROM SCOTT.NameAddrView
WHERE ename = 'BLAKE'
Suppose SCOTT only wants to let SMITH and ADAMS see
names & addresses of tuples in Emps with a job of CLERK?
© Ellis Cohen 2002 - 2005
13
Granting Access to Restricted Views
SCOTT> CREATE VIEW NameAddrView AS
SELECT ename, addr
FROM Emps
WHERE job = 'CLERK'
SCOTT> GRANT SELECT ON NameAddrView
TO SMITH, ADAMS
Now SMITH can execute
SMITH> SELECT * FROM SCOTT.NameAddrView
WHERE ename = 'BLAKE'
© Ellis Cohen 2002 - 2005
14
Secure Modification Problem
Supose that SCOTT wants to allow
SMITH to change anyone's address
in the Emps table.
What SQL commands (views & grants
only) does SCOTT execute to ensure
that SMITH has the appropriate
capabilities?
© Ellis Cohen 2002 - 2005
15
Secure Modification Solution
SCOTT> CREATE VIEW NameAddrView AS
SELECT ename, addr FROM Emps
SCOTT> GRANT SELECT, UPDATE(addr) ON
NameAddrView TO SMITH
Now SMITH can execute
SMITH> UPDATE SCOTT.NameAddrView
SET addr = '31 Upham Way, …'
WHERE ename = 'BLAKE'
© Ellis Cohen 2002 - 2005
16
Granting Access to Operations
Suppose SCOTT has defined a stored DB function
GetDeptName( deptno ) which returns the name of
the department with the specified dept number
If TOMMY is connected, TOMMY can try to use that
function by doing
TOMMY> EXECUTE pl( SCOTT.GetDeptName( 30 ) )
(Assuming that pl is TOMMY's function which prints the value passed to it)
This will only be allowed if SCOTT has granted TOMMY
the privilege to EXECUTE GetDeptName
SCOTT> GRANT EXECUTE ON GetDeptName TO TOMMY
© Ellis Cohen 2002 - 2005
17
Granting Access to
Packaged DB Operations
Some databases (e.g. Oracle) allow stored DB
operations to be organized by package. For
example, GetDeptName might be defined within
SCOTT's package DeptPkg
If TOMMY is connected, TOMMY can try to execute
that function by doing
TOMMY> EXECUTE pl(
SCOTT.DeptPkg.GetDeptName( 30 ) )
This will only be allowed if SCOTT has granted
TOMMY the privilege to EXECUTE DeptPkg
SCOTT> GRANT EXECUTE ON DeptPkg TO TOMMY
© Ellis Cohen 2002 - 2005
18
Delegation &
Revocation
© Ellis Cohen 2002 - 2005
19
Delegation
Suppose SCOTT created a view, but doesn't want to
decide who should be granted SELECT access to it.
Can SCOTT delegate that to another user?
Yes, by granting SELECT with the GRANT option
SCOTT> GRANT SELECT ON NameAddrView
TO FLICKA
WITH GRANT OPTION
FLICKA> GRANT SELECT
ON SCOTT.NameAddrView
TO MERCURIO
Who can grant a privilege on an object?
– Creator of an object
– A user who was granted the privilege with the GRANT
option (i.e. and so becomes an administrator for that
privilege)
Suppose FLICKA is out sick.
Can FLICKA delegate the job of granting SELECT
access to her friend SUE?
© Ellis Cohen 2002 - 2005
20
Transitive Delegation
Who can grant a privilege with the GRANT
OPTION?
– Creator of an object
– A user who was granted the privilege with the
GRANT option (i.e. and so becomes an
administrator for that privilege)
SCOTT> GRANT SELECT ON NameAddrView
TO FLICKA WITH GRANT OPTION
FLICKA> GRANT SELECT ON SCOTT.NameAddrView
TO SUE WITH GRANT OPTION
SUE> GRANT SELECT ON SCOTT.NameAddrView
TO MERCURIO
Can SCOTT prevent FLICKA from also
delegating the privilege to grant
(e.g. granting SUE the GRANT OPTION)?
© Ellis Cohen 2002 - 2005
21
Controlling Transitive Delegation
If SCOTT delegates the privilege to grant to
FLICKA (by granting FLICKA a privilege
with the GRANT OPTION)
can SCOTT prevent FLICKA from also
delegating the privilege to grant
(e.g. granting SUE the GRANT OPTION)?
The standard DAC mechanism does
not allow this problem to be solved
directly.
We will see later how to define a
dynamic security mechanism which
can be used to control transitive
delegation.
© Ellis Cohen 2002 - 2005
22
Revocation
Whenever a database user grants another database
user a privilege, the user can later revoke that
privilege
After SCOTT grants TOMMY access to Emps
SCOTT> GRANT SELECT, UPDATE(ename,sal),
INSERT ON Emps TO TOMMY
SCOTT can later revoke any or all of those privileges
from TOMMY
SCOTT> REVOKE SELECT, UPDATE(sal)
ON Emps FROM TOMMY
© Ellis Cohen 2002 - 2005
23
Revocation of Delegation
After SCOTT grants FLICKA access to NameAddrView with the
GRANT OPTION
SCOTT> GRANT SELECT ON NameAddrView
TO FLICKA WITH GRANT OPTION
SCOTT can later revoke the SELECT privilege from FLICKA, Of
course, this means that FLICKA is no longer an administrator for it.
SCOTT> REVOKE SELECT ON NameAddrView
FROM FLICKA
It is also possible (in standard SQL, but not Oracle) for SCOTT to
just revoke the GRANT OPTION for SELECT from FLICKA. This still
allows FLICKA to continue to simply use the SELECT privilege
SCOTT> REVOKE GRANT OPTION FOR SELECT ON NameAddrView
FROM FLICKA
© Ellis Cohen 2002 - 2005
24
Basic Revocation Questions
Suppose SCOTT granted JOE the INSERT privilege to
the same table twice, and then revoked it once.
Should JOE still be able to insert into the table?
If both FLICKA and SAM grant JOE the INSERT
privilege to SCOTT's table, and then just FLICKA
revokes it, should JOE still be able to insert into
the table?
If SCOTT grants the INSERT privilege with GRANT
OPTION to JOE, and JOE grants the INSERT
privilege to SUE, then if SCOTT revokes these
privileges from JOE, should SUE still be able to
insert into the table (either immediately or the
next time SUE logs in)?
What are the implications for how information
about grants and privileges is maintained in the
database?
© Ellis Cohen 2002 - 2005
25
Revocation & Trust
If both FLICKA and SAM grant JOE the INSERT privilege
to SCOTT's table, and then just FLICKA revokes it, should
JOE still be able to insert into the table?
Trust Rules:
YES. As long as someone trusts JOE, JOE should
be able to access the table. FLICKA sometimes
revokes trust capriciously, whereas SAM checks
more thoroughly into whether access should be
revoked.
Distrust Rules:
NO. As long as someone stops trusting JOE, JOE's
access should be revoked. SAM sometimes is
inattentive, while FLICKA is more diligent.
In Standard DAC, Trust Rules, which is also commutative: The
sequence [FLICKA grants, SAM grants, FLICKA revokes] has the
same result as [FLICKA grants, FLICKA revokes, SAM grants].
BUT, both models are reasonable, as well as variants based on
degrees of trust.. A dynamic security mechanism would have to
be used to support other models.
© Ellis Cohen 2002 - 2005
26
Revocation Control Questions
If both FLICKA and SAM have the
INSERT privilege with the GRANT
OPTION for a table, and FLICKA
grants the INSERT privilege to JOE,
should SAM be able to revoke that
privilege from JOE?
If SCOTT grants the INSERT privilege
with GRANT OPTION to JOE, and
JOE grants INSERT to SUE, should
SCOTT be able to revoke INSERT
directly from SUE?
© Ellis Cohen 2002 - 2005
27
Distributed vs Centralized Administration
Distributed Administration
A user can revoke a privilege from
another user only if the user previously
granted the privilege
Centralized Administration
A group of administrators (of a privilege)
can not only grant, but also revoke the
privilege from any other user (whether
or not the administrator granted the
privilege)
© Ellis Cohen 2002 - 2005
28
GRANT OPTION
for Distributed Administration
The GRANT OPTION is used for
distributed administration
A user granted the GRANT OPTION
for a privilege can grant that
privilege (with or without the
GRANT OPTION)
A privilege can only be revoked by
the user who granted that
privilege
© Ellis Cohen 2002 - 2005
29
ADMIN OPTION
for Centralized Administration
The ADMIN OPTION is used for
centralized administration
A user granted the ADMIN OPTION
for a privilege can grant that
privilege (with or without the
ADMIN OPTION)
A privilege can be revoked by any
user who has the ADMIN OPTION
for that privilege (including from
another administrator)
Oracle uses the ADMIN OPTION only for roles and
system privileges, and does NOT allow the GRANT
OPTION to be used in these cases.
© Ellis Cohen 2002 - 2005
30
Potential Admin Option Example
Suppose tables could use centralized
administration (not standard or supported in
commercial databases, including Oracle)
SCOTT> GRANT SELECT ON Emps TO BILL WITH
ADMIN OPTION
-- not in Oracle or SQL Standard
BILL> GRANT SELECT ON SCOTT.Emps
TO MERCURIO
Then SCOTT could revoke directly from MERCURIO
SCOTT> REVOKE SELECT ON Emps
FROM MERCURIO
NOT Legal in
Standard SQL
If it were legal though, SCOTT would need to determine
who has access to Emps. How wold SCOTT do that?
© Ellis Cohen 2002 - 2005
31
Accessing Metadata
Relational Databases not only store user
data in tables, but they store their own
data in tables as well (including metadata
– information about user tables)
One or more system tables contain
information about grants of privileges.
Views of these tables are granted to users –
in particular, each user is generally
granted a view that shows who has been
granted privileges on that user's objects.
This does NOT imply that the DB must create a separate view
for every user. The DB creates a single dynamic view which
shows a different subset of the system table to each user.
© Ellis Cohen 2002 - 2005
32
Cascading Revocation
Suppose
A grants a privilege for an object to B
(with the GRANT or ADMIN option),
Then B grants it to C
then A revokes it from B
Without specifying "CASCADE"
- If B had the GRANT option:
The revoke fails
- If B had the ADMIN option:
It is revoked from B, but not from C
With "CASCADE"
- It is revoked from C as well as B.
(Note: Oracle does not support CASCADE,
however, it is always implied for distributed
revocation)
© Ellis Cohen 2002 - 2005
33
System Privileges (Oracle)
Privilege to allow a user to
– operate as an administrator
– with respect to
• The schema of the user (w that role)
• The entire database
Examples
SYS> GRANT Create Procedure TO JOE
– JOE can now create procedures in his schema
SYS> GRANT Create Any Procedure TO JOE
– JOE can now create procedures in ANY schema
SYS> GRANT Create Any Table TO JOE
WITH ADMIN OPTION
– JOE can now also grant/revoke that privilege
to/from any other user
© Ellis Cohen 2002 - 2005
34
Dynamic Views
& Fine-Grained
Access Control
© Ellis Cohen 2002 - 2005
35
Fine-Grained
Access Control
Decision to Permit/Deny access
may be based on
– a dynamic property of a user
– a dynamic property of the system
(including system time)
Using grant/revoke is
ineffective/inappropriate
Need a better way to control
access
© Ellis Cohen 2002 - 2005
36
Generalized Security Policies
Permit/Deny are the extremes of
possible responses to a user
command
For Read Access
May want to limit (e.g. using a view)
what the user can see, or provide
default or altered information in place
of actual values
For Write Access
May want to allow only part of a
modification, or add a side effect that
moderates the effect of the
modification
© Ellis Cohen 2002 - 2005
37
Oracle's USER pseuodocolumn
SELECT empno FROM Emps
WHERE ename = USER
-- returns the employee number of
the employee whose name is the
same as the current user
-- This kind of code is fairly
common if the users of the
system are the employees
© Ellis Cohen 2002 - 2005
38
User-Based Dynamic View Problem
Suppose BLAKE & ADAMS need to be
able to change their own address in
Emps?
What SQL commands (views & grants
only) does SCOTT execute to ensure
that BLAKE and ADAMS have the
appropriate access to Emps to
change their own address, but can't
make other changes
Solve this using a single dynamic
view – a view which shows
different information to different
users!
© Ellis Cohen 2002 - 2005
39
User-Based Dynamic Views
SCOTT> CREATE VIEW ChangeMyAddrView AS
SELECT addr FROM Emps
WHERE ename = USER
Security Policy
SCOTT> GRANT SELECT, UPDATE ON
ChangeMyAddrView
TO BLAKE, ADAMS
Now BLAKE can execute
BLAKE> UPDATE SCOTT.ChangeMyAddrView
SET addr = '31 Upham Way, …'
© Ellis Cohen 2002 - 2005
40
User-Based Update Control
Suppose the mgr field of an employee
holds the DB login id of their manager.
Suppose only an employee's manager can
change their salary?
What SQL commands (views & grants
only) does SCOTT execute to ensure
managers can only change the salaries
of the employees they directly manage.
Solve this using a single dynamic view!
© Ellis Cohen 2002 - 2005
41
User-Based Update Control
SCOTT> CREATE VIEW ChangeMySalView AS
SELECT empno, ename, sal FROM Emps
WHERE mgr = USER
Security Policy Predicate
SCOTT> GRANT SELECT, UPDATE(sal) ON
ChangeMyAddrView
TO PUBLIC
Now to give all of his reports a 10% raise,
BLAKE can execute
Or better,
grant this just
to all the
managers
BLAKE> UPDATE SCOTT.ChangeMySalView
SET sal = sal * 1.1
Suppose the mgr field of an employee
holds the empno of their manager.
Now what does SCOTT do?
© Ellis Cohen 2002 - 2005
42
Using Views with Subqueries
SCOTT> CREATE VIEW ChangeMySalView AS
SELECT empno, ename, sal FROM Emps
WHERE mgr =
(SELECT empno FROM Emps
WHERE ename = USER)
SCOTT> GRANT SELECT, UPDATE(sal) ON
ChangeMyAddrView
Or better,
TO PUBLIC
grant this just
to the
managers
© Ellis Cohen 2002 - 2005
43
Selective Denial
Suppose SCOTT grants SELECT ON
NameAddrView with the GRANT option to
certain users (e.g. FLICKA), but wants to
ensure that BLAKE cannot ever SELECT
using NameAddrView, no matter how this
privilege is granted to BLAKE
SQL Server uses DENY for this
DENY SELECT ON NameAddrView TO BLAKE
If DENY were not available, how could SCOTT
use a dynamic view to ensure that BLAKE could
never SELECT using NameAddrView
© Ellis Cohen 2002 - 2005
44
Enforcing Selective Denial
SCOTT> CREATE VIEW XNameAddrView AS
SELECT * FROM NameAddrView
WHERE USER <> 'BLAKE'
or
SCOTT> CREATE VIEW XNameAddrView AS
SELECT * FROM NameAddrView
WHERE CheckIfAllowed()
SCOTT> GRANT SELECT ON
XNameAddrView TO FLICKA
WITH GRANT OPTION
© Ellis Cohen 2002 - 2005
45
User
Identification
© Ellis Cohen 2002 - 2005
46
Using Identification Functions
Suppose
• An employee's ename has NOTHING to do with
their DB login id
• SCOTT has written a function AuthPkg.GetUser,
which returns the employee number of the
current user, and has granted the EXECUTE
privilege for AuthPkg to every employee
• BLAKE & ADAMS need to be able to change their
own address in Emps
What additional SQL commands (views & grants
only) does SCOTT execute to ensure that BLAKE
and ADAMS have the appropriate access to Emps
to change their own address, but can't make
other changes
Solve this using a single view!
© Ellis Cohen 2002 - 2005
47
Identity-Based Views
SCOTT> CREATE VIEW ChangeMyAddrView AS
SELECT addr FROM Emps
WHERE empno = SCOTT.AuthPkg.GetUser()
SCOTT> GRANT SELECT, UPDATE ON
ChangeMyAddrView
TO BLAKE, ADAMS
Now BLAKE can execute
BLAKE> UPDATE SCOTT.ChangeMyAddrView
SET addr = '31 Upham Way, …'
How is AuthPkg.GetUser implemented?
© Ellis Cohen 2002 - 2005
48
Implementing User Identity
User Identification requires
Registration.
Registration associates a user's DB
login id with their employee
number. This may be stored in a
table in the database, or externally
(e.g. an LDAP directory)
AuthPkg.GetUser finds out the DB
login ID of the current user, and
looks up and returns the
corresponding employee number.
© Ellis Cohen 2002 - 2005
49
Identity-Based Update Control
Suppose the mgr field of an employee
holds the employee # of their manager.
Suppose only an employee's manager can
change their salary?
What SQL commands (views & grants
only) does SCOTT execute to ensure
managers can only change the salaries
of the employees they directly manage.
Solve this using a single view!
© Ellis Cohen 2002 - 2005
50
Answer: Identity-Based Update Control
SCOTT> CREATE VIEW ChangeSalView AS
SELECT empno, ename, sal FROM Emps
WHERE mgr = SCOTT.AuthPkg.GetUser()
SCOTT> GRANT SELECT, UPDATE(sal) ON
ChangeSalView TO PUBLIC
Suppose an employee's dept # is given by the
deptno field
Suppose a department manager is the one
employee in a dept whose job is 'DEPTMGR'
Suppose a dept mgr can change the salary of
every employee in their dept except their own
How does SCOTT arrange this?
© Ellis Cohen 2002 - 2005
51
Authentication
& Encryption
© Ellis Cohen 2002 - 2005
52
Principal
Who wants to access a database?
• A user
• An application (e.g. a web service)
• etc …
Principal:
The entity in a computer system to which
privileges are granted
© Ellis Cohen 2002 - 2005
53
Authentication in a Single
Machine Environment
Authentication
Verifying the identity of a principal making a
request
How does the database know who is
making a request?
– Determined at connection time
– Remains associated with the connection
How does the database know who is
establishing a connection
– Provide a userid and password to the DB when
making a connection
– Ask the operating system to identify the
(userid of the) principal making the connection
[Single signon]
© Ellis Cohen 2002 - 2005
54
Corporate Network Security
Suppose
user is on one machine
database on another
Problem
Secure (mutual) authentication
Secure identification of user to database
Secure identification of database to user
Secure communication between two
machines: Use encryption
With potentially malicious individuals
Eavesdrop on communication line
Remove/modify/insert/replay packets
© Ellis Cohen 2002 - 2005
55
Primitive Communication Attacks
© Ellis Cohen 2002 - 2005
56
Security Attacks
Passive Attacks (sniffing/snooping/
eavesdropping/monitoring):
– Obtain message contents (esp sensitive data,
particularly passwords)
– Monitor traffic flows
– Deduce secrets (especially "keys")
Active Attacks
– Masquerade of one entity as some other
(spoofing)
– Replay previous messages (once or many
times)
– Modify messages in transit
– Denial of service (flooding)
– Viruses/Worms
© Ellis Cohen 2002 - 2005
57
Symmetric/Private Key Encryption
Plain-text input
“The quick
brown fox
jumps over
the lazy
dog”
Cipher-text
“AxCv;5bmEseTfid3)f
GsmWe#4^,sdgfMwir3
:dkJeTsY8R\s@!q3%”
Encryption
Security
depends
on the
secrecy
of the
key,
Plain-text output
“The quick
brown fox
jumps over
the lazy
dog”
Decryption
Same key
not the
secrecy of
the
algorithm
(shared secret)
© Ellis Cohen 2002 - 2005
58
Symmetric Key-Based Confidentiality
For A to communicate with a service B
• They both share a private key kAB that can
be used both to encrypt and decrypt data
• A uses the key to encrypt data -- [data]kAB
• A sends [data]kAB to B
Eavesdroppers who don't know the key see
"random" bits; packets they insert will (once
decryption is attempted) be identified as fake
• B uses kAB to decrypt [data]kAB and gets
back the data
If a key is used too heavily,
it can be compromised
• If A and B continue to use kAB, it can be
deduced by an eavesdropper
© Ellis Cohen 2002 - 2005
59
Session Keys
If a key is used too heavily,
it can be compromised
An eavesdropper can deduce a secret key if
it sees a long enough sequence of
encrypted messages
For A to communicate with a service B
• They both share a private key kAB
• When A starts a session with B, B creates a
one-time private session key, kS, and returns
[kS]kAB to A
• A uses kAB to decrypt the message and get
kS, and A & B subsequently use kS to encypt
their messages for the rest of the session
© Ellis Cohen 2002 - 2005
60
Simple Password-Based Authentication
Assumption: Database's key, kDB, is securely
embedded on each user's local host
Sample Simplified Protocol:
• User process
– creates a one-time private session key, kS
– Sends [userid, passwd, kS]kDB
to database server
• Database server
– uses kDB to obtain userid, passwd, kS
– checks userid and passwd
• Database server and user process use kS to
set up a secure encrypted connection
– Problem: kDB can be too easily compromised
which then completely compromises system
© Ellis Cohen 2002 - 2005
61
Simple Key-Based Security
Assumption: Every user has registered their
private key with the database server
• User process
– Send the user's name to the database server
• Database service
– Gets the name and looks up the user's registered
key, kUser
– Creates a one-time private session key, kS
– Sends [name, kS]kUser back to user process
• User process
– Extracts name & checks if it is its own name
(Guarantees response came from DB server &
that decryption was successful)
– Extracts kS
• Database server and user process use kS to
set up a secure encrypted connection
© Ellis Cohen 2002 - 2005
62
Corporate Network
Authentication Approaches
• Database Password Approach:
maintains set of userids & passwords
• Operating System Approach:
uses network login identity
(single signon)
• Authentication Service Approach
(e.g. Kerberos):
Each user and service registers a single private key
with Kerberos
Kerberos mutually authenticates users and services
using their registered private keys, and creates a
session key for their communication
Avoids having each service handle key registration,
means that a user only needs one key, rather
than one key for each service
© Ellis Cohen 2002 - 2005
63
Public Networks & Public Keys
Registering passwords or private
keys across public network is not
very scalable or secure
Secure key distribution across a
public network is a significant
problem.
Instead, use public keys
© Ellis Cohen 2002 - 2005
64
Public Key Encryption
public
private
Public key encryption is based on the
combination of a public key and a private
key, which are generated as a matched pair
private
The keys are mathematically related but it is
computationally infeasible to deduce a
private key from its public key
Private keys are kept secret - often by being
stored in a tamper-resistant chip
SMART
CARD
123 89 3486
M
Public keys are just that - public!
© Ellis Cohen 2002 - 2005
65
Public Key Encryption
Plain-text input
Cipher-text
“The quick
brown fox
jumps over
the lazy
dog”
“AxCv;5bmEseTfid3)f
GsmWe#4^,sdgfMwir3
:dkJeTsY8R\s@!q3%”
Encryption
Encrypt
with the
receiver's
public key
Plain-text output
“The quick
brown fox
jumps over
the lazy
dog”
Decryption
The
message
can only be
decrypted
with their
private key
public
© Ellis Cohen 2002 - 2005
66
Encrypt & Decrypt
Public key systems use a pair of keys,
K (public) and K' (private):
– You can't decrypt [data]K just by
knowing K. You need to know K'
[[data]K]K' => data
– Also goes the other way!
[[data]K']K => data
© Ellis Cohen 2002 - 2005
67
Secure Mutual Authentication
Database Server advertises its public key, DK
A user's public key is UK.
User sends the following to the DB server
– [UK, nonce]DK (a nonce is a random value,
different for every initial request)
Database server
– Uses DK' to extract UK & nonce
– Uses UK to identify user (or user could have also
sent a name in the initial request)
– creates private session key, kS
– sends [nonce, kS]UK to user process
User process
– uses UK' to extract nonce and kS
– checks nonce (prevents masquerading)
Database service and user process use kS to
set up a secure encrypted connection
© Ellis Cohen 2002 - 2005
68