1

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

© Ellis Cohen 2002 - 2005 2

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 3

Database SecurityOverview

© Ellis Cohen 2002 - 2005 4

Database Security Objectives

Secrecy/PrivacyUsers can't see what they're not

supposed to

IntegrityUsers can't modify what they're

not supposed to

AvailabilityUsers should not be prevented

from doing what they are allowed to do

© Ellis Cohen 2002 - 2005 5

Problems, Policies, Mechanisms & Solutions

Security ProblemGeneral description of a situation in which

a user is able to inappropriately access or modify information

Security PolicySpecifies who is authorized to do what

Security MechanismFacilities provides by a system that can be

used to enforce some set of security policies

Security SolutionUse of a Security Mechanism to solve a

problem or enforce a policy

© Ellis Cohen 2002 - 2005 6

Database Security Policies

Access Control PolicySpecify limitations related to what a user is able to access

Information Flow Control PolicySpecify limitations related to what kind of information a user is able to find out about

Inference Control PolicySpecify limitations related to what kind of inferences a user might be able to make

© Ellis Cohen 2002 - 2005 7

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 8

DiscretionaryAccess ControlMechanisms

(DAC)

© Ellis Cohen 2002 - 2005 9

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 EmpsTOMMY> SELECT * FROM SCOTT.Emps

Indicates that we are in SQL*Plus connected as TOMMY

© Ellis Cohen 2002 - 2005 10

PrivilegesPrivilege

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.Empswill 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 11

Table Privileges

Privileges on tables includeSELECT - query tableUPDATE - 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

ExamplesSCOTT> GRANT SELECT ON Emps TO JOE, MARYJOE> 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 12

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 13

Granting Access to ViewsSCOTT> GRANT SELECT(ename,addr) ON Emps

TO SMITH, ADAMSdoesn't work in most databases.

Here's what does work:SCOTT> CREATE VIEW NameAddrView AS

SELECT ename, addr FROM Emps

SCOTT> GRANT SELECT ON NameAddrViewTO SMITH, ADAMS

Now SMITH can execute (for example)

SMITH> SELECT * FROM SCOTT.NameAddrViewWHERE ename = 'BLAKE'

Suppose SCOTT only wants to let SMITH and ADAMS see names & addresses of tuples in Emps with a job of CLERK?

Access can be granted to a view instead

of to the underlying

table

© Ellis Cohen 2002 - 2005 14

Granting Access to Restricted Views

SCOTT> CREATE VIEW NameAddrView ASSELECT ename, addr FROM Emps WHERE job = 'CLERK'

SCOTT> GRANT SELECT ON NameAddrViewTO SMITH, ADAMS

Now SMITH can execute

SMITH> SELECT * FROM SCOTT.NameAddrViewWHERE ename = 'BLAKE'

© Ellis Cohen 2002 - 2005 15

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 16

Secure Modification Solution

SCOTT> CREATE VIEW NameAddrView ASSELECT 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 17

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 18

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 19

Delegation & Revocation

© Ellis Cohen 2002 - 2005 20

Delegation

SCOTT> GRANT SELECT ON NameAddrView TO FLICKAWITH GRANT OPTION

FLICKA> GRANT SELECT ON SCOTT.NameAddrViewTO MERCURIO

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

Suppose FLICKA is out sick.Can FLICKA delegate the job of granting SELECT

access to her friend SUE?

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)

© Ellis Cohen 2002 - 2005 21

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)

Can SCOTT prevent FLICKA from also delegating the privilege to grant

(e.g. granting SUE the GRANT OPTION)?

SCOTT> GRANT SELECT ON NameAddrView TO FLICKA WITH GRANT OPTION

FLICKA> GRANT SELECT ON SCOTT.NameAddrViewTO SUE WITH GRANT OPTION

SUE> GRANT SELECT ON SCOTT.NameAddrViewTO MERCURIO

© Ellis Cohen 2002 - 2005 22

Controlling Transitive Delegation

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.

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)?

© Ellis Cohen 2002 - 2005 23

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 24

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 25

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 26

Revocation & Trust

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.

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?

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 27

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 28

Distributed vs Centralized Administration

Distributed AdministrationA user can revoke a privilege from another user only if the user previously granted the privilege

Centralized AdministrationA 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 29

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 30

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 31

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 EmpsFROM MERCURIO

If it were legal though, SCOTT would need to determine who has access to Emps. How wold SCOTT do that?

NOT Legal in Standard SQL

© Ellis Cohen 2002 - 2005 32

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 33

Cascading RevocationSuppose

A grants a privilege for an object to B (with the GRANT or ADMIN option),

Then B grants it to Cthen 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 34

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 JOEWITH ADMIN OPTION

– JOE can now also grant/revoke that privilege to/from any other user

© Ellis Cohen 2002 - 2005 35

Dynamic Views& Fine-GrainedAccess Control

© Ellis Cohen 2002 - 2005 36

Fine-GrainedAccess 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 37

Generalized Security Policies

Permit/Deny are the extremes of possible responses to a user command

For Read AccessMay 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 AccessMay want to allow only part of a

modification, or add a side effect that moderates the effect of the modification

© Ellis Cohen 2002 - 2005 38

Oracle's USER pseuodocolumn

SELECT empno FROM EmpsWHERE 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 39

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 40

User-Based Dynamic Views

SCOTT> CREATE VIEW ChangeMyAddrView ASSELECT addr FROM EmpsWHERE ename = USER

SCOTT> GRANT SELECT, UPDATE ON ChangeMyAddrViewTO BLAKE, ADAMS

Now BLAKE can execute

BLAKE> UPDATE SCOTT.ChangeMyAddrView SET addr = '31 Upham Way, …'

Security Policy

© Ellis Cohen 2002 - 2005 41

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 42

User-Based Update Control

SCOTT> CREATE VIEW ChangeMySalView ASSELECT empno, ename, sal FROM EmpsWHERE mgr = USER

SCOTT> GRANT SELECT, UPDATE(sal) ON ChangeMyAddrViewTO PUBLIC

Now to give all of his reports a 10% raise,BLAKE can execute

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?

Or better, grant this just

to all the managers

Security Policy Predicate

© Ellis Cohen 2002 - 2005 43

Using Views with Subqueries

SCOTT> CREATE VIEW ChangeMySalView ASSELECT empno, ename, sal FROM EmpsWHERE mgr = (SELECT empno FROM Emps WHERE ename = USER)

SCOTT> GRANT SELECT, UPDATE(sal) ON ChangeMyAddrViewTO PUBLIC Or better,

grant this just to the

managers

© Ellis Cohen 2002 - 2005 44

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 45

Enforcing Selective Denial

SCOTT> CREATE VIEW XNameAddrView ASSELECT * FROM NameAddrView WHERE USER <> 'BLAKE'

orSCOTT> CREATE VIEW XNameAddrView AS

SELECT * FROM NameAddrView WHERE CheckIfAllowed()

SCOTT> GRANT SELECT ON XNameAddrView TO FLICKAWITH GRANT OPTION

© Ellis Cohen 2002 - 2005 46

UserIdentification

© Ellis Cohen 2002 - 2005 47

Using Identification FunctionsSuppose

• 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 48

Identity-Based Views

SCOTT> CREATE VIEW ChangeMyAddrView ASSELECT addr FROM EmpsWHERE empno = SCOTT.AuthPkg.GetUser()

SCOTT> GRANT SELECT, UPDATE ON ChangeMyAddrViewTO BLAKE, ADAMS

Now BLAKE can execute

BLAKE> UPDATE SCOTT.ChangeMyAddrView SET addr = '31 Upham Way, …'

How is AuthPkg.GetUser implemented?

© Ellis Cohen 2002 - 2005 49

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 50

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 51

Answer: Identity-Based Update Control

SCOTT> CREATE VIEW ChangeSalView ASSELECT empno, ename, sal FROM EmpsWHERE 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 52

Authentication& Encryption

© Ellis Cohen 2002 - 2005 53

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 54

Authentication in a Single Machine Environment

AuthenticationVerifying 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 55

Corporate Network Security

Supposeuser is on one machinedatabase on another

ProblemSecure (mutual) authentication

Secure identification of user to databaseSecure identification of database to user

Secure communication between two machines: Use encryption

With potentially malicious individualsEavesdrop on communication lineRemove/modify/insert/replay packets

© Ellis Cohen 2002 - 2005 56

Primitive Communication Attacks

© Ellis Cohen 2002 - 2005 57

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 58

Symmetric/Private Key Encryption

EncryptionEncryption

““The quick The quick brown fox brown fox jumps over jumps over the lazy the lazy dog”dog”

““AxCv;5bmEseTfid3)fAxCv;5bmEseTfid3)fGsmWe#4^,sdgfMwir3GsmWe#4^,sdgfMwir3:dkJeTsY8R\s@!q3%”:dkJeTsY8R\s@!q3%”

““The quick The quick brown fox brown fox jumps over jumps over the lazy the lazy dog”dog”

DecryptionDecryption

Plain-text inputPlain-text input Plain-text outputPlain-text outputCipher-textCipher-text

Same keySame key

(shared secret)(shared secret)

Security depends on the secrecy of the key,

not the secrecy of

the algorithm

© Ellis Cohen 2002 - 2005 59

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 60

Session Keys

If a key is used too heavily,it can be compromisedAn 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 61

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 62

Simple Key-Based SecurityAssumption: 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 63

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 KerberosKerberos 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 64

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 65

Public Key Encryption

pri

vate

pri

vate

pu

blic

pu

blic

Public key encryption is based on the Public key encryption is based on the combination of a public key and a private combination of a public key and a private key, which are generated as akey, which are generated as a matchedmatched pairpair

The keys are mathematically related but it is The keys are mathematically related but it is computationally infeasiblecomputationally infeasible to deduce a to deduce a private key from its public keyprivate key from its public key

Private keys are kept secret - often by being Private keys are kept secret - often by being stored in a tamper-resistant chipstored in a tamper-resistant chip

pri

vate

pri

vate

Public keys are just that - Public keys are just that - public!public!

MM

SMART SMART CARDCARD123 89 3486123 89 3486

© Ellis Cohen 2002 - 2005 66

Public Key Encryption

EncryptionEncryption

““The quick The quick brown fox brown fox jumps over jumps over the lazy the lazy dog”dog”

““AxCv;5bmEseTfid3)fAxCv;5bmEseTfid3)fGsmWe#4^,sdgfMwir3GsmWe#4^,sdgfMwir3:dkJeTsY8R\s@!q3%”:dkJeTsY8R\s@!q3%”

““The quick The quick brown fox brown fox jumps over jumps over the lazy the lazy dog”dog”

DecryptionDecryption

Plain-text inputPlain-text input Plain-text outputPlain-text outputCipher-textCipher-text

Encrypt with the

receiver'spublic key

The message

can only be decrypted with their

private key

publicpublic

© Ellis Cohen 2002 - 2005 67

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 68

Secure Mutual Authentication

Database Server advertises its public key, DKA 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