Introduction to

Database Security
Kjell Jørgen Hole
NoWires Research Group
Department of Informatics
University of Bergen

Last updated September 12, 2008

KJhole.com

Outline
Database fundamentals
Vulnerabilities and attacks
Threats and countermeasures
Securing databases with cryptography
• cryptographic infrastructure
• cryptographic keys

2
Database fundamentals

Concept of database
• Database—collection of data and rule set
that specify relationships among the data
• a user utilizes the rules to describe the
logical format of the data
• Users interact with the database through a
program called
• database manager or DataBase
Management System (DBMS)
4
 Relational database
Diary: attribute name
name of
table Name Day Flight Status
field Alice Mon SK123 private
record Bob Mon YL011 business
Bob Wed BX201

• Data stored in tables

5

Database keys
• A primary key uniquely identifies a
record (row) from all other records
• example: values of the attribute
combination ‘name’ and ‘day’ in
the table ‘Diary’
• A foreign key links a row in one table to
a row in another table by referencing the
latter table’s primary key
6
 SQL
• By specifying an index on a column, the
database creates a data structure that allows
rapid search in the column
• primary key columns are typically indexed
• A language called Structured Query Language
(SQL) is used to manage data via the DBMS
• A programmer uses SQL to select information
from one or more tables
7

KJhole.com

Why database security?

• A database provides central storage for
customer information, business plans,
financial forecasts, acquisition targets, etc.
• More lucrative for an attacker to crack the
database than to eavesdrop on network
communications
• data is often encrypted during
transport, but stored in cleartext
8
Vulnerabilities and attacks

Why study attacks?

• A vulnerability is a flaw in the design
or a bug in the implementation of a
database system (DBMS, database,
server)
• We study confidentiality and integrity
attacks to be able to determine and
remove exploitable vulnerabilities in
a database system
10
 Confidentiality attack
defined
• Confidentiality attack—unauthorized person is
able to access sensitive information
• Example: attacker gets full access to database
server
a. downloads complete database file
b. loads file into database engine (part of DBMS)
to access data just like a regular user
11

Confidentiality attacks (1)

1. Access control (authentication and
authorization) is used to protect databases
• frequently misconfigured (?)
• allows administrators to read data
2. There often exist backdoors to databases
used for troubleshooting
• not subject to the otherwise strict access
control
12
Confidentiality attacks (2)
• Backdoors include read-only accounts
accessible by administrators and developers
• Non-production databases constitute
another example of a backdoor situation
• created by cloning a production database
• used for development and testing
• fewer access controls than production
databases
13

Confidentiality attacks (3)

3. Insecure database backups represent yet
another possibility for an attacker to get
access to sensitive data
• often stored off-site
4. SQL injection attacks utilize the application’s
own access privileges
• many web applications accessing databases
may be vulnerable to this type of attack
14
 Integrity attack defined
• Integrity attack—inappropriate change to
information in database
• requires the ability to write to a production
database
• Some attacks are easily discovered (changes
to web pages), while others are hard to find
(minor changes to financial data)

15

Common integrity attacks

1. Attack from malicious administrator

2. Subversion of faulty application
3. Using stolen account with write access
4. Escalating privileges of account

16
 Threats and
countermeasures

KJhole.com

Threat defined
• Threat—adversary with the knowledge, means,
and motivation to attack the confidentiality and
integrity of a database system
• There are two types of threats:
• Internal—threat inside firewall, knows
network topology
• External—threat must pass firewall, Intrusion
Detection System (IDS), unknown network
topology 18
 Internal threats, particularly database
administrators, can be more dangerous
than external threats

19

KJhole.com

Threats
1. Database administrators
2. Development staff
3. Network intruders
4. Legitimate users
5. Application crackers
6. Traditional thieves

20
1. Database administrators
• Privileged users with access to everything in
their administrative domain
• may be able to cover up traces of attacks
• It is best to assume that an administrator is
able (eventually) to access all information
• Countermeasures: employment screening,
separation of duties, encryption of information,
logging
21

2. Development staff
• Responsible for designing, building, and
testing database applications
• Have very good understanding of database
systems
• Access to troubleshooting accounts
• Countermeasures: encrypted information,
logging

22
 KJhole.com

3. Network intruders
• Individuals with unauthorized access to
network
• Eavesdrop on communication to obtain
confidential information or authentication
credentials
• May attempt to crack database application
• Countermeasures: transport encryption, IDS,
and hardened applications with access control
23

KJhole.com

4. Application crackers
• Crackers try to circumvent application
security to gain unauthorized access to
database
• Worst-case scenario is a cracker that gets
administrative privileges
• Countermeasures: intrusion detection,
prevent SQL injection, hardened
applications using access control
24
Legitimate users and thieves
5. Legitimate users can try to leverage
limited access privileges to gain
additional (unauthorized) access
• behave much like application crackers
6. Traditional thieves may steal database or
backup
• Countermeasures: secure database
server and backup media
25

Securing databases
KJhole.com

with cryptography
Use symmetric cryptography as
the last line of defense to protect
proprietary information
Changes the problem from protecting
the data to protecting the secret key
– easier to protect one secret than many

Protect key from direct and indirect

access 26
 KJhole.com

Direct key access

• An attacker with direct key access can copy
the key and use it to decrypt information
• Countermeasure: key protected from all
discussed threats by utilizing Hardware
Security Module (HSM) to store key
• key never leaves tamper-proof HSM
• If an HSM is not used, it is very important to
store key separately from the database
27

KJhole.com

Indirect key access

• Instead of trying to attack the key directly,

it is often easier to attack an application
that decrypts sensitive information
• An attacker can feed encrypted data to the
application (with key access) and view the
decrypted information

28
 KJhole.com

Indirect-key attack

• An indirect-key attack is a serious threat since

it may continue to provide information even
after the key is changed
• It is much more difficult to defend against
this type of attack than a direct key attack

29

KJhole.com

Indirect-key defense
• Ideally, strong access control that requires
authentication and authorization of each
decryption request should be used
• difficult with automated processes
• Containment: decrypt the fewest
necessary columns in the database
• Observation: extensive logging of
decryption request
30
Warning about transparent
encryption
• The encryption is transparent to the legitimate,
authorized user but not to attackers
• The security of a system with transparent
encryption depends on how well it can
distinguish legitimate users from attackers
• external attackers are good at looking like
legitimate users; internal attackers are
legitimate users 31

Warning about ...

• SQL injection attacks are not stopped by

transparent encryption
• If key is stored in tamper-proof HSM or
on some other machine, then transparent
encryption defends against thievery of
database or backups

32
 KJhole.com

Warning about
Cryptographic risks
1. The perhaps largest risk is the danger of lost
keys
• leads to loss of all data
2. Insufficient randomness in the key generation
routines can lead to “easy-to-guess” keys
3. Implementation bugs can lead to “bad”
encryption
33

KJhole.com

Application architecture
To the Internet • Web server
only talks to
Firewall
app. server
Web server
• App. server
Firewall
only talks to
Application server database
Firewall
• Cryptographic
Database system on app.
server or data-
34
base
Cryptographic architecture
1. Cryptographic engine—performs the
cryptographic operations
2. Key vault—secure storage of keys
3. Key manifest—tracks details of keys,
including aliases, family, state, engine
4. Key manager—manages keys in the
key vault and key manifest
35

Architecture ...
5. Protected data—the data that needs to be
secured by cryptography
6. Cryptographic consumer—maintains or
processes data that needs encryption or
decryption
7. Cryptographic provider—bridge between
the cryptographic engine and the consumer

36
 KJhole.com

Architecture illustrated
Data
input 1. Key admin uses key manager to create new
key in key vault and adding info to key manifest
Feedback Input
2. Crypto consumer Write
Crypto 5. Encrypted Key
hands data to crypto Protected data written to admin
provider and identifies consumer data
Read database
key family Task Admin
Encrypted data Cleartext feedback tasks

3. Provider uses key Lookup Manifest tasks

Crypto Key Key
manifest to determine
provider manifest manager
key, engine, and vault Key ID Task
feedback
Response Request
Task
4. Engine retrieves Key Key store tasks
feedback
key and performs Engine request Key vault
encryption Key data
Request

Key aliases and key ID

• The key vault and the cryptographic engine are
the only entities that have access to a real key
• All other entities refer to a key by its key alias
• Each key alias is a unique identifier over the
whole system
• consists of a key ID and a vault ID

38
 KJhole.com

More on HSM
• Includes both cryptographic HSM
engine and key vault
Engine Key vault

• Off-loads application CPU

• Implements Advanced Encryption Standard (AES)

• Communicates through PCI connection, SCSI, or over

SSL connection

• Provides strong key protection

39

KJhole.com

Key manifest
• The key manifest keeps track of the connection
between key vault and key ID
• In addition, the manifest stores a key’s family
(to be explained), activation date, and the status
of the key
• Since not all cryptographic engines have access
to all vaults, the key manifest must also store
which engine is assigned to a key
40
Benefits of key separation
• Minimize the number of entities that need
access to the key
• use different keys for different databases
• Keep the amount of data handled during a
key replacement manageable
• Reduce the amount of data encrypted with a
given key so that attackers have less
information to use in breaking the encryption
41

KJhole.com

Benefits of key ...

• Limit the damage if a particular key is

compromised
• Allow different levels of security to be
applied to different types of data

42
 KJhole.com

Key family
• Key family—group of keys that are used to
operate on the same type of data
• Example:
• one family is used for credit card numbers
• another family is used for medical records
• Keys are labeled with their family name
• Key families map keys to columns in database
43

KJhole.com

Key life cycle (1)

State Encryption Decryption
Life cycle
Pending No No
Live Yes Yes
Expired No Yes
Retired No No
Terminated No No

44
 KJhole.com

Key life cycle (2)

• A pending key becomes alive when its
activation date is reached
• There may be several pending keys in a family
• There is only a single live key in a family. The
previous live key is pushed into the expired
state
• There may be several expired, retired, and
terminated keys in a family
45

KJhole.com

Key migration

• If the key used to encrypt data has expired,

then the data is decrypted with the expired
key, but changes are encrypted with the
new live key

46
 KJhole.com

Key fatigue

• The amount of data encrypted with a given

key must be limited because all engines start
to leak information when they use the same
key for too long
• N. Ferguson and B. Schneier. Practical
Cryptography. Wiley Publishing, 2003

47

Conclusions
• Necessary to develop a very good
understanding of vulnerabilities,
threats, and countermeasures
• This understanding should shape the
architecture and design of a new
database system
• Cryptography provides last line of
defense
48
 Literature
• K. Kenan, Cryptography in the Database:
The Last Line of Defense, Symantec Press,
2006
• D. Gollmann, Computer Security, 2nd Ed.,
Wiley, 2006
• C. P. Pfleeger and S. L. Pfleeger, Security in
Computing, 4th Ed., Prentice Hall, 2007

49